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:
VeriSign, Inc.
Address:
487 E. Middlefield Road, Mountain View, CA 94043
Telephone:
+1 (650) 961 – 7500
Fax:
+1 (650) 961 – 7300
Email:
info@verisign-grs.com
Confirm Email:
info@verisign-grs.com
URL:
http://www.verisign.com
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.

Billions of times each day, the world interacts with a company you may not
realize is there, a company that is driving dynamic transformations at the very
core of commerce and communications. Through our Intelligent Infrastructure
Services, VeriSign enables businesses and individuals to find, connect, secure,
and transact across today's complex Internet, telecom, and converged networks.
We operate the systems that manage .com and .net, handling 14 billion DNS
queries that support Web addresses and emails every day. We run one of the
largest telecom signaling networks in the world, enabling services such as
cellular roaming, text messaging, caller ID, and multimedia messaging. We manage
network and user security for more than 3,000 global businesses and 400,000
websites. And we handle more than 30 percent of all e-commerce transactions in
North America, processing $100 million in daily sales. As next-generation
networks emerge and converge, VeriSign is there, deploying the Intelligent
Infrastructure Services necessary for everything from RFID-enabled supply chains
to inter-enterprise VoIP to mobile and rich media content distribution. Whether
you're a telecom carrier looking to rapidly deploy new services; a Fortune 500
enterprise needing comprehensive, proactive security services; or an e-commerce
leader wanting to securely process payments and reduce fraud, we can help. We're
VeriSign. Where it all comes together.TM To learn more about VeriSign you can
visit www.verisign.com. 

VeriSign is organized into 3 business units: Naming and Directory Services,
Security and Payment Services, and Communications Services. The Naming and
Directory Services business unit operates the .net, .com, .TV, and .cc
registries and provides outsourced registry services for .name, .edu and .bz. In
addition, the business units' qualifications were recognized by EPCglobal in
2004 when VeriSign was named as the authoritative root of the emerging EPC
Network, enabling organizations to locate and share RFID information in a
similar manner to the DNS enabling browsers to locate Web addresses. 

Through the operation of the .net TLD registry, VeriSign ensures a high level of
stability and security for a TLD that is woven into the very fabric of the
Internet and e-commerce, supporting more than $700 billion in e-commerce, 2.8
trillion page views, 300 billion e-mails, 58 percent of all Internet hosts and
more than 5 million domain names. With 100 percent availability of .net TLD
resolution services and 100 percent zone file accuracy over the past 7 years,
network operators, registrars, businesses, and Internet users worldwide have
come to depend on the certainty of the .net TLD. As a result, .net users such as
Sun Microsystems, Microsoft, MCI, HiChina, The Thomson Group, China Telcom, and
KRNIC have endorsed VeriSign's performance as the .net TLD operator. As the
operator of the .net TLD for the last 13 years, VeriSign prides itself on having
invested more than $150 million to build a world-class infrastructure that
reliably and securely handles more than 4 billion .net DNS queries per day, more
than 500,000 .net DNS queries per second during adverse conditions, and more
than 225 million .net registration transactions per day. To continue to offer
this level of stability and security, VeriSign is committing to:

+ An SLA of 100 percent availability for resolution services
+ An SLA of 100 percent accuracy of the zone file
+ An SLA of 100 percent availability of Whois
+ An SLA of 99.99 percent availability for registration services
+ Expanding the .net infrastructure from 7 countries and 13 locations to 12
countries and 18 locations by end of 2005.

Operating a registry with 100 percent availability for DNS resolutions, 100
percent zone file accuracy, 99.99 percent availability of registration services,
and 24x7x365 customer service requires a diligence that can only come from a
staff of more than 140 dedicated professionals. In addition, as the .net TLD
grows from 5 million domains in 2005 to 10.1 million domains in 2011, and from 4
billion daily DNS queries in 2005 to 30 billion DNS queries in 2011, delivering
on the commitments required to maintain this high level of stability and
security necessitates the ability to make a significant investment in the
operation of the .net TLD. VeriSign is prepared to continue to make this
investment in both our technical infrastructure as well as our experienced staff
that has over 1,000 years of combined Internet-related experience. VeriSign also
has a proven track record of promoting and strengthening user choice as well as
end-user stability and reliability. As such, VeriSign has grown the .net name
base at an annualized rate (2004) of 22 percent, making it the second-largest
non-.com domain of all 250+ available domains.

VeriSign's ability to make these investments results from the company's strong
balance sheet and income statement. For the period ending September 30, 2004,
VeriSign's year to date revenue was $810.4 million, net income was $71.4
million, and free cash flow was $423.8 million. In addition, VeriSign has $605.7
million in cash and cash equivalents on hand and no long-term debt. As the usage
of the Internet continues to grow, VeriSign is committed to continue
significantly investing in the .net resolution, registration, monitoring, and
support infrastructure to deliver on our promises of highly stable and secure TLD.

As a leader in DNS management, VeriSign understands the need to operate the .net
TLD in a manner that supports the growth and diverse use of the Internet. Over
the past 5 years, VeriSign has developed and deployed a DNS infrastructure
technology that supports multiple protocols called ATLAS (for Advanced
Transaction Lookup and Signaling System) that was named as one of the year's
best innovations by InfoWorld and cited by ICANN Chairman Vint Cerf as an
example of innovation in the ICANN-sponsored evaluation of new gTLDs. With
ATLAS, VeriSign can provide the 100 percent reliability and high level of
security the Internet expects from .net resolution services. In fact,
traditional hardware and software solutions deployed by other registries are
unable to handle on a reliable and cost-effective basis the daily 4 billion .net
queries or 800:1 queries to domain name ratio for .net. Not only does ATLAS
enable a high level of stability, but also it supports emerging uses of the DNS
for services such as VOIP, VeriSign's EPC/RFID services, and wireless services.
In addition to ATLAS, VeriSign has implemented IPv6, International Domain Names
(IDN) with the corresponding variant tables, a DNSSEC pilot, and has actively
led the development of the EPP and IRIS standards.

VeriSign's commitment to developing the Internet does not stop with technology
innovations. Over the past 5 years, VeriSign has recruited 120+ registrars in
markets throughout the world, recently deployed TLD servers in South Korea and
China (launching February 2005), played an instrumental role in establishing a
new transfer policy, provided 24x7x365 customer service in 150 languages and
deployed a TLD monitoring system called the Heads Up Display (HUD) that allows
governments and root operators to monitor usage and trends of the .net TLD.
Recognizing the importance of community participation in the development of the
Internet, VeriSign has organized IDN and DNSSEC developer consortiums to
establish industry collaboration and encourages its employees to actively
participate in leadership positions on standard bodies such as the IAB and IETF.
Acknowledging this participation, Jonathan Schwartz, President and COO of Sun
Microsystems, stated, "they [VeriSign] have expanded capabilities to address new
and increasing uses of the Internet, and have taken leadership roles in standard
organizations and innovation councils to further secure and stabilize the .net
registry."

As part of VeriSign's strong commitment to the development of the Internet, and
.net in particular, VeriSign will:

+ Maintain implementation of EPP
+ Continue to offer all existing registration services
+ Implement and support ICANN's consensus policies and policy development processes
+ Maintain our DNSSEC and Whois/IRIS pilot program and continue coordinating
with the community on market adoption and implementation
+ Continue to perform extensive market research for the benefit of the entire
community
+ Establish an international .net Policy Implementation Committee to facilitate
timely implementation of ICANN policies
+ Continue to actively recruit new registrars in developing Internet markets.

VeriSign's ability to provide a highly reliable, secure, and scalable DNS system
for the .net TLD is unmatched in the industry.  When considering applications
for operating the .net TLD, the standard should include 7 years of performance
with 100 percent availability for resolution services, proven commitment to
industry-leading SLAs for registration, resolution and Whois, proven ability to
handle DDOS attacks that spikes DNS traffic to 500,000 queries per second,
proven active recruitment of new registrars, registrar marketing programs, and
the ability to support new uses of DNS, such as wireless convergence.  

Finally, by leveraging the integrated nature of the .net and .com
infrastructure, VeriSign will reduce it registry fee by 42 percent to $3.50 per
year exclusive of the $0.75 ICANN fee (inclusive of the ICANN fee, the
registration fee is $4.25 per year). This fee allows VeriSign to provide
unparallel value to the industry and to offer all existing and proposed services.

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,
Mark McLaughlin, Senior Vice President and General Manager, Naming and Directory
Services. Mr. McLaughlin is the Senior Vice President and General Manager of
VeriSign's Naming and Directory Services Business Unit. The Naming and Directory
Services Business Unit runs the internet's .com and .net system as well as
provides powerful and proven platforms to businesses to support their
mission-critical applications across disparate networks, devices, and end
points. In this role, Mr. McLaughlin is responsible for all P&L, operations,
engineering, sales, and business development aspects of this business. Before
joining this business unit, Mr. McLaughlin headed business development for
VeriSign. Prior to this, Mr. McLaughlin was the General Manager of VeriSign's
Payment Services Business Unit. In this role, Mr. McLaughlin led VeriSign's
Internet and wireless payment line of business. Previously, Mr. McLaughlin was
the Vice President of Sales and Business Development for Signio, a leading
Internet payment company. Before joining Signio, Mr. McLaughlin was the Vice
President of Business Development for Gemplus, the world's largest smart card
company. Before joining Gemplus, Mr. McLaughlin was the General Counsel of Caere
Corporation, the word's leading OCR software company. Before joining Caere, Mr.
McLaughlin practiced law with Cooley Godward, a leading high technology law firm
in Silicon Valley, in the firm's Information and Technology Licensing Group and
assisted clients such as Adobe and Netscape in technology and corporate matters.
Mr. McLaughlin received his JD, Magna cum Laude, from Seattle University School
of Law and his BS from the United States Military Academy at West Point. Mr.
McLaughlin served as an attack helicopter pilot in the U.S. Army and earned an
Army Commendation Medal and Airborne Wings.

(Experience and qualifications for all key personnel can be found in Table 3(b)-1.)
(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,
Mr. Mark McLaughlin reports directly to Mr. Stratton Sclavos, Chairman and CEO.
The primary management and operations are handled through the Naming and
Directory Services business unit.
(iii) the top two financial officers of the applicant,
Dana L. Evan, Executive Vice President and CFO. Mrs. Evan joined the company in
May 1996 as Vice President of Finance and Administration and Chief Financial
Officer. From November 1995 to May 1996, Ms. Evan served as acting Chief
Financial Officer as a consultant to VeriSign. Over the past 8 years, she has
been a key member of the Executive Management team helping to grow the company
from a small startup into a global corporation. In her capacity as CFO and
Executive Vice President of Finance and Administration, Ms. Evan is responsible
for all company operations related to finance and accounting, human resources,
and legal matters. Ms. Evan has over 20 years of experience, specializing in
finance and accounting for high technology companies. Prior to joining VeriSign,
she provided consulting services in the capacity of Chief Financial Officer,
Vice President of Finance and Controller for both public and private companies.
Ms. Evan holds a BS in Commerce with a concentration in Accounting and Finance
from the University of Santa Clara. She is also a Certified Public Accountant in
the State of California.

Bert Clement, Senior Vice President, Finance and Administration. Mr. Clement has
been part of the VeriSign management team since 2000. He has over 20 years of
experience in accounting and finance. Since 2000, Mr. Clement has been
responsible for all aspects of internal and external reporting, revenue
recognition, accounts receivable, technical accounting, merger integration, and
due diligence on acquisitions. His responsibilities include managing the
accounting functions related to our foreign locations, monthly closures and
consolidation, and finance decision-making with the CFO for the company as a
whole. He has spent significant time over the last 2 years supporting the
company's Sarbanes Oxley compliance program.  His duties also included tax,
purchasing, and internal audit. Previously, Mr. Clement worked at MCI
Communications in both Corporate Accounting and as Director of Financial
Operations for the Mass Markets business unit, which accounted for $7 billion in
revenues. His responsibilities included revenue assurance, operational
improvement, and financial reporting. Before joining MCI, Mr. Clement spent 12
years with Price Waterhouse as an auditor, including a 3-year tour of duty in
Italy. He has extensive experience with high-growth public companies. Mr.
Clement graduated from George Washington University in 1984 with a Bachelor's in
Accountancy.
(iv) the person with the principal technical responsibility for the operation of the registry,
Aristotle Balogh, Senior Vice President, Operations and Infrastructure. Mr.
Balogh is the Senior Vice President of Operations and Infrastructure for
VeriSign Corporation. Mr. Balogh is responsible for delivering secure, highly
reliable and highly available core Internet services critical to the operation
of the Internet and e-commerce, including security services such as web server
certificates, the payment gateway, and the DNS. VeriSign server certificates
secure the majority of Internet commerce transactions, while VeriSign's payment
gateway is the largest gateway for Internet merchants offering online commerce
transactions on the Internet. VeriSign also operates 2 of the Internet's 13 root
server sites, including the authoritative "A" root, from which all other root
servers obtain the top level map of the Internet, as well as all DNS for
.com,.net, .org, .tv, .cc, and other Tlds--an infrastructure that underlies
practically all Internet operations. Mr. Balogh's responsibility includes
implementing and operating the infrastructure that delivers VeriSign's external
Internet services, such as engineering for the DNS--the world's most reliable,
highest volume look-up service. Mr. Balogh is also responsible for engineering
and operations of internal VeriSign infrastructure, including corporate IT,
Management Information Services (MIS), IP networks, information security,
infrastructure engineering, facilities, and physical security. Mr. Balogh's has
served as Senior Vice President, Operations and Infrastructure, since May 2002.
From 1999 through 2002, Mr. Balogh served as Vice President of Engineering at
VeriSign and Network Solutions. Prior to that, he held a variety of positions at
Network Solutions. Before joining Network Solutions in 1998, Mr. Balogh held a
variety of senior engineer and management roles at SRA Corporation, UPS's
Roadnet Technologies, and Westinghouse Electric Corporation. He earned his MS in
Electrical and Computer Engineering from the Whiting School of Engineering and
BS in Electrical Engineering and Computer Science at Johns Hopkins University.
(v) each other executive or management person of the applicant who will have significant policy making or operational influence regarding the registry operations,
Raynor Dahlquist, Vice President, Naming and Directory Services. Ms. Dahlquist
is the Vice President for Naming Services at VeriSign, Inc., where she is
responsible for the domestic and international business unit supporting .com and
.net registries and new naming services. She was previously the Director of
Product Management for VeriSign's Payment Services Group where she managed the
domestic and international e-commerce gateways for VeriSign's 100,000+
merchants. Previous to VeriSign, Ms. Dahlquist worked as the Director of Product
Management for Network Solutions, where she managed the team responsible for the
creation of the website and e-commerce offerings of Network Solutions. Prior to
Network Solutions, Ms. Dahlquist worked as a Product Manager for Intuit as a
part of Intuit's Quicken Insurance group. Ms. Dahlquist joined Intuit from
Transamerica, where she managed the product marketing programs of Transamerica's
nontraditional insurance lines, including the online offering of insurance
products and services, and Transamerica's insurance annuity offerings through
financial brokerage firms and large financial institutions. Ms. Dahlquist holds
a Masters of Business Administration, with an emphasis in International Finance
and Marketing, from Pepperdine University, Malibu, CA and a BA from
Randolph-Macon College, Ashland, VA, majoring in French.
 
Charles A. Gomes, Vice President, Policy and Compliance. Mr. Gomes has been a
part of VeriSign/Network Solutions' management team since 1984.  He has over 30
years of experience as a leader in business and educational environments. Since
October 1999, Mr. Gomes served as Vice President of Policy and Compliance for
VeriSign Naming and Directory Services (VNDS). Because he is VNDS's primary
point of contact with ICANN, he is actively involved in the development and
implementation of policies involving all aspects of domain name registration
services, including international domain names, redemption grace period,
registrar transfer policy, deleting names, etc. Previously, Mr. Gomes was Vice
President of Customer Programs for Network Solutions. From 1995 to 1999, he was
responsible for all areas of customer service in support of Network Solution's
Internet domain name registration services. During this time, he saw staff grow
from 25 to 220 and the number of domain registrations grow from about 135,000 to
over 3.4 million. In earlier responsibilities with Network Solutions, Mr. Gomes
managed various programs and projects involving delivery of technical services
to state and federal government agencies.  Projects ranged in scope from data
center construction and equipment/software procurement to computer center
operations, training, and information center support. Before joining Network
Solutions in 1984, Mr. Gomes was a secondary school math teacher. He has a
Master's in Education from Boston University and a BA in mathematics from the
University of California at Davis.
(vi) all directors or persons with equivalent positions for non-corporate entities, and
The following represent VeriSign's Board of Directors:
- Stratton Sclavos, Chairman and CEO
- D. James Bidzos, Vice Chairman of the Board
- William L. Chenevich, Vice Chairman of Technology and Operations Services, US
Bancorp
- Kevin R. Compton, General Partner, Kleiner Perkins Caufield & Byers
- Scott G. Kriens, President, Chief Executive Officer and Chairman of the Board,
Juniper Networks, Inc.
- Len J. Lauer, President and Chief Operating Officer, Sprint Corporation
- Roger H. Moore, Former Chief Executive Officer, Illuminet Holdings, Inc. 
- Gregory L. Reyes, Chairman of the Board and Chief Executive Officer, Brocade
Communications Systems, Inc.
- William A. Roper Jr., Corporate Executive Vice President, SAIC.
(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.
- Wellington Management Company LLP
- Franklin Resources, Inc.
- Capital Guardian Trust Company
- T. Rowe Price Associates, Inc.

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.

+ Type of Entity: Corporation
+ Law under Which Organized: United States, Delaware
+ Company Structure: For-Profit
+ Articles of Incorporation: Available upon Request
   

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.

At the time of submission of this proposal, VeriSign, Inc. has approximately
3,000 full-time employees.
   

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.

As the current .net registry operator, VeriSign has implemented all ICANN
consensus policies to date and will implement all applicable ICANN consensus
policies going forward. We fully recognize that policy and contractual
compliance are necessary and important to fulfill our obligations to ICANN. 

Our commitment to policy compliance is demonstrated annually. VeriSign is the
only registry in the world that has undergone annual equivalent access audits
performed by an independent, internationally recognized, third party accounting
firm to confirm compliance. To ensure the comparable level of compliance
demonstrated by VeriSign, any credible applicant must have a fully implemented
Inter-Registrar Transfer Policy, fund regular third-party audits to ensure
compliance with ICANN policies, and have a proven experience working with the
Internet community to smoothly and quickly implement all of ICANN's policy.

VeriSign Advantages:
+ Implemented all applicable ICANN consensus policies to date.
+ Commitment to implement all consensus policies going forward.
+ Continued support of Policy Advisory Group to facilitate policy implementation
(see Section 7 for a full description).
+ Fully implemented the Inter-Registrar Transfer Policy on 12 November 2004.
 
This section provides the following information with regard to ICANN Policy
Compliance, organized into 3 subsections, as follows:
* Mechanisms to Ensure Policy Compliance: VeriSign employs numerous mechanisms
(described below) to ensure compliance with all applicable ICANN policies. Such
mechanisms include training programs, monthly compliance reports, and
maintaining a dedicated policy compliance team.
* VeriSign's Involvement in ICANN's Policy Development: An examination of the
multiple forms of involvement with ICANN and the broader Internet community to
facilitate policy development and compliance.
* Method for Implementing the Inter-Registrar Transfer Policy: Description of
VeriSign's implementation of ICANN's Inter-Registrar Transfer Policy.


Mechanisms to Ensure Policy Compliance

VeriSign has a comprehensive process in place to address ICANN policy issues and
implementation. Active coordination through ICANN working groups and committees
provides the basis for implementing ICANN policy.

The first step in ICANN Policy Compliance is to ensure compliance with all
registry agreement requirements as well as all applicable consensus policies.
VeriSign business, technical, legal, and policy teams work together to
continually ensure compliance with all applicable consensus policies and the
.net registry agreement. In particular, the VeriSign Vice President of Policy
and Compliance and the VeriSign Compliance Officer actively monitor and manage
policy and contractual compliance across all aspects of registry operations
using the following mechanisms:
* Offering a weekly instructor-led initial Organizational Conflicts of Interest
(OCI) training course for all new personnel (which includes both employees and
contractors) supporting the registry business. A refresher course is required to
be taken annually.
* Maintaining a contractual requirements matrix that is updated monthly. This
matrix serves as a management tool to regularly ensure that all contractual
requirements are met on time. The matrix is maintained by the Compliance Officer
and provided to the Vice President of Policy and Compliance each month. 
* Preparing a monthly compliance report that summarizes the fulfillment status
of all contract requirements. This report is produced by the Compliance Officer
in conjunction with the contractual requirements matrix referenced in the
previous bullet. It shows the status of all requirements that are due or coming
due in the near term. The report is updated for the Vice President of Policy and
Compliance each month.
* Performing a semi-annual compliance audit. This audit serves as an internal
check of the equivalent access requirements to registrars.
* Developing detailed policy implementation plans for new, applicable consensus
polices in coordination with business and technical teams. This is a critical
part of ensuring full compliance with all applicable ICANN consensus policies.
It involves coordination and cooperation among VeriSign business, technical,
policy and legal teams as well as with registrars and ICANN. Our implementation
of the ICANN Inter-Registrar Transfer Policy is an excellent example of the
steps VeriSign takes in implementing policies. 

Beyond our internal mechanisms, VeriSign is also committed to helping our
registrar customers comply with the Registry Registrar Agreement (RRA). To
facilitate this, our Compliance Officer conducts an Annual Compliance Review of
registrar practices to check compliance of the RRA requirements by all
registrars. Results are communicated to registrars to assist them in meeting
their contractual requirements. In the case of new policy implementation, we
schedule Web-based seminars at varying times to accommodate registrars in
different time zones. In addition, through day-to-day interaction with
registrars we notify them of irregular system behavior and work collaboratively
to understand these observed anomalies in the context of their business needs.
Through this process we regularly update ICANN of our findings and continue to
collaborate with registrars to identify solutions. All policies are available
online in the password protected area of our website; an evaluator password can
be found in Part 2, Section 4(a).

In all of our policy implementation efforts, we perform full, policy life cycle
management that includes the following:
* Active participation in GNSO constituencies, working groups and committees in
the policy development stage provides the initial basis for implementing ICANN
policy.
* Closely working with our registrars and actively seeking feedback during the
policy development process helps us contribute to that process in a manner
consistent with our customers' needs.
* Developing draft business and technical requirements before policies are
finalized allows us to estimate levels of effort required to implement policies,
provide registrar implementation tools and then estimate reliable implementation
timetables.

While policy is being finalized, VeriSign initiates the internal planning
process to understand the requirements of a change and develop a schedule. This
includes:
* After policy finalization, preparing detailed business and technical
requirements ensures that systems development work can be accurately done in
preparation for policy implementation.
* Well in advance of policy implementation, we notify registrars of policy
details and implementation dates and provide assistance via web-based seminars,
account manager visits and through normal customer service support.

After policies are implemented, we commence the implementation phase which includes:
* Working directly with registrars and actively seeking feedback on the
effectiveness of policies and procedures to provide the mechanisms to verify
that we are achieving policy objectives.
* Monitoring the implementation of the RRA policies and procedures provides the
methodology for identifying policy infractions, resolving policy or procedure
disagreements, improving operational support of the policy, and providing
insight into needs for improvement of the policy.
* Ongoing participation in GNSO constituencies, working groups and committees in
policy review stages provides the opportunity to continually improve policies.

Each of these discreet mechanisms are vital to ensure policy compliance and are
embedded in the planning processes of VeriSign. To facilitate the efficient
introduction of ICANN policies, VeriSign will continue to support our Policy
Advisory Group. A full description of this group is found in Section 7.


VeriSign's Involvement in ICANN Policy Development

VeriSign has an established record of actively contributing to ICANN policy
development efforts by working collaboratively with the broader ICANN community
including IETF, the Business, Registrar, Registry, ISP, Intellectual Property,
CNSO, and Non-Commercial Users Constituencies, and the IAB. VeriSign will
continue to actively engage with the community to ensure timely implementation
and compliance with future applicable ICANN policies. Some of the ways that
VeriSign has contributed to ICANN policy development processes are highlighted
below:
* VeriSign personnel have actively participated in every ICANN public meeting
since ICANN's inception in the Fall of 1998.
* VeriSign personnel have actively participated in the generic top-level domain
(gTLD) Registry Constituency currently as a part of the Generic Names Supporting
Organization (GNSO) and previously as part of the Domain Name Supporting
Organization (DNSO) since the creation of all three of these organizations.
VeriSign provided initial support for the creation of the gTLD Registry
Constituency to include providing the first chair of that group after new gTLD
registries were introduced. VeriSign hosted the gTLD Registry Constituency web
site for the first three years of the organization's existence.
* VeriSign provided representatives to the DNSO Names Council during the
organization's first years, provided a chair and an additional representative to
the DNSO Budget Committee that ultimately recommended the selection of the
current GNSO secretariat, and provided a representative to one of the first DNSO
working groups, Working Group E.
* Through the gTLD Registry Constituency and through direct contributions,
VeriSign has contributed to every policy development effort undertaken by the
DNSO/GNSO including such notable examples as the Universal Dispute Resolution
Policy (UDRP), the introduction of new gTLDs, internationalized domains, the
Redemption Grace Period, the Expired Names Deletion Policy, the Domain Name
Transfer Policy, .net re-compete, three Whois task forces (currently in
progress) and the procedure for use by ICANN in considering requests for consent
and related contractual amendments to allow changes in the architecture or
operation of a gTLD registry (currently in progress).
* VeriSign personnel worked closely with registrars to break a long-standing
deadlock in the development of a new registrar transfer policy and then
participated actively in the lengthy steps leading to the implementation of the
new policy by all registries and registrars.
* VeriSign provides members to ICANN's Security and Stability Advisory Committee
and the Root-Server System Advisory Committee.
* On behalf of VeriSign's registry operator role for the .tv and .cc ccTLDs,
VeriSign provides representatives to the ICANN Country Code Supporting
Organization and other ccTLD groups involved in ICANN policy development activities.

In addition to the direct involvement in policy development described above,
VeriSign also indirectly contributes to policy development by participating in
technical standards bodies, in ICANN advisory committees, and by hosting
workshops and forums in the broader Internet community. VeriSign extends policy
compliance to both technical and business groups within the company to ensure
compliance and coordination. 

The technical standards work performed in organizations such as the Internet
Engineering Task Force (IETF) often become guidelines and/or requirements for
TLD registries through ICANN processes, and then become the basis for policy
development to support implementation of the standards. As just one example of
VeriSign personnel participation in technical standards work, at any Internet
Engineering Task Force meeting, there are typically 10 to 12 VeriSign
participants; this does not include additional personnel who participate in IETF
working groups remotely. Four examples that are especially relevant for registry
operators are: 
1) The extensible provisioning protocol (EPP) that is now a standard registry
protocol; 
2) The four international domain name (IDN) standards that were produced by the
IDN Working Group;
3) The Internet Registry Information Service (IRIS) protocol nearing completion
in the Cross Registry Information Service (CRISP) working group, a possible
replacement for the old Whois protocol; 
4) Domain name system (DNS) security extensions (DNSSEC). 

In the case of EPP, Scott Hollenbeck, a senior VeriSign engineer, authored the
original EPP Request for Changes (RFCs) (3730, 3731, 3732, 3733, 3734, and 3735)
as part of the IETF process and continues to be involved in the update of the
protocol. He also authored an EPP extension to accommodate the implementation of
the Redemption Grace Period. In the case of IDNs, three VeriSign personnel
(Scott Hollenbeck, Pat Kane and John Colosi) participated actively in the IETF
IDN working group that ultimately resulted in the four IDN Requests for Changes
(RFCs) that now guide the implementation of TLD IDN programs. With regard to
IRIS, four VeriSign engineers have been key contributors to the ongoing IETF
effort (Andrew Newton, Leslie Daigle, David Blacka and Scott Hollenbeck).
Regarding DNSSEC four VeriSign engineers have been active participants in the
work that is nearing completion (Mark Kosters, Scott Hollenbeck, Matt Larson and
Dave Blacka). 

Because there is much cooperative work that needs to be performed after
standards are finalized, VeriSign also provides leadership in the Internet
community to facilitate implementation of already approved standards as well as
those that are nearing approval. With regard to IDNs, VeriSign hosts IDN
workshops in the U.S., Asia, and Europe. To get a head start and enlist
cooperation of the many Internet players who will need to be involved in
implementation of DNSSEC, VeriSign also hosts DNSSEC workshops in the U.S., Asia
and Europe. In all of these efforts, VeriSign invites domain name registries and
registrars, Internet service providers (ISPs), application providers, technical
leaders, and other interested parties.


Implementing ICANN's Inter-Registrar Transfer Policy

VeriSign is fully compliant with the ICANN Inter-Registrar Transfer Policy. It
was implemented, pursuant to schedule on 12 November 2004. VeriSign has long
recognized the importance of implementing a new transfer policy that more
closely governs the transfer of domain names from one registrar to another. In
October 2002, our Vice President of Policy and Compliance initiated a working
group of registrars to create a list of recommendations for improving the
transfer process, which was sent to all registrars, registries, and the DNSO for
further discussion. Most of the recommendations that were made by this group
were incorporated into the recommendations that the DNSO Transfer Task Force
presented to the ICANN Board. VeriSign continued to be actively involved in the
Transfer Implementation Committee and the Transfer Assistance Group, as well as
with registrars and registries leading up to the actual implementation of the
new policy on 12 November 2004. Even before the release of the final transfer
policies on 12 July 2004, VeriSign began the work of converting policy to
practice. As with all new ICANN policies, we approached the implementation
process in a consistent and systematic manner. The steps taken to implement the
new transfer policies are summarized below:
* Key personnel were identified and assigned to lead and participate in the project.
* A detailed project plan was developed encompassing both business and system
deliverables.
* A communication plan consisting of policy implementation reminder notices to
the registrars at 30, 7, and 1 day prior to the implementation date of 12
November 2004. In addition, web seminars to review the policies and VeriSign's
implementation of them were held for the registrars prior to the effective date
on 8 November.
* Supplemental rules were developed, approved by ICANN, and published.
* Contract amendments to integrate the new policy into the RRA were drafted,
approved by ICANN, and sent to all registrars for execution.
* An online transfer dispute resolution submission tool was built and is
available to registrars.
* A registrar readiness exercise was conducted by our customer service team to
answer any questions they have about the policy, its implementation, and to
obtain transfer point of contact information for each registrar.
VeriSign was the first gTLD registry to submit its supplemental rules to ICANN.
Those rules were also provided to other unsponsored registries to provide a
possible basis for the development of their supplemental rules.

Because VeriSign processes an average of 28,000 successful .net registrar
transfers each month, the potential for a dispute to ensue is high. Therefore,
it is critical to have in place a system that allows the registrars to easily
submit a request for enforcement, and for our team to track and resolve the
dispute within the service level timeframes stipulated by the dispute resolution
policy. Registry operators for smaller TLDs can survive using manual processes,
but it is critical to recognize that manual processes will not scale in a large
TLD. This applies to both registry and registrar operations. As mentioned above,
VeriSign developed and implemented an online submission tool to address this
need. Registrars can use this tool to submit, respond to, and track their disputes. 

To ensure security and integrity, access to this tool requires two sets of
authentication. Registrars first must enter their username and password that
were assigned to them to access the registrar only, password-protected area of
the VeriSign website. Only those individuals who have been identified as the
transfer point of contact for each registrar have been provided the second
registrar unique username and password needed to access the transfer dispute
resolution submission tool. Upon entering this username and password, the
transfer point of contact has access to a list of their open cases and the
online forms used in the transfer dispute resolution process at the registry
level. This process involves six discrete forms; the "Supplemental Rules for
Registrar Transfer Disputes" can be found at
http://www.verisign.com/static/016086.pdf. 


Conclusion 

VeriSign's commitment and capability in implementing ICANN consensus policies is
evidenced by historical compliance with all applicable consensus policies and
our significant participation in ICANN policy development processes, as well as
indirectly by contributions in the development of technical standards,
participation in ICANN advisory committees, and sponsoring workshops and forums
for the community at-large. In addition, VeriSign employs experienced staff and
proven mechanisms to ensure compliance with policies and contractual
requirements as the Internet continues to grow and the challenges increase. Our
periodic registrar compliance review provides ICANN evidence that VeriSign
monitors registrar compliance with the RRA. Finally, our online Transfer Dispute
Resolution Submission Tool allows registrars to easily submit and track
transfer-related disputes. Each of these specific features, as well as others
mentioned above, provide noticeable benefits to the community and assurance of
policy compliance. VeriSign will continue these practices and will all future
applicable ICANN consensus policies.
   

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

VeriSign currently allows, and will continue to allow, all ICANN-accredited
registrars to register names in .net on an equivalent basis. 

VeriSign Advantages
+ Have several technical and operational mechanisms in place to ensure
equivalent access to all registrars
+ Sponsor third-party audits verifying compliance
+ 24x7x365 customer support in 150 languages, including English
+ Provide programs that increase registrar points of presence in new markets
throughout the world, and provide existing registrars extensive marketing and
technical support.


To maintain a comparable level of equivalent access currently provided in .net,
an operator must demonstrate: 
* Customer service support of 150 languages, including English, with an abandon
rate of 2 percent, 94 percent of all calls answered within 20 seconds, and 99
percent of emails answered within 24 hours
* Support of 250+ registrars and 10,000+ resellers internationally and the
ability to equivalently support over 500 registrars by the end of 2005
* Provide programs that increase registrars in new markets throughout the world,
support existing registrars' marketing and technical needs
* A demonstrated method to ensure a smooth and low-cost migration from Registry
Registrar Protocol (RRP) to Extensible Provisioning Protocol (EPP), including
the demonstrated ability to operate both RRP and EPP during this migration
period for at least 1 year
* That claims of equivalent access are certified and audited by an independent
nationally recognized firm on an annual basis at its own cost (VeriSign has
spent over $400,000 on such audits)
* That it is not under the control of, nor influenced by, a substantial
financial or organizational relationship with one or more registrars or
government entities.


VeriSign's commitment to provide equivalent access to accredited .net registrars
begins even before we receive notification from ICANN of a newly accredited
registrar. Seven of the steps we take to establish and monitor equivalent access
for all registrars include:
1. Semi-annual certification of compliance with the equivalent access
requirements stipulated in the Organizational Conflict of Interest (OCI)
Compliance Plan, and strict adherence to the Registry Code of Conduct.
2. Semi-annual certification of compliance with the Registry Code of Conduct
3. Regular compliance audits
4. Detailed standard operating procedures for working with registrars
5. A dedicated team of compliance professionals
6. 24x7x365 customer support in more than 150 languages
7. An OCI Compliance Plan.

Detailed information about each of these methods and how they contribute to
providing equivalent registrar access are provided below.


Method 1: Semi-Annual Equivalent Access Certification

VeriSign's executive management provides ICANN with a semi-annual certification
confirming compliance with equivalent access requirements. The OCI Plan provides
the foundation for the VeriSign equivalent access policies and practices. A copy
of the most recent VeriSign Equivalent Access Certification was given to ICANN
on 22 October 2004. Additionally, Verisign has provided a list of the questions
required of Verisign for certification. Refer to Section 2, Table 2.1 at
www.verisign.com/nds. Certifications have been continuously provided to ICANN
since October 1999.

Method 2: Semi-Annual Code of Conduct Certification

As with the equivalent access certification, VeriSign closely monitors
compliance with the Code of Conduct requirement. VeriSign employs a vice
president of policy and compliance, as well as a compliance officer to monitor
and ensure that VeriSign's performance is in accordance with the contractual
Code of Conduct requirement. VeriSign provides a summary of how we have
approached each requirement, which is posted at www.verisign.com/nds (Section 2,
Table 2.2). VeriSign complies with the Code of Conduct requirements by
constantly monitoring registrar access to the Shared Registration System (SRS)
and having technical and operational systems in place to ensure that all code of
conduct requirements are met.

Method 3: Regular Compliance Audits

VeriSign is the only gTLD registry that undergoes audits by an internationally
recognized, third-party independent accounting firm to ensure compliance with
equivalent access and code of conduct requirements. VeriSign provides full
access to all materials needed to audit our compliance with equivalent access. A
full list of these materials, as reviewed in conjunction with the annual audit
to validate equivalent access and fair treatment of registrars, is provided at
www.verisign.com/nds (Section 2, Table 2-3). VeriSign provides unfettered access
to operational, financial, marketing, and human resource files related to this
subject matter.

Method 4: Standard Operating Procedures for Processing Newly Accredited Registrars

VeriSign has implemented efficient operational and technical processes to ensure
that each registrar has timely, cost-efficient, and equivalent access to the
systems, tools, and personnel resources that support the .net registry. In
addition, response/escalation procedures are in place to assist registrars in
addressing any challenges. The processes include: certification of registrars,
customer support, registry code of conduct assurance, and technical elements of
equivalent access. Through November 2004, the year-to-date average ramp-up to
production for registrars was 45 days.

Method 5: Dedicated Compliance Team

VeriSign has a dedicated and experienced compliance team, which consists of the
following personnel: Chuck Gomes, Vice President of Policy and Compliance;
Barbara Knight, Compliance Officer; Inez Toppin, Contract Administrator; Suzanne
Yerks, OCI Administrator and Contract Administrator; and Heidi Shalom, OCI Trainer.

Method 6: Customer Service in Multiple Languages and Time Zones

VeriSign offers services and support in all time zones and in 150 languages,
including English. VeriSign believes that superior, prompt customer support to
all registrars is an essential element to the success of any top-level domain
(TLD), but is particularly important to a TLD of the size and critical nature as
.net. Registrars selling .net domain names are accustomed to: 
* 24x7x365 customer support through a team of trained professional customer
service representatives.
* Representatives available to address questions and assist customers in every
time zone at the customer's convenience.
* In language support for 150 languages, including English via VeriSign's
affiliation with Language Line. Language Line is a telephone translation service
also available 24x7x365, enabling VeriSign representatives to communicate
effectively and immediately with all its customers, without additional expense
to the customer. In addition to Language Line, VeriSign employs customer service
representatives in-house who speak Spanish, Farci, and German.
* Established escalation procedures whereby technical, legal, or other issues
are promptly forwarded to the appropriate groups, ensuring suitable,
professional, and timely responses.
* Web-based tools.
* Centralized access to customer service representatives who are trained to
appropriately assess any issue and resolve or escalate it to Engineering,
Operations, Networking personnel, or the Customer Service Manager, as necessary,
to ensure prompt resolution.
VeriSign's current .net registry operator agreement with ICANN provides for the
provision of fair treatment to all registrars. A table that outlines the
provisions of Fair Treatment of ICANN-accredited Registrars per the current
contract is posted at www.verisign.com/nds (Section 2, Table 2-5).

Method 7: OCI Compliance Plan

VeriSign ensures no OCI with the following steps:
* Organizational Structure.  Requirement: .net registry and registrar business
units must be separated into separate business units with different profit and
loss centers, each with different General Managers.  
 - Compliance: VeriSign does not have controlling interest in any .net
registrars. However, other competitors for the current .net bid do have
controlling interest in registrars or are reliant on registrars or governmental
organizations for their profit structure. 
* Financial Separation.  Requirement: In cases where a company owns both a .net
registry and a .net registrar business, the registry business must account for
its own costs, revenues, cash flow, etc. as a separate profit and loss center,
using separate and distinct systems and accounting functions and accounting
controls must in place to ensure the adequacy of these systems and functions.
 - Compliance: VeriSign does not have controlling interest in any .net registrars.
* Location Change.  Requirement: In cases where a company owns both a .net
registry and a .net registrar business, the registry and registrar businesses
must be located in two separate facilities.
 - Compliance: VeriSign does not have controlling interest in any .net registrars.
* Physical Barriers.  Requirement: All facilities must require security badge
access, and only registry assigned personnel and other personnel who are
identified to have a legitimate need for regular badge access to the registry
facility can be given badge access to registry facilities; all other people,
including regular employees, must be treated as visitors to the facility and
gain access only through established visitor sign-in, identification badge, and
escort procedures.
 - Compliance: VeriSign has always, and continues to be, in full compliance with
these requirements. Refer to Part 2, Section 5b(xiii), System Security and
Physical Security, for more detail.
* Access to the Shared Registration System.  Requirement: the registry must
provide access to all ICANN-accredited registrars via the following mechanisms:
all registrars must be able to connect to the Shared Registration Gateway via
the Internet by using the same maximum number of Internet Protocol (IP)
addresses and Secure Sockets Layer (SSL) certificate authentication; all
registrars must be provided the same level of access to registry generated data
to reconcile their registration activities from registry web and file transfer
protocol (FTP) servers; all registrars must be able to perform basic automated
registrar account management functions using the same registrar tool made
available to all registrars by the registry; the Shared Registration System
(SRS) cannot include any algorithms or protocols that differentiate among
registrars with respect to functionality, including database access, system
priorities, and overall performance; no registrar affiliated with the registry
can be given any access to the registry that is not available to any other
registrar, except with regard to information that is specific to that registrar;
and any information needed by registrars regarding the technical interface of
registry/registrar operations must be made available to all registrars.
 - Compliance: VeriSign has always been, and continues to be, in full compliance
with these requirements.
* Information Control.  Requirement: the registry must have procedural
safeguards in place to ensure that data and information of the registry business
are not used to advantage the business of any registrar.
 - Compliance: VeriSign has a policy addressing the marking, accessing, and
dissemination of business sensitive information. This policy requires employees
to mark all registry sensitive information as such. In addition, the policy
requires that all registry sensitive information be limited in access and
disseminated only to those VeriSign personnel and other personnel who are
identified to have a legitimate "need to know."
* Training.  Requirement: All personnel needing access to registry information
or facilities must complete an initial OCI training course and an annual OCI
refresher course.  
 - Compliance: All VeriSign personnel who need access to registry information or
the registry facility are required to complete a formal OCI training course.
* Non-Disclosure Agreement/OCI Avoidance Certifications. Requirement: Upon
completion of the initial OCI training, all VeriSign registry employees and
other employees who have a need to know registry business are required to sign a
Non-Disclosure Agreement and a Registry Business OCI Avoidance Certification,
acknowledging their understanding of the OCI requirements and certifying that
they will strictly comply with the provisions of the OCI Plan.
 - Compliance: All VeriSign employees sign a Nondisclosure Agreement and a
Registry Business OCI Avoidance Certification.


Technical Elements of Equivalent Access

In addition to the organizational and policy methodologies VeriSign uses to
provide equivalent access, VeriSign also makes extensive use of technical and
operational initiatives to ensure equivalent access. The first of two
representative examples of these methods are the new constellations that
VeriSign has placed in non-U.S. countries to help ensure access to the domain
name system all over the world is equivalent to the access in the United States.
In 2004, VeriSign implemented a constellation site in Seoul Korea. In February
2005, an additional site will be implemented in Beijing, China. Also, VeriSign
is committed to continue to expand new sites, including a site in Brazil in
mid-2005.

A second example of VeriSign's technical methods to ensure equivalent access is
the batch pool. In Summer 2000, VeriSign encountered a unique issue that
required immediate action to ensure equivalent access for all registrars.
Increased demand for just-deleted names motivated some registrars to develop
automated batch processes for sending repeated registration add commands to the
registry. This resulted in an unanticipated surge in SRS connection demand. To
ensure equivalent access for all registrars, VeriSign quickly designed and
implemented a registration pool system to address this issue. It ensures each
operational registrar is given equivalent access to the SRS through its use of
connections to various pools: the Guarantee Pool, the Overflow Pool, and
finally, the Automated Batch Pool. This system recognizes and appreciates the
various business models used by registrars, while at the same time providing a
fair and level playing field.

VeriSign designed and implemented this pool system of access to specifically
ensure equivalent access of all registrars, while at the same time accommodating
a previously unknown and very large demand for recently deleted domain names
spurred by a 100-percent increase in registrar accreditations from 2003-2004.
VeriSign has invested significant sums of money to purchase increasing amounts
of hardware to support these pools to continue to provide equivalent access to
registrars.

Since September 2000, VeriSign has worked extensively with registrars, ICANN,
and other community members to develop ways to deal with the re-registration of
deleted names, and thereby, reduce the demand on registry systems in this
regard, while at the same time addressing the market demand. Those efforts are
ongoing at the present time, and VeriSign is committed to continue cooperating
with all stakeholders to decide on a solution that not only addresses current
needs but also future needs. Given the volume of names under management, no
other registry (ccTLD or gTLD) has had to deal with this issue to anywhere near
the same extent as VeriSign. In the interim, VeriSign has ordered and installed
additional front-end hardware to ensure equivalent access for all registrars and
sustained performance capabilities.

Marketing programs
VeriSign is the only registry that consistently and uniformly assists registrars
to better their businesses through marketing efforts and industry research. 
VeriSign designs marketing promotional campaigns for registrars, as well as
designing and reviewing each marketing campaign in an effort to provide
equivalent access and incentive to all registrars. Each campaign is reviewed
with ICANN before launch. In an effort to support all registrars in their
marketing activities, no matter what they might be, VeriSign has offered a new
unit, renewal unit, IDN, and marketing funds promotion program. The marketing
funds promotion provides an incentive to registrars to market in various target
markets, such as underserved markets, consumer markets, and portals. This
enables registrars of all sizes to apply funds earned toward programs that
benefit their businesses. VeriSign will continue to offer marketing programs to
all registrars on an equivalent basis. 


Conclusion

VeriSign provides equivalent registrar access to registry services and systems,
including equivalent and fair treatment by our personnel. VeriSign is the only
registry to have equivalent access compliance certified by an outside auditor. 
We provide our services and support in all time zones in 150 languages,
including English. We currently provide access to our systems via the RRP and
EPP protocol, and have a detailed plan in place for full migration to the EPP.

We recognize the importance of monitoring and maintaining equivalent access and
the fair treatment of all registrars to the continued growth of the Internet. 
The concept of equivalent access is evident in all our product management,
marketing, technical, and operational practices. Our lifecycle management
includes the priority of expanding the breadth of services and offerings to all
registrars equivalently and to opening new markets for all registrars. Our
dedication to the growth of the overall base of the industry benefits all
registrars. To that extent, VeriSign goes the extra distance of opening offices
in all regions to provide localized support. We provide in-region services to
our European, Asian, and North American customers to ensure that service is
available in a timely manner and in language.

Additionally, consideration is given to all registrars in our technical training
and support. Every marketing program release and product update web-based
seminar is given three times to support time zones around the world so that all
registrars can participate. Additionally, our night and weekend teams of
Customer Service and technical staff are trained and skilled to provide equal
support to our customers in non-U.S. based countries and our marketing materials
are provided in-language.

Since the first day new registrars were introduced, VeriSign has continuously
allowed all ICANN-accredited registrars to qualify to register names in the .net
TLD, and treated all qualified registrars equivalently. We also extend the
equivalent access principles to all aspects of our .net registry business:
marketing funds programs, new registry service offerings, and technical
innovations and migrations. We have the mechanisms in place to continue
providing such access in the future and are fully committed to doing so. No
other operator can attest to such extensive and verified methods.

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

VeriSign wrote the EPP protocol. We currently support both Registry Registrar
Protocol (RRP) and Extensible Provisioning Protocol (EPP) while implementing a
smooth, low cost migration from RRP to EPP. 

VeriSign Advantages
+ Employs leading experts in protocol development
+ Experience operating both RRP and EPP
+ Low-cost, smooth transition that offers registrars on-site account management,
schedule flexibility, webex training seminars, an extended RRP duration and
mapping tools for migration ease


VeriSign designed and implemented the Shared Registration System (SRS) in 1998
and 1999 for the specific purpose of allowing fair competition at the registrar
level. From the time that registrar competition was introduced in mid-1999,
access to the SRS has been provided through RRP based on RFC 2832. In 2003
VeriSign initiated discussions with its registrar customers to obtain their
input into a plan for migration to EPP. That plan is now in place and being
implemented. Specific details of the plan for supporting EPP 1.0 are provided
below including:
* Dual Support of RRP and EPP - In response to feedback from registrars,
VeriSign will provide an extended period of dual support of both protocols.
* Schedule for Dual RRP and EPP Operations -An EPP operational test and
evaluation (OT & E) environment was made available for registrars in September
2004. The implementation of EPP into the .net production environment is
scheduled for Q2 2005 at which time dual operations will start for live
registration services.  The end of dual operations will depend on registrar
feedback but is targeted for Q2 2006. 
* Status Mapping between RRP and EPP - A table defining status mappings between
the two protocols is provided in Section 8, Table 8-2-3.
* Status Rules - A table with detailed EPP status rules is provided in Section
8, Table 8-2-4.

VeriSign's methodology in the RRP to EPP transition is an excellent example of
applying equivalent access principles to a technical migration. VeriSign's
extended provision of dual protocol support is designed to provide a low-cost
and flexible way for registrars of all sizes and technical capabilities to make
this transition and thereby not unfairly advantage or disadvantage any
registrar. We often provide registrars special tools to facilitate technical
migrations and whenever we have done that they are made available to all
registrars in the same manner and timeframe (e.g., IDN Race to Punycode
conversion tool). In the RRP to EPP migration effort, special mapping and
migration tools are being provided to all registrars to assist them with the
migration.

The development of VeriSign's migration plan for migrating from RRP to EPP
involved a period of more than 4 years information-gathering and technical
analysis by our engineering, operations and business teams including extensive
feedback from registrars. It specifically includes:
* Implementation of EPP 1.0 in the .net production environment starting in Q2
2005 (as specified in RFCs 3730, 3731, 3732, 3734 and 3735).
* Consideration of implementing RFC 3733 (a thick registry) through discussion
with the ICANN community as discussed below in the subsection titled `Thin vs.
Thick Registry' [Note that RFC 3733 applies to a thick registry only.]
* Significant advance preparation by the registry, much of which has occurred
* A comprehensive operational test environment for registrars
* Tools and technical assistance for registrars
* Extended migration flexibility for registrars to accommodate their varying needs.
As a result, it maximizes the chances of a smooth and low-cost migration path
for registrars.

It is important to recognize that the size of the .net registration base creates
some special challenges for both the registry and registrars in migrating to
EPP. The .net database has more than 5 million names plus 18 million name
servers that need to be migrated by each individual registrar. As a result,
VeriSign has developed a series of tools to ensure that registrars can complete
this migration in a smooth, low cost manner. VeriSign has been particularly
concerned about the impact on registrars and therefore has solicited their input
to make sure that the migration plan is designed in both an effective and
flexible manner that accommodates varying registrar needs while ensuring
security and stability at both the registry and registrar levels. Providing
extended dual support for both protocols is a key aspect of the migration plan;
it allows registrars sufficient time to fit the migration effort into their
development schedules and to do so in a reliable way.


Dual Support of RRP and EPP

VeriSign's dual use of RRP and EPP for the .net registry will continue through
the end of 2006 to minimize undue hardship imposed by a hard cutover.
Transitioning the .net registry from RRP to EPP is a complex task due to the
inherent differences between the two protocols. Operating the SRS with support
for both protocols simultaneously is not a trivial task, and requiring all
registrars to meet a cutover will place a burden on them and creates additional
challenges should one or more registrars not be capable of making the change at
the designated time. VeriSign began communicating with registrars to develop
this transition plan even before the EPP standards were finalized to solicit
feedback and lessons learned from previous registry migrations.

Additionally, the ccTLD registries operated by VeriSign (.tv, .cc and .bz) had
traditionally been available through an RRP SRS that is nearly identical to the
.net registry. In the migration of those ccTLDs to EPP, VeriSign chose to use
the same dual operation transition process before implementing it in .net,
thereby allowing registrars to complete a similar transition in a full
production system before committing to a transition to a larger TLD such as
.net. This dual system is currently in place, thus enabling registrars to gain
experience and prove the success of the dual protocol operation.

The features of this dual protocol operational period ensure that:
* Compatibility with all RRP functionality currently available in .net is
maintained.
* Equivalent Access is preserved
* Registrar Console capabilities are enhanced through expanded web tool
functionality
* Reports for registrars are unchanged
* Whois format is modified to return EPP statuses
* Batch Pool automated processes using RRP remain unchanged
* Transfers of domain names between RRP and EPP registrars are enabled
* Enhanced features such as Redemption Grace Period (RGP), IDN, ConsoliDate, and
IPv6 are available through both protocols.
* Fully redundant platform with support for both RRP and EPP offers scalability,
availability, and extensibility demanded by registrars and necessary for
operation of .net. A detailed diagrams of this EPP/ RRP gateway interaction can
be found in Section 8, Figure 8-2-1.  
* Schedule for Dual RRP and EPP Operations

Dual protocol operations and an extended implementation schedule are critical
elements in the provision of a smooth migration path to EPP. VeriSign began
offering an EPP 1.0 OT&E environment in September 2004 to allow registrars an
extended period of time to develop and test their systems and to provide
feedback on the technical implementation. Additionally, the dual operation of
RRP and EPP is being proven through our offering of simultaneous RRP and EPP
support for .bz, .cc, and .tv.

VeriSign currently supports a draft, working version of .net in EPP 1.0 in our
OT&E environment. The implementation of EPP into the .net registry production
environment is scheduled for the second quarter of 2005. At that time, an
extended period for registrar migration will begin on a schedule that is
amenable to their development schedules. The existing RRP implementation will
continue to be operational and supported even after the introduction of EPP.
This period of RRP-EPP parallel operations will mitigate operational risk to
registrars and minimize impact to their business operations and development
schedules. VeriSign account management has a calendar of agreed upon migration
dates for most registrars.

The migration from RRP will begin with the introduction of the EPP
implementation into the .net registry production environment in the second
quarter of 2005. The existing RRP implementation will continue to be operational
and supported even after the introduction of EPP. This period of RRP-EPP
parallel operations, enabled by the VeriSign Registrar Console (described
earlier and depicted in Section 8, Figure 8-2-2) will mitigate operational and
technical risk to registrars.

We will also support and encourage the adoption of EPP through a number of
additional tools used in the transition to EPP in other domains. These are
explicitly designed to promote low-cost, low-risk migration. To achieve these goals:
* VeriSign will provide a development and Beta test environment where registrars
can test new software systems prior to live operation.
* We will offer a JAVA-based software development kit (SDK) to facilitate the
modification of registrar systems that will integrate with the EPP platform.
* We have developed an EPP tool called REST that generates EPP Extensible Markup
Language (XML) and that can be used in conjunction with the SDK to increase
registrar familiarity with the EPP protocol and formats.
* We will conduct web seminars, provide transition documentation to the
registrar community, and offer technical resources that will support registrar
transition.

While the timing of the transition to EPP will be at the discretion of
registrars, the RRP implementation will be completely replaced by EPP at a time
determined jointly by VeriSign, ICANN, and the registrar community. Our
objective is to provide registrars sufficient time to transition at a time that
best fits their development schedule without constraint of a hard cut-over.
While we have the ability to cut-over to EPP very quickly, our plan is to
complete the transition no earlier than 2Q 2006 to meet the needs of our customers.


Thin vs. Thick Registry

The current .net registry is commonly referred to as a `thin' registry.  In
contrast to a `thick' registry where the registry database contains registrant
and contact information along with name server information, a `thin' registry
database contains only domain name, registrar and name server information.
Section 8, Figure 8-2-3 compares the data maintained by `thin' and `thick'
registries.

In working with the registrar community to evaluate the issue of migrating the
.net registry from thin to thick, VeriSign found that:
* Based on lessons learned from the .org migration from RRP to EPP including
feedback from registrars, if a migration to a thick registry is considered, it
should be performed as a totally separate migration from the protocol migration
to avoid over-complication of the EPP migration and thereby ensure a smooth
transition.
* Based on registrar feedback, the majority of registrars prefer a thin registry
model. A primary reason for this is that they perceive there to be a loss of
control of their customer data as is illustrated in Section 8, Table 8-2-3. A
secondary reason is that migrating customer data adds costs to registrars for
which many of them do not recognize any value plus they have the ongoing cost
and responsibility of ensuring that registry data is synchronized with registrar
data.
* Considering the work currently underway in the ICANN Generic Names Supporting
Organization's Whois task forces and the work nearing completion in the Internet
Engineering Task Force CRISP working group on the IRIS protocol, a primary value
of the thick registry model may be diminished. A key advantage of thick data at
the registry level is to facilitate a centralized Whois service instead of
having to search the Whois of many different registrars. The IRIS protocol
provides a way of implementing a centralized domain name lookup service through
a distributed architecture that would not require thick registry data.

Therefore, VeriSign proposes that the .net registry remain a thin registry at
least until such time that the work of the Whois task forces is completed and
the IRIS protocol becomes a recognized standard. At that time, if the Internet
community through ICANN processes develops a consensus policy that supports a
thick registry, VeriSign will make the transition.

VeriSign took the following steps to develop its EPP 1.0 migration plan:
* Analysis of registry technical requirements including detailed review of RFC
specifications
* Analysis of registrar technical requirements with particular focus on
operational impact
* Solicitation of registrar feedback with regard to migration time constraints,
business needs and technical development requirements
* Consideration of issues encountered in the .org RRP to EPP migration
* Integration of all of the above into a plan that maximizes the chances of a
smooth migration with minimal impact on registrars and registrants and minimizes
any chance of encountering security or stability issues. The plan:
 - Includes a lengthy operational test environment for registrars that started
in 2003
 - Provides for dual support of RRP and EPP for an extended period of time and
thereby avoids the pitfalls associated with a hard cutover to EPP by in excess
of 250 registrars
 - Thoroughly addresses issues related to differences in statuses in the two
protocols by clearly defining status mapping between RRP and EPP and by
explicitly listing status rules
 - Includes a migration schedule that allows for a reliable migration by all
registrars while at the same time providing registrar flexibility to best fit
their migration efforts into their business plans
 - Calls for registry provided tools to facilitate registrar migration tasks.
See chart of status mapping commands located in Section 8, Table 8-2-1.  
 - Balances ICANN compliance requirements with cooperation between registry and
registrars
 - Maximizes the chances of a seamless migration for registrants.
This plan is based on over a year of information gathering and technical
analysis and reflects the knowledge and experience of the VeriSign technical and
operations teams and feedback of registrars. As a result, it maximizes the
chances of a smooth and low-cost migration path from RRP to EPP by providing
for: significant advance preparation by the registry, much of which has already
happened; a lengthy operational test environment for registrars; tools and
technical assistance for registrars; and extended flexibility to accommodate
varying registrar needs.


Conclusion

VeriSign currently provides and will continue to provide all ICANN-accredited
registrars equivalent access to register names in .net. VeriSign currently
supports RRP and EPP and is implementing a smooth, low cost migration from RRP
to EPP while continuing to support both protocols. VeriSign has been and
continues to be the leader in the industry for equivalent access.
* VeriSign supports 150 languages, including English, with an abandon rate <2
percent, and 94 percent of all calls answered within 20 seconds, and 99 percent
of emails answered within 24 hours.
* VeriSign currently support 250+ registrars internationally and 10,000+
resellers internationally and the ability to support over 500 registrars by the
end of 2005. To maintain this level of equivalent support, VeriSign spends over
$3 million annually to ensure equivalent access to the Shared Registration
System. Other operators do not meet this standard. In fact, Afilias has only 195
registrars, NeuLevel has 132 registrars and DENIC has 216 registrars (as of
September 2004). 
* Provide programs that increase registrars in new markets throughout the world,
support existing registrars marketing and technical needs. VeriSign spends over
$5 million annually to ensure equivalent access. Competitors do not provide
marketing programs on an equivalent basis to registrars of all sizes.

Additionally, in assessing the ability of prospective .net operators to meet
ICANN's equivalent access requirements, it is important to consider the following:
* VeriSign provides a demonstrated method to ensure a smooth and low cost
migration from RRP to EPP including the demonstrated ability to operate both RRP
and EPP during this migration period for at least one year. Other operators have
not demonstrated the ability to execute on a smooth, low cost migration.
* VeriSign's equivalent access practices are audited annually. All claims of
equivalent access should be certified and audited by an independent nationally
recognized firm on an annual basis at its own cost (VeriSign has spent over
$400,000 on such audits). Other registry operators have never conducted audits
for their Internet registry businesses. 
* VeriSign is able to offer equivalent access to all programs and services
because it is not influenced by the investment or controlling interest of any
registrar or government entity. Any applicant should prove that it is not under
the control of, nor influenced by, a substantial financial or organizational
relationship with one or more registrars or government entities. Other
operators, specifically NeuLevel and Afilias were created by, and are controlled
in part by a registrar, and DENIC is a quasi government agency whose stated
focuses is the German internet community. VeriSign has established practices in
place to ensure compliance under any and all circumstances. With the divestiture
of Network Solutions last year, there can be no concern for such conflicts to
arise as could be the case with other registry operators.
* VeriSign abides by a Code of Conduct. All applicants should be required to
prove the existence and implementation of a Registry Code of Conduct No other
operators have proven methods to enforce employee compliance with a Registry
Code of Conduct.
   

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

Nameserver operations for the Registry TLD shall comply with RFC 1034,
1035, and 2182.

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

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

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

For Updates and Upgrades, VeriSign 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 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. VeriSign will maintain the Update or Upgrade in the
OT&E environment for at least thirty (30) days, to allow each registrar the
opportunity to modify its client applications and complete testing, before
implementing the new code in the production environment.

This notice period shall not apply in the event Registry Operator's system is
subject to the imminent threat of a failure or a material security threat, or
the discovery of a major security vulnerability or urgent registrar/market
demand, or a Denial of Service (DoS) attack where the Registry Operator's
systems are rendered inaccessible by being subject to:
i) excessive levels of data traffic
ii) unauthorized traffic
iii) data traffic not conforming to the protocols used by the Registry
Operator's system.

Appendix D, Performance Specifications

1. Introduction. The VeriSign, Inc. ("Registry Operator") registry provides
world-class service to its customers. This set of Performance Specifications
provides a means to measure Registry Operator's delivery of SRS, DNS Name Server
and Whois services for the Registry TLD. 


2. Definition. Capitalized terms used herein and not otherwise defined shall
have the meaning ascribed to them in the Registry Agreement, including, but not
limited to, Appendix E thereto. (See definitions in Table D-1).


3. Performance Specifications. The Performance Specifications set forth in this
Section 3 establish the standards to which the Registry Operator's System
Services will be measured and serve as the basis for the Service Level
Agreements Credits ("SLA Credits") provided for in Appendix E.


3.1 Service Availability. Service availability is defined as the time, in
minutes, that the Registry Operator's System Services (SRS, DNS Name Server and
Whois) are individually responding to its users ("Service Availability") as
further defined in sections 3.1.1 through 3.1.3. 

3.1.1 Service Availability is measured as follows:
Service Availability % = {[(MTM - POMU) - UOM] / (MTM - POMU)}*100 where:
MTM = Monthly Timeframe Minutes calculated as the number days in that month
times 24 hours times 60 minutes.  For example, the MTM for January is 31 days *
24 hours * 60 minutes or MTM = 44,640 minutes.
POMU = Planned Outage Minutes Used is the number of minutes of a Planned Outage
or Extended Planned Outage Used for that Monthly Timeframe for each individual
System Service.  No Monthly Timeframe shall have both a Planned and an Extended
Planned Outage.
UOM = Unplanned Outage Minutes 
The Service Availability calculation shall be calculated by the Registry
Operator and the results reported for each Monthly Timeframe for SRS, Whois and
DNS Name Server availability. Results will be reported to the Registrar
Community via e-mail and to ICANN according to Appendix T.

3.1.2 Service Availability--SRS = 99.99% per Monthly Timeframe. Service
Availability as it applies to the SRS refers to the ability of the SRS to
respond to ICANN-Accredited Registrar(s) that access and use the SRS through the
EPP/RRP protocols. SRS unavailability, except for Planned Outages (as defined in
Section 3.2 below) and Extended Planned Outages (as defined in Section 3.3
below), will be logged with the Registry Operator as Unplanned Outage Minutes.
Unavailability will not include the effects from a Planned Outage or any events
affecting individual ICANN-Accredited Registrars locally.
SRS unavailability as it applies to the SRS shall mean when, as a result of a
failure of systems within the VeriSign Registry's control, an ICANN-Accredited
Registrar is unable to establish a session with the SRS gateway. Establishing a
session with the SRS gateway shall be defined as:
a) successfully complete a TCP session start,
b) successfully complete the SSL authentication handshake, and
c) successfully complete the registry registrar protocol (RRP) session command
or the Extensible Provisioning Protocol(EPP) login command.
Registry Operator will log SRS unavailability once an ICANN-Accredited Registrar
reports an occurrence to Registry Operator's customer service help desk in the
manner required by the Registry Operator (i.e., e-mail, fax, telephone). The
committed Service Availability for SRS is 99.99% per Monthly Timeframe.  The SRS
Availability metric is a Credit Level 2.

3.1.3 Service Availability--DNS Name Server = 100% per calendar month. Service
Availability as it applies to the DNS Name Server refers to the ability of the
DNS Name Server to resolve a DNS query from an Internet user. DNS Name Server
unavailability will be logged with the Registry Operator as Unplanned Outage
Minutes. Registry Operator will log DNS Name Server Service unavailability (a)
when such unavailability is detected by monitoring tools described in Exhibit A,
or (b) once an ICANN-Accredited Registrar reports an occurrence to Registry
Operator's customer service help desk in the manner required by the Registry
Operator (i.e., e-mail, fax, telephone) and Registry Operator confirms that the
occurrence is not unique to the reporting registrar. 
DNS Name Server unavailability shall mean when less than eight (8) sites on the
Registry Operator's constellation are returning answers to queries with less
than 1% packet loss averaged over a Monthly Timeframe or 5% packet loss for any
five minute period. 
The committed Service Availability for DNS Name Server is 100% per calendar
year.  The DNS Name Server Availability metric is a Credit Level 1.

3.1.4 Service Availability--Whois = 100% per Monthly Timeframe. Service
Availability as it applies to Whois refers to the ability of all users to access
and use the Registry's Whois service. Whois unavailability will be logged with
the Registry Operator as Unplanned Outage Minutes. Registry Operator will log
Whois Service unavailability (a) when such unavailability is detected by
monitoring tools described in Exhibit A, or (b) once an ICANN-Accredited
Registrar reports an occurrence to Registry Operator's customer service help
desk in the manner required by the Registry Operator (i.e., e-mail, fax,
telephone). The committed Service Availability for Whois is 100% per Monthly
Timeframe.  The Whois availability metric is a Credit Level 2.

3.2 Planned Outage. From time to time the Registry will require an outage for
regular maintenance or the addition of new functions or features.  Allowing for
regular scheduled maintenance ("Planned Outage") helps ensure a high level of
service for the Registry and continued ICANN-Accredited Registrar satisfaction. 

3.2.1 Planned Outage Duration. The Planned Outage Duration defines the maximum
allowable time, in minutes, that the Registry Operator is permitted to take the
System Services out of service for regularly scheduled maintenance ("Planned
Outage Duration"). Planned Outages are planned in advance and the Registrar
Community is provided notification prior to an outage. The Planned Outage
Duration for the System Services is as follows:
(i) Planned Outage Duration - SRS = 45 minutes per Monthly Timeframe;
(ii) Planned Outage Duration - DNS Name Server = no Planned Outages allowed; and
(iii) Planned Outage Duration - Whois = no Planned Outages allowed. 
The Planned Outage Duration metric is a Credit Level 6.

3.2.2 Planned Outage Timeframe. The Planned Outage Timeframe defines the hours
and days in which a Planned Outage can occur ("Planned Outage Timeframe"). The
Planned Outage Timeframe for the System Services is as follows:
(i) Planned Outage Timeframe - SRS = 0100-0900 UTC Sunday;
(ii) Planned Outage Timeframe - DNS Name Server = no Planned Outages allowed; and
(iii) Planned Outage Timeframe - Whois = no Planned Outages allowed.
The Planned Outage Timeframe metric is a Credit Level 5.

3.2.3 Planned Outage Notification. The Registry Operator shall notify all
ICANN-Accredited Registrars of any Planned Outage ("Planned Outage
Notification"). The Planned Outage Notification shall set forth the date and
time of the Planned Outage. The number of days prior to a Planned Outage that
the Registry Operator shall notify its ICANN-Accredited Registrars is as follows:
(i) Planned Outage Timeframe - SRS = 30 days for general maintenance and 90 days
for Updates or Upgrades as defined in the Patch, Update and Upgrade Policy;
(ii) Planned Outage Timeframe - DNS Name Server = no Planned Outages allowed; and
(iii) Planned Outage Timeframe - Whois = no Planned Outages allowed.
The Planned Outage Notification metric is a Credit Level 5.

3.3 Extended Planned Outage. In some cases, such as major software upgrades and
platform replacements, an extended maintenance timeframe is required ("Extended
Planned Outage"). Extended Planned Outages will be less frequent than regular
Planned Outages but their duration will be longer.

3.3.1 Extended Planned Outage Duration. The Extended Planned Outage Duration
defines the maximum allowable time, in hours and minutes that the Registry
Operator is permitted to take the System Services out of service for extended
maintenance ("Extended Planned Outage Duration"). Extended Planned Outages are
planned in advance and the Registrar Community is provided notification in
accordance with Section 3.3.3. Extended Planned Outage periods may not occur in
the same Monthly Timeframe as a Planned Outage. The Extended Planned Outage
Duration for the System Services is as follows:
(i) Extended Planned Outage Duration - SRS = 4 hours (240 minutes) per calendar
year and one Extend Planned Outage of 8 hours (480) minutes every three years.
(ii) Extended Planned Outage Duration - DNS Name Server = no Planned Outages
allowed; and
(iii) Extended Planned Outage Duration - Whois = no Planned Outages allowed.
The Extended Planned Outage Notification metric is a Credit Level 6.

3.3.2 Extended Planned Outage Timeframe. The Extended Planned Outage Timeframe
defines the hours and days in which the Extended Planned Outage can occur
("Extended Planned Outage Timeframe"). The Extended Planned Outage Timeframe for
the System Services is as follows:
(i) Extended Planned Outage Timeframe - SRS = 0100 - 1300 UTC Sunday;
(ii) Extended Planned Outage Timeframe - DNS Name Server = no Planned Outages
allowed); and
(iii) Extended Planned Outage Timeframe - Whois = no Planned Outages allowed.
The Extended Planned Outage Notification metric is a Credit Level 5.

3.3.3 Extended Planned Outage Notification. The Registry Operator must notify
all of its ICANN-Accredited Registrars of any Extended Planned Outage ("Extended
Planned Outage Notification"). The Extended Planned Outage Notification shall
set forth the date and time of the Extended Planned Outage. The number of days
prior to an Extended Planned Outage that the Registry Operator must notify its
ICANN-Accredited Registrars is as follows:
(i) Extended Planned Outage Timeframe - SRS = 90 Days;
(ii) Extended Planned Outage Timeframe - DNS Name Server =no Planned Outages
allowed; and
(iii) Extended Planned Outage Timeframe - Whois = no Planned Outages allowed.
The Extended Planned Outage Notification metric is a Credit Level 5.

3.4 Processing Time. Processing time is an important measurement of
transaction-based services like the System Services.  Service Availability,
including Planned Outages and Extended Planned Outages, measures the amount of
time that the service is available to its users. Processing time measures the
quality of Service Availability.
Processing Time refers to the Round-trip for the System Services ("Processing
Time"). Since each of the System Services has a unique function the Performance
Specifications Processing Times are unique to each System Services. 
Processing Time Performance Specifications will be measured in a Monthly
Timeframe and will be reported on a monthly basis to ICANN in accordance with
Appendix T. The Registry Operator will log the Processing Time for all of the
protocol transactions (i.e. Check, Add/Create, Modify/Update and Delete).

3.4.1 Processing Time--Check Domain = 25 milliseconds for 95%.
(i) Processing Time - Check Domain is applicable to the SRS as accessed through
the RRP and EPP protocols as defined in Appendix C. It measures the Processing
Time for an availability check of a specific domain name.
(ii) The performance specification is 25 milliseconds for 95% of the
transactions. That is, 95% of the transactions during a Monthly Timeframe will
take 25 milliseconds or less from the time the Registry Operator receives the
query to the time it provides a response as to the domain name's availability.
The Processing Time for Check Domain metric is Credit Level 3.

3.4.2 Processing Time--Add/Create = 50 milliseconds for 95%.
(i) Processing Time - Add/Create to the SRS as accessed through the RRP and EPP
protocols defined in Appendix C. It measures the Processing Time for add/create
associated with domain names.
(ii) The Performance Specification is 100 milliseconds for 95% of the
transactions processed. That is, 95% of the transactions during a Monthly
Timeframe will take 100 milliseconds or less from the time the Registry Operator
receives the request to the time it provides a response.
The Processing Time for Add/Create metric is Credit Level 3.

3.4.3 Processing Time--Modify/Update and Delete Domain = 100 milliseconds for 95%.
(i) Processing Time - Modify/Update and Delete is applicable to the SRS as
accessed through the RRP and EPP protocols defined in Appendix C. It measures
the Processing Time for modify/update and delete transactions associated with
domain names.
(ii) The Performance Specification is 100 milliseconds for 95% of the
transactions processed. That is, 95% of the transactions during a Monthly
Timeframe will take 100 milliseconds or less from the time the Registry Operator
receives the request to the time it provides a response.
The Processing Time for Modify/Update and Delete metric is Credit Level 3

3.4.4 Processing Time--Whois Query = 5 milliseconds for 95%.
(i) Processing Time - Whois Query is applicable to the Whois and measures the
Processing Time for a Whois Query.
(ii) The Performance Specification is 5 milliseconds for 95% of the
transactions. That is, 95% of the transactions during a Monthly Timeframe will
take 5 milliseconds or less from the time the Whois receives a query to the time
it responds.
The Processing Time for Whois Query metric is Credit Level 3.

3.4.5 Processing Time--DNS Name server Resolution = 100 milliseconds for 95%.
(i) Processing Time - DNS Name Server Resolution is applicable to the DNS Name
Server. It measures the processing time for a DNS query.
(ii) The Performance Specification is 100 milliseconds for 95% of the
transactions. That is, 95% of the transactions during a Monthly Timeframe will
take 100 milliseconds or less from the time name server receives the DNS query
to the time it provides a response.
The Processing Time for DNS Name Server metric is Credit Level 3.
3.5 Update Frequency. The Registry Operator makes timely updates to the data on
the DNS Name Servers and Whois. ICANN-Accredited Registrars record these updates
through the SRS. The SRS then updates the DNS Name Server and the Whois.
Registry Operator processes this updates on a near real time basis. 
The committed performance specification with regards to update frequency for
both the DNS Name Server and the Whois is 3 minutes for 95% of the transactions
during a Monthly Timeframe. That is, 95% of the updates to the DNS Name Servers
and Whois during a Monthly Timeframe will be completed within 3 minutes. This is
measured from the time that the registry confirms the update to the time the
update appears in the DNS Name Server and Whois. Update frequency performance
will be reported on a monthly basis.

3.5.1 Update Frequency--DNS Name Server = 3 minutes for 95%.
The Update Frequency--DNS Name Server metric is Credit Level 4.

3.5.2 Update Frequency--Whois = 3 minutes for 95%.
The Update Frequency--Whois metric is Credit Level 4.

3.6 Cross-Network Name server Performance Requirements. DNS Name Server
Round-trip and packet loss from the Internet are important elements of the
quality of service provided by the Registry Operator. These characteristics,
however, are affected by Internet performance and, therefore, cannot be closely
controlled by Registry Operator. Accordingly, these requirements are not matters
subject to SLA Credits under the Service Level Agreement (Appendix E).
The committed performance specification for cross-network name server
performance is a measured Round-trip of under 100 milliseconds and measured
packet loss of under 1% averaged over the course of a Monthly Timeframe and no
greater than 5% for any five (5) minute period over the course of a Monthly
Timeframe. Cross-network name server performance measurements may be conducted
by ICANN at times of its choosing, in the following manner:

3.6.1 The measurements will be conducted by sending strings of DNS request
packets from each of four measuring locations to each of the .net DNS Name
Servers and observing the responses from the .net DNS Name Servers. (These
strings of requests and responses are referred to as a "CNNP Test".) The
measuring locations will be four root name server locations (on the US East
Coast, US West Coast, Asia, and Europe).

3.6.2 Each string of request packets will consist of 100 UDP packets at 10
second intervals requesting nameserver(NS) records for arbitrarily selected .net
second-level domains, preselected to ensure that the names exist in the Registry
TLD and are resolvable. The packet loss (i.e. the percentage of response packets
not received) and the average round-trip time for response packets received may
be noted.

3.6.3 To meet the packet loss and Round-trip requirements for a particular CNNP
Test, all three of the following must be true:

3.6.3.1 The Round-trip and packet loss from each measurement location to at
least one .net name server must not exceed the required values.

3.6.3.2 The packet loss to each of the .net name servers from at least one of
the measurement locations must not exceed the required value.

3.6.4 Any failing CNNP Test result obtained during an identified Core Internet
Service Failure shall not be considered.

3.6.5 To ensure a properly diverse testing sample, ICANN will conduct the CNNP
Tests at varying times (i.e. at different times of the day, as well as on
different days of the week). Registry Operator may only be deemed to have failed
to meet the cross-network name server performance requirement only if the .net
name servers fail (see Section 3.6.3 above) the CNNP Tests with no less than
three consecutive failed CNNP Tests. to be considered to have persistently failed.

3.6.6 In the event of persistent failure of the CNNP Tests, ICANN will give
Registry Operator written notice of the failures (with backup data) and Registry
Operator will have sixty days to cure the failure.

3.6.7 Sixty days prior to the commencement of testing under this provision,
ICANN will provide Registry Operator with the opportunity to evaluate the
testing tools and procedures to be used by ICANN. In the event that Registry
Operator does not approve of such tools and procedures, ICANN will work directly
with Registry Operator to make necessary modifications.


4. Responsibilities of the Parties.

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

4.2 The Registry Operator will publish system performance and availability
reports monthly. 

4.3 The Registry Operator will provide the Whois Service as specified in
Appendices C and O.

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

5. Miscellaneous.

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


Appendix E, Service-Level Agreement

The VeriSign, Inc. ("Registry Operator") registry strives to provide a
world-class level of service to its customers. This Service Level Agreement
("SLA") provides remedies in the form of SLA Credits (as defined in Section 2
below) should the operational performance of the Registry Operator fall below
certain Performance Specifications identified in Appendix D. 

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

2. SLA Credits. 
If the Registry Operator fails to meet the Performance Specifications defined in
Appendix D to which Credit Levels apply, the Registry Operator shall pay credits
to ICANN-Accredited Registrar(s) or an ICANN fund established for the benefit of
the Registrar Community ("Registrar Community Fund") in accordance with the
identified Credit Level for each of the Performance Specifications metrics,
calculated in accordance with the Credit Level tables set forth in this Section
2 ("SLA Credit"). The SLA Credit due to each ICANN-Accredited Registrar shall be
paid as an offset to registrations and other fees owed to Registry Operator by
ICANN-Accredited Registrar. The SLA Credit represents the total credits,
penalties and/or liabilities that may be assessed to the Registry Operator for a
breach of the Performance Specifications set forth in Appendix D. All SLA
Credits shall be paid in U.S. Dollars. The Credit Level Table (Refer to Table
E-1) indicates the corresponding Credit Level for each Performance Specification
for which Credit Levels apply.

(See Table E-1)

2.1 Credit Level 1 - Credit Level 1 is assessed for DNS Name Server Availability
less than 100% per Monthly Timeframe. If an availability Performance
Specifications is not met, the SLA Credit for Credit Level 1 shall be payable to
a Registrar Community Fund 30 days after the applicable calendar month in
accordance with Table Credit Level 1 (Refer to Table E-2). 

2.2 Credit Level 2 - Credit Level 2 is assessed for SRS Availability less than
99.99% per Monthly Timeframe and for Whois Availability less than 100% per
Monthly Timeframe. If an availability Performance Specifications metrics is not
met, the SLA Credit for Credit Level 2 shall be credited directly to
ICANN-Accredited Registrar(s) in an amount equal to the sum of the duration of
the outage times (OT) and the average daily number of .net registrations over
the previous three (3) months (NRAvg) times the .net wholesale fee divided by
the number of minutes per day (1,440 minutes).  Additionally, for any month
where the total combined Unplanned Outage of SRS and Whois is greater than 30
minutes, Registry Operator will credit ICANN One Thousand Dollars ($1,000) for
every active ICANN-Accredited Registrar. For purposes of this Appendix E, an
"active" ICANN-Accredited Registrar is one who has registered greater than 150
new .net domain names in the previous Monthly Timeframe.
Each active registrar would be credited:

(.net Registry Fee)*(OT)*(NRAvg)
(1,440 minutes)

2.3 Credit Level 3 - Credit Level 3 is assessed for failure to meet the
Performance Specifications for the Processing Time for check domain, add/create,
modify/update and delete domain commands, and DNS Name Server and Whois queries.

If the Processing Time Performance Specifications metrics are not met, the SLA
Credit for Credit Level 3 (Refer to Table E-3) shall be payable to ICANN in an
amount based upon the percent of time that the Processing Time exceeds the
applicable Performance Specifications metric. Registry Operator will issue SLA
credit(s) for each Processing Time Performance Specification  not met to ICANN
within 30 days after the applicable calendar month.


2.4 Credit Level 4 - Credit Level 4 is assessed for failure to meet the
Performance Specifications for update frequencies for DNS Name Server and Whois.
If the update frequency Performance Specifications metrics are not met, the SLA
Credit for Credit Level 4 (Refer to Table E-4)shall be payable to ICANN in an
amount based upon the % of time that the update frequency exceeds the applicable
Performance Specifications metric; provided, however, that SLA Credits shall not
be available for Whois update frequency until January 2006.

2.5 Credit Level 5 - Credit Level 5 is assessed for failure to meet the Extended
Planned Outage Notification Performance Specifications. If the Extended Planned
Outage Notification Performance Specifications metrics is not met, the SLA
Credit for Credit Level 5 shall be payable to ICANN in an amount equal to One
Thousand Dollars ($1,000). 

2.6 Credit Level 6 - Credit Level 6 is assessed for failure to meet the Extended
Planned Outage Duration Performance Specifications. If the Extended Planned
Outage Duration Performance Specifications metrics is not met, the SLA Credit
for Credit Level 6 shall be payable directly to ICANN-Accredited Registrar(s) in
an amount equal to the Average Daily Volume (ADM) of net new adds as averaged
over the course of the previous three months times the Planned Duration Overage
(PDO) in minutes times a graduated financial penalty. Refer to Table E-5.

3. Registrar Responsibilities.
In order for ICANN-Accredited Registrars to claim SLA Credits outlined in this
SLA, the procedures of this Section 3 must be strictly followed.

3.1 The affected ICANN-Accredited Registrar must report each occurrence of
alleged failure by Registry Operator to meet a Performance Specification and
make a request for SLA Credit to the Registry Operator customer service help
desk in the manner required by the Registry Operator (i.e., e-mail, fax,
telephone) in order to be eligible for a SLA Credit. 

3.2 ICANN-Accredited Registrar(s) must inform the Registry Operator any time its
estimated volume of transactions (excluding check domain commands), will exceed
ICANN-Accredited Registrar's previous month's volume by more than 25%. In the
event that ICANN-Accredited Registrar fails to inform Registry Operator of a
forecasted increase of volume of transactions of 25% or more and the
ICANN-Accredited 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 ICANN-Accredited Registrars for that month exceed the Registry
Operator's actual volume of the previous month's transactions by more than 20%,
then ICANN-Accredited Registrar will not be eligible for any SLA Credits
outlined in this SLA in that Monthly Timeframe. ICANN-Accredited Registrar shall
provide such forecast 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.

3.3 The affected ICANN-Accredited Registrar must provide documentation to
support its claim for a SLA Credit. An ICANN-Accredited Registrar shall provide
documentation in the form of either:

a) ICANN-Accredited Registrar initiated notification(s) to the Registry Operator
of a Performance Specification 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 trouble
ticket includes this); or

b) Notification from the Registry Operator (with trouble ticket number attached)
of a Performance Specification that exceeded SLA limits. The closing ticket(s)
should be included as well in order to determine the total downtime (unless the
trouble ticket includes this).

3.4 In order to calculate credits, the affected ICANN-Accredited Registrar must
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 period.

3.3.3 Registry Operator shall perform the required measurements in order to
corroborate the total SLA Credits requested by ICANN-Accredited Registrar. Such
measurements and associated documentation shall be delivered by e-mail to each
of the ICANN-Accredited Registrars requesting a SLA Credit.  Such notice shall
also include the total SLA Credit (if any) to be paid to the Registrar Community.

3.4 When the above steps have been completed to Registry Operator's
satisfaction, Registry Operator shall provide notification of the number of SLA
Credits that will be entered in the affected ICANN-Accredited Registrar's
account that can be used immediately toward .net domain name registrations and
other fees owed to Registry Operator by ICANN-Accredited Registrar.


4. Obligations.

4.1 Except in the case of cross-network name server performance (which is not a
subject of this Service Level Agreement), Registry Operator will perform
monitoring from at least two external locations and a minimum of one internal
location as a means to verify that a) sessions can effectively be established
and b) RRP/EPP commands can be successfully completed.

4.2 In the event that all ICANN-Accredited Registrar are affected by an SRS
unavailability, the Registry Operator is responsible for opening a blanket
trouble ticket and immediately notifying all ICANN-Accredited Registrar of the
trouble ticket number and details. 

4.3 In the event that the System Services are unavailable to an individual
ICANN-Accredited Registrar, Registry Operator will use commercially reasonable
efforts to re-establish the affected System Services for such ICANN-Accredited
Registrar as soon as reasonably practicable. Any System Services unavailability
attributable to individual ICANN-Accredited Registrars that does not represent a
System Services outage will not be eligible for SLA Credits or subject to this SLA.

4.4 ICANN-Accredited Registrar(s) and the Registry Operator agree to use
reasonable commercial good faith efforts to establish the cause of any alleged
System Services unavailability. If it is mutually determined to be a Registry
Operator problem, the period of unavailability will be subject to this SLA

4.5 The Registry Operator will use commercially reasonable efforts to restore
any System Services within 24 hours after the termination of a force majeure
event and restore full system functionality within 48 hours after the
termination of a force majeure event. Outages due to a force majeure will not be
considered System Services unavailability, impact the Performance Specifications
set forth in Appendix D or be subject to this SLA.

4.6 The Registry Operator will open incident trouble tickets within a
commercially reasonable period of time and 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 subject to this SLA.

4.7 This SLA will be reconciled on a quarterly basis and unless otherwise
specified in this SLA, SLA Credits will be issued on a quarterly basis.

4.8 The Registry Operator will publish monthly system performance and
availability reports. 


5. Miscellaneous.

5.1 This SLA is independent of any rights, obligations or duties set forth in
the Registry Agreement. In the event of any conflict between the terms and
conditions of this SLA and the Registry Agreement, the Registry Agreement shall
control.

5.2 As an addendum to the Registry-Registrar Agreement ("RRA"), no provision in
this addendum is intended to replace any term or condition in the RRA.

5.3 Dispute Resolution will be handled per RRA Section 6.7.

5.4 Any interruption of System Services that occurs, as a direct result of RRA
Sections 2.12, 5.4, or 6.3 or any other applicable RRA contract term, will not
be subject to this SLA.


Appendix O*, Whois Specification – Public Whois

Appendix O 
Whois Specification - Public Whois

Registry Operator's .net Whois service is the authoritative Whois service for
directory service data for the .net top-level domain. This service contains data
about .net second-level domain names, associated name servers and respective
registrars. This is a public query service available on the Internet. 

Registry Operator shall provide public Whois access via RFC 3912 compliant port
43 protocol, a Web-based service available at Registry Operator's web site, and
an IRIS compliant protocol no later than 180 days after the IETF specification
is adopted as a Proposed Standard.

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.

RFC 3912 Whois
To use Registry Whois via port 43 enter the applicable parameter via an RFC 3912
compliant client as illustrated below: 
* For a domain name: whois "domain Registry Operator.com"
* For a registrar name: whois "registrar Network Solutions, Inc."  
* For a name server: whois "nameserver ns1.netsol.com" or whois "nameserver
192.5.6.30"   

By default, Whois performs a very broad search, looking in all record types for
matches to your query in these fields: domain name, nameserver name, nameserver
IP address, and registrar names. 

Use keywords to narrow the search (for example, 'domain root'). Specify only
part of the search string to perform a "partial" search on domain. Every domain
starting with the string will be found. A trailing dot (or dots) after your text
or the partial keyword indicates a partial search. For example, entering 'mack.'
will find "Mack", "Mackall", "Mackay", and so on.

Web-based Whois
To use Registry Whois using the web interface:
* Go to www.verisign.com/nds and select the Whois link
* Click on the appropriate button ("domain," "registrar" or "nameserver") 
 Enter the applicable parameter:  * Domain name including the TLD (e.g.,
verisign.com)
* Full name of the registrar including punctuation, "Inc.", etc. (e.g., Example,
Inc.) 
* Full host name or the IP address (e.g., A.GTLD-SERVERS.NET, 192.5.6.30, or
2001:503:A83E:0:0:0:2:30)
* Select the appropriate radio button for query type
* Click on the "submit" button. 

RFC 3912 and Web-based Whois Output
For all registered second-level domain names in .net, information as illustrated
in the following example is displayed, where the entry parameter is the domain
name (including the TLD):  

Domain Name: VERISIGN.COM 
Registrar: NETWORK SOLUTIONS, LLC.
Whois Server: whois.networksolutions.com
Referral URL: http://www.networksolutions.com
Name Server: NS1.CRSNIC.NET
Name Server: BAY-W1-INF5.VERISIGN.NET 
Name Server: GOLDENGATE-W2-INF6.VERISIGN.NET 
Status: REGISTRAR-LOCK 
Updated Date: 19-nov-2004 Creation Date: 02-jun-1995
Expiration Date: 01-jun-2012

 >>> Last update of whois database: Wed, 11 Apr 2001 08:39:18 EDT <<< 

For all ICANN-accredited registrars who are authorized to register .net
second-level domain names through Registry Operator, information as illustrated
in the following example is displayed, where the entry parameter is the full
name of the registrar (including punctuation, "Inc.", etc.): 

Registrar Name: EXAMPLE, INC.
Address: 1 Main Street, Anytown, NY 12345, US
Phone Number: 555 123 4567 Email: registrar@example.net
Whois Server: whois.registrar.example.net
Referral URL: www.registrar.example.net
Admin Contact: John Smith
Phone Number: 555 123 4568
Email: admin1@example.net
Admin Contact: Jane Doe
Phone Number: 555 123 4569
Email: admin2@example.net
Admin Contact: Chris Auer
Phone Number: 555 123 4560 Email: admin3@example.net
Admin Contact: Domain Name Administrator
Phone Number: 555 123 4571
Email: admin@example.net
Billing Contact: Adam Smith Phone Number: 555 123 4572 
Email: asmith@example.com 
Technical Contact: Chris Auer Phone Number: 555 123 4573
Email: cauer@example.com
Technical Contact: Technical Contact 
Phone Number: 555 123 4574 Email: techcontact@tld.net

 >>> Last update of whois database: Sat, 8 Jan 2005 07:36:07 EST <<< 

For all hosts registered using second-level domain names in .net, information as
illustrated in the following example is displayed, where the entry parameter is
either the full host name or the IP address:  

Server Name: A.GTLD-SERVERS.NET
IP Address: 192.5.6.30
IP Address: 2001:503:A83E:0:0:0:2:30
Registrar: NETWORK SOLUTIONS, LLC.
Whois Server: whois.networksolutions.com Referral URL:
http://www.networksolutions.com 

>>> Last update of whois database: Sat, 8 Jan 2005 07:36:07 EST <<<

IRIS Whois
The IRIS service will be compliant with RFC 3981 and RFC 3982 or any future
standards track RFC that may update or obsolete RFCs 3981 or 3982.  The IRIS
service will be compliant RFC 3983, any future standards track RFC that may
update or obsolete RFC 3983, or any standards track RFC that is specifically
intended as an access-control capable, TCP-based transport binding replacement
of RFC 3983.  Additionally, the IRIS service may offer transport-bindings
specified in a standards track RFC or RFCs that are complementary of RFC 3983. 

References 
[RFC3912] L. Daigle: "WHOIS Protocol Specification", RFC-3912, September 2004.
[RFC3981] A. Newton, M. Sanz: "IRIS: The Internet Registry Information Service
(IRIS) Core Protocol", RFC-3981, January 2005.
[RFC3982] A. Newton, M. Sanz: "IRIS:  A Domain Registry (dreg) Type for the
Internet Registry Information Service (IRIS)", RFC-3982, January 2005
[RFC3983] A. Newton, M. Sanz: "Using the Internet Registry Information Service
(IRIS) over the Blocks Extensible Exchange Protocol (BEEP)", RFC-3983, January 2005

Appendix P*, Whois Data Specification – Independent Whois Provider

Appendix P 
Whois Bulk Data Provisioning 

Registry Operator shall provide bulk access to up-to-date data concerning domain
name and name server registrations maintained by Registry Operator in connection
with the .net TLD on a daily schedule, only for purposes of providing free
public query-based access to up-to-date data concerning domain name and name
server registrations in multiple TLDs, to a party designated from time to time
in writing by ICANN (the "Designated Recipient"). The specification of the
content and format of this data, and the procedures for providing access, shall
be as stated below. 
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.

Content The data sets will consist of three types of objects: 
1. Registrar objects. The first type of object corresponds to a single
registrar. It includes the following data: * Registrar ID * Name of Registrar *
TLDs in which registrations are capable * Reference to registrars public whois
service 

2. Nameserver objects. A second type of object is the nameserver object, which
corresponds to a single registered name server. The nameserver object includes
the following data: * Name Server ID * Host Name * IPv4 Addresses if applicable
* IPv6 Addresses if applicable * Creation Date * Last Updated Date
* Last Verification Date if applicable 

3. 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 
* ASCII-based Domain Name
* IDN if applicable
* All IDN variants if applicable 
* Sponsoring Registrar 
* All name servers associated with this domain 
* Registration Date 
* Expiration Date 
* Last Updated Date
* Last Verification Date 

Status
Reference to domain in registrar's public Whois service if applicable 
Format Full and incremental data sets will be XML version 1.0, UTF-8 encoded
documents conforming to Section 5 ("Database Serialization") of RFC 3981 and the
data model specified in RFC 3982. 
Procedures for Providing Access 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 Registry Operator and ICANN during the design process as
well as during the IETF standards process. 
Registry Operator 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 a specified time of day on the day of the week to which they relate. Until a
different day of the week and time of 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: "fullYYMMDD" 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: "IIIYYMMDD" where "III" is the change type of either
"add" for additions, "mod" for modifications, or "del" for deletions and
"YYMMDD" follows the same format. 

b. 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 or S/MIME. The Data
Recipient's public key will be used for the encryption and Registry Operator's
private key will be used for the signature. Public keys will be exchanged
between 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 transmission of incremental data sets or
at the option of either Registry Operator or the Designated Recipient, by
writing the full data set to DAT tape (or other media and format mutually agreed
by Registry Operator and the Designated Recipient) and sending it to the
Designated Recipient using an expedited delivery service. 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, Registry Operator will make them available for download
by the Designated Recipient by Internet file transfer protocol.

References 
[RFC3981] A. Newton, M. Sanz: "IRIS: The Internet Registry Information Service
(IRIS) Core Protocol", RFC-3981, January 2005.
[RFC3982] A. Newton, M. Sanz: "IRIS:  A Domain Registry (dreg) Type for the
Internet Registry Information Service (IRIS)", RFC-3982, January 2005

Appendix Q*, Whois Data Specification – ICANN

Appendix Q 
Whois Data Specification

Registry Operator shall provide access for ICANN to bulk up-to-date data
concerning domain name and name server registrations maintained by Registry
Operator in connection with the .net TLD on a daily schedule; only for the
purpose of verifying and ensuring the operational stability of Registry
Services, the DNS, and the Internet. The specification of the content and format
of this data, and the procedures for providing access, shall be as stated below,
until changed according to the Registry Agreement. 
The content and format specification data and procedures for providing access,
will be as stated below, until changed according to the Registry Agreement.
 
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. 
Content The full data sets will consist of the objects and contents described
for full data sets in the ("Content") section of Appendix P. 
Format Full data sets will be XML version 1.0, UTF-8 encoded documents
conforming to the schema/document type declaration set forth in the ("Format")
section of Appendix P. 

Procedures for Providing Access Registry Operator will prepare a full data set
once each week (the day to be agreed upon by Registry Operator and ICANN). Full
data sets shall be up-to-date and complete as of a specific time of day on the
day of the week to which they relate. Until a different day of the week and time
of day is agreed upon by Registry Operator and ICANN, the full data sets will be
prepared for Sundays at 12:00 UTC. 

1. Preparation of Files Containing Data Sets. Each full data set consists of an
XML document meeting the content and format requirements of part 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: "fullYYMMDD" 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. 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, an MD5 file (produced with MD5SUM or equivalent) must
be included with the resulting files to isolate errors. Registry Operator may
optionally compress the document using the Unix GZIP command (or equivalent) to
reduce the file size. 

c. The file(s) will then be encrypted and signed using PGP or S/MIME. An ICANN
public key will be used for the encryption and Registry Operator's private key
will be used for the signature. Public keys will be exchanged between Registry
Operator 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 Registry Operator's option,
according to paragraph b below: 

a. Registry Operator will make full data sets available for download by ICANN by
secure and authenticated methods, including, but not limited to, secure ftp
(sftp) or secure web (https) protocols. The data sets will be made available for
download no later than a time of day to be specified by ICANN on the day of the
week to which they relate and until the next full data set becomes available for
download. 

b. Registry Operator 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.
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.

Appendix R, Data Escrow Specification

Data Escrow Specification 
EXHIBIT A - Task Order and Statement of Work 

TASK ORDER TITLE
Exhibit A to the Registry Data Escrow Agreement dated _______________.

COMPANY NAME
Data Escrow Provider

STATEMENT OF WORK
Establish an escrow account to deposit all Registry Data in an electronic format
mutually approved by VeriSign Global Registry Services, and ICANN. More
specifically, to meet the Data Escrow requirements outlined in the Registry
Agreement, VeriSign Global Registry Services will store in escrow with Data
Escrow Provider a complete set of Registry Data in an electronic format agreed
upon by VeriSign Global Registry Services, and ICANN. Data Escrow Provider will
verify that the data is complete, accurate, and delivered in the intended format
using scripts provided by VeriSign Global Registry Services. A phased approach
will be taken to implement the scripts required for verification. The short-term
escrow process will verify completeness and integrity (accuracy). A long-term
approach is required to create a script to verify that the file format sent is
the format received by Data Escrow Provider (correctness). Refer to Exhibits B1
and B2 to review the short and long-term verification processes. The
Introspection validation, defined in Exhibit B2, will be implemented in a later
phase, as mutually agreed by the parties hereto.

Data will be securely and electronically transmitted on a daily and weekly basis
as follows:
Weekly Escrow Deposits:
VeriSign Global Registry Services will deposit a complete set of Registry Data
into escrow on a weekly basis by electronically and securely transmitting a
snapshot of each operational Registrar's data (the "Deposit Materials"). The
snapshot captures the state of each Registrar's data at the time the snapshot
was created. Specific data elements contained in the Deposit Materials are
identified in Table 1.

Daily Escrow Deposits:
VeriSign Global Registry Services will securely and electronically deposit a
transaction log for each operational Registrar representing transactions that
occurred over the previous 24 hour period (the "Additional Deposit"). The logs
will be escrowed daily, being in the form of Additional Deposit each Tuesday
through Sunday, and being in the form of the Weekly Deposit Materials each
Monday, which shall capture that Sunday's data. The Daily Additional Deposit
will act as incremental updates to the Weekly Deposit Materials and will include
all Registrar activity, such as add, delete, and transfer of a domain name.
Specific data elements contained in the Additional Deposit are identified in
Table 2.

Electronic Delivery Service Escrow Deposit Method:
The "Electronic Delivery Service" escrow deposit method shall mean and refer to
the following. VeriSign Global Registry Services shall transmit the Deposit
Materials and Additional Deposit to a secure server on a weekly and daily basis,
respectively. VeriSign Global Registry Services shall provide a secure ID and
password for Data Escrow Provider. Data Escrow Provider shall pull the
transmitted data from the server and store it in a secured location. The
transmitted data will be made available to Data Escrow Provider as follows:

Daily Deposits:
Daily transactional data will be made available at the close of business each
Tuesday through Sunday for the previous calendar day. For example, transactional
data created on Monday would be available to the escrow company on Tuesday at
the close of business. The results of transactions completed on Sunday will be
made available in the Weekly Deposit Materials, thus no separate Daily
Additional Deposit will be made for Sunday activity.

Weekly Deposits:
Weekly database snapshots taken at midnight on Sundays will be available not
later than 6 p.m. each Monday.

Data Transmission File Sizes:
The Weekly Deposit Materials shall include 4 reports (see Table 1 for details of
reports). 
Additional Deposits shall include 1 report (see Table 2 for details of report).
FILE SIZE ESTIMATES 
 	Daily 	Weekly 
Current Data Escrow Size	up to 10 Megabytes 	up to 750 Megabytes 
Forecasted 2001 Data Escrow Size	up to 75 Megabytes 	up to 1 Gigabytes 
Total Forecasted Escrow Size	up to 110 Megabytes 	up to 4 Gigabytes 
Table 1: Weekly Deposit Materials Format 

Registrar Weekly Reports
1. Registrar Domain Report
Title: Registrar Domain Report
Report name: rgr_domain
Description: This report contains all domains associated with a specific
registrar. The domain is listed once with each current status and associated
nameserver.
Fields:
          domainname
          statusname
          servername
Examples:
          ALPHA.COM:REGISTRY-LOCK:NS1.ALPHA.COM
          ALPHA.COM:REGISTRY-LOCK:NS2.ALPHA.COM
          ALPHA.COM:REGISTRY-HOLD:NS1.ALPHA.COM
          ALPHA.COM:REGISTRY-HOLD:NS2.ALPHA.COM
          BETA.COM:ACTIVE:NS1.BETA.COM
          BETA.COM:ACTIVE:NS2.BETA.COM
          GAMMA.COM::NS1.GAMMA.COM
          DELTA.COM:ACTIVE: 

2. Registrar Nameserver Report - Listed with IP Address
Title: Registrar Nameserver Report - Listed with IPAddress
Report name: rgr_nameserver
Description: This report contains all nameservers associated with a specific
registrar. The nameserver is listed once with each associated ipaddress.
Fields:
          servername
          ipaddress
Examples:
          NS.ALPHA.COM:111.222.333.001
          NS.ALPHA.COM:111.222.333.002
          NS.BETA.COM: 

3. Registrar Nameserver-Domain Hosting Report
Title: Registrar Nameserver Report - Listed with Domain
Report name: gr_nameserver_domain
Description: This report contains domains hosted per nameservers associated with
a specific registrar. The nameserver is listed once with each associated domainname.
Fields:
          servername
          domainname
Examples:
          NS.ALPHA.COM:ALPHA1.COM
          NS.ALPHA.COM:ALPHA2.COM
          NS.ALPHA.COM:ALPHA3.COM
          NS.BETA.COM:BETA1.COM
          NS.BETA.COM:BETA2.COM
          NS.GAMMA.COM: 

4. Registrar Common Report
Title: Registrars Report
Report name: Registrars
Description: This report contains one row for each registrar. Fields of the
report contain name, location, contact, financial, and business information.
Fields:
          REGISTRARID
          REGISTRARNAME
          SECURITYPHRASE
          PHONENUMBER
          FAXNUMBER
          LICENSEEXPIRATIONDATE
          CREDITLIMIT
          AVAILABLECREDIT
          LOWERLIMITPCT
          EMAIL
          GROSSAMOUNTDUE
          NETAMOUNTDUE
          ORIGINALDUEDATE
          DUEDATE
          ADDRESSLINE1
          ADDRESSLINE2
          ADDRESSLINE3
          CITY
          STATEPROVINCE
          POSTALCODE
          COUNTRYCODE
          STATUSNAME
          DESCRIPTION
          CANPLACEORDER
Examples:
123:Alpha Registrar:Gazpacho is a dish best served cold:(123)456-7890:
(123)456-7891:2001.01.01.00.00.00:2000000:218990:.2:registrar@alpha.com:
::::123 4th Avenue, 7 1/2th Floor:::NY:NY:10018:US:ACTIVE:Registrar is active
and can use the Registry to issue RRP commands: 

Table 2: Daily Additional Deposit Format 

Registrar Daily Additional Deposits

1. Registrar Transaction Report
Title: Registrar Transaction Report
Report name: rgr_transaction
Description: This report contains transactions associated with a specific
registrar. Domain operations produce one row for each associated nameserver.
Nameserver operations produce one row for each associated ipaddress. A
transactionid is included to allow unique identification of transactions. The
content of columns 3 and 4 is dependent on the operation in the following ways:
          operation Oe (ADD_DOMAIN, MOD_DOMAIN, DEL_DOMAIN) =>
[domainname][servername]
          operation Oe (ADD_NAMESERVER, MOD_ NAMESERVER, DEL_ NAMESERVER) =>
[ipaddress][servername]
          operation Oe (TRANSFER_DOMAIN) => [domainname][null]
Only the seven (7) operation types above are included in the report.
Fields:
          transactionid
          operationname
          domainname | ipaddress
          servername | null
          transactiondate
Examples:
          1000010:ADD-DOMAIN:ALPHA.COM:NS.ALPHA.COM:1999.04.25.00.01.08
          1000020:ADD-DOMAIN:BETA.COM:NS1.BETA.COM:1999.04.25.00.05.33
          1000020:ADD-DOMAIN:BETA.COM:NS2.BETA.COM:1999.04.25.00.05.33
          1000030:ADD-DOMAIN:GAMMA.COM::1999.04.25.00.05.34
          2000010:ADD-NAMESERVER:111.222.333.001:NS.DELTA.COM:1999.04.25.00.06.48
          2000020:ADD-NAMESERVER:444.555.666.001:NS.EPSILON.COM:1999.04.25.00.36.18
          2000020:ADD-NAMESERVER:444.555.666.002:NS.EPSILON.COM:1999.04.25.00.36.18
          2000030:ADD-NAMESERVER::NS.ZETA.COM:1999.04.25.00.37.31
          3000010:TRANSFER_DOMAIN:ETA.COM::1999.04.25.01.37.31
          3000020:TRANSFER_DOMAIN:THETA.COM::1999.04.25.02.37.31
          3000030:TRANSFER_DOMAIN:IOTA.COM::1999.04.25.03.37.31
          3000040:TRANSFER_DOMAIN:KAPPA.COM::1999.04.25.03.37.31 

1. ADDITIONAL TERMS AND CONDITIONS 

For .com agreement:
Registry Operator shall periodically deposit into escrow all Registry Data on a
schedule (not more frequently than weekly for a complete set of Registry Data,
and daily for incremental updates) and in an electronic format mutually approved
from time to time by Registry Operator and ICANN, such approval not to be
unreasonably withheld by either party. The escrow shall be maintained, at
Registry Operator's expense, by a reputable escrow agent mutually approved by
Registry Operator and ICANN, such approval also not to be unreasonably withheld
by either party. The schedule, content, format, and procedure for escrow
deposits shall be as established by ICANN from time to time. The initial
schedule, content, format, and procedure shall be as set forth in Appendix R.
Changes to the schedule, content, format, and procedure may be made only with
the mutual written consent of ICANN and Registry Operator (which neither party
shall unreasonably withhold) or through the establishment of Consensus Policies
as set forth in Definition 1 of this Agreement. The escrow shall be held under
an agreement, substantially in the form of Appendix S, among ICANN, Registry
Operator, and the escrow agent.

For .net and .org agreements:
Registry Operator shall periodically deposit into escrow all Registry Data in an
electronic format. The escrow shall be maintained, at Registry Operator's
expense, by a reputable escrow agent mutually approved by Registry Operator and
ICANN, such approval also not to be unreasonably withheld by either party. The
schedule, content, format, and procedure for escrow deposits shall be as
established by ICANN from time to time. The initial schedule, content, format,
and procedure shall be as set forth in Appendix R. Changes to the schedule,
content, format, and procedure may be made only with the mutual written consent
of ICANN and Registry Operator (which neither party shall withhold without
reason) or in the manner provided in Subsections 4.3 through 4.6. The escrow
shall be held under an agreement, substantially in the form of Appendix S, among
ICANN, Registry Operator, and the escrow agent.

2. PERIOD OF PERFORMANCE

Period of Performance shall be as defined by section 7(a) of this Escrow Agreement. 

3. FEE SCHEDULE
Fees to be paid by VeriSign Global Registry Services shall be as follows:
Initialization fee (one time only) $ _________


*Annual maintenance/storage fee $ _________
*includes two cubic feet of storage space
Additional Services Available:

Electronic Updates
Transmitted once daily $ ________
Price quoted is limited to 650 MB per update.

Electronic Updates over 650 MB $ ________
Fee incurred for updates over 650 MB will be billed on a monthly basis.
Additional Services
Verification / File Listing Services $ ________
(This includes up to one hour of service
for each deposit)

Additional Storage Space $ ________

Payable by Licensee or Producer Only Upon Release Request:
Due Only Upon Licensee's or Producer's
Request for Release of Deposit Materials $ _________ 
                    $ ___________ . 
Fees due in full, in US dollars, upon receipt of signed contract or deposit
material, whichever comes first. Thereafter, fees shall be subject to their
current pricing, provided that such prices shall not increase by more than 10%
per year. The renewal date for this Agreement will occur on the anniversary of
the first invoice. If other currency acceptance is necessary, please contact
your Account Manager to make arrangements.

EXHIBIT B1 - Phase I Escrow Process 
The goal of the Escrow Process is to periodically encapsulate all
Registrar-specific information into a single Escrow File and to make this file
available to a third party for escrow storage. Existing Daily and Weekly reports
as well as a Registrars Report (note a) will be used to construct the Escrow
File because these reports, when taken together, describe completely the entire
set of domains, nameservers, and Registrars. The Escrow Process employs a method
of encapsulation whereby the Daily, Weekly, and Registrar reports are
concatenated, compressed, digitally signed, and digested into a single file. The
format of this encapsulation enables the single file to be verified for
Completeness (note b) and Integrity (note c) by a third party.

EXHIBIT B1 - Phase I Verification Process 
The goal of the Verification Process is to verify Completeness (note b) and
Integrity (note c) of an Escrow File. The Verification Process uses layers of
meta-data encapsulated in the Escrow File to construct a Verification Report.
The verification report produced by the Verification Process indicates whether
the data file meets the authentication requirements. The report has 2 sections,
action and results. Actions describe each of the actions taken against the data
file and whether those actions met success or failure. Results describe the
results of the verification process. If there was a failure in the Actions
section then the Results section will describe details of the failure and
indicate that the Data File is corrupt and cannot be verified. If no errors are
present the Results section will indicate that the file is valid.

Notes
a. Registrar Report
The existing Daily and Weekly reports associate Registry data and transactions
to specific Registrars by naming each report with a specific Registrar Id. The
Registrar report provides a mapping between these Registrar Ids and other
associated Registrar information such as name, credit, billing address, contact
info, and location.

b. Completeness
A data file transfer is complete if all data files transferred from the source
machine are present on the destination machine.

c. Integrity
A data file transfer has integrity if no data file was altered by a third party
while in transit.

Exhibit B2: Phase II Escrow Process 
The goal of the Escrow Process is to periodically encapsulate all
Registrar-specific information into a single Escrow File and to make this file
available to a third party for escrow storage. Existing Daily and Weekly reports
as well as a Registrars Report (note a) will be used to construct the Escrow
File because these reports, when taken together, describe completely the entire
set of domains, nameservers, and Registrars.
The Escrow Process employs a method of encapsulation whereby the Daily, Weekly,
and Registrar reports are concatenated, compressed, signed, and digested into a
single file. The format of this encapsulation enables the single file to be
verified for Completeness (note b), Correctness (note c), and Integrity (note d)
by a third party. The Escrow Process includes data format specification for each
report file using regular expression algebra. This format specification is
stored with the report file itself and is used for format verification later.
The report file along with data format specification is then digitally signed
for authentication, non-repudiation and message integrity verification.

Exhibit B2: Phase II Verification Process 
The goal of the Verification Process is to verify Completeness (note b),
Correctness (note c), and Integrity (note d) of an Escrow File. The Verification
Process uses layers of meta-data encapsulated in the Escrow File to construct a
Verification Report (note f). The verification report produced by the
verification process indicates whether the data file meets the authentication
requirements. The report has 2 sections actions and results. Actions section
describes each of the actions taken against the data file and whether those
actions met success or failure. Results section describes the results of the
Verification Process. If there was a failure in the Actions section then the
Results section will describe details of the failure and indicate that the Data
File is corrupt and cannot be verified. If no errors are present the Results
section will indicate that the file is valid. As part of verification the data
format specification is used to verify the correctness of the format of each
record in the file. To ensure that the Reports are self-consistent,
introspection will be implemented in a later phase. Introspection will analyze
Weekly Reports across all Registrars to verify that fields referenced from
outside the report are indeed valid entries in other weekly reports.

Notes
a. Registrars Report
The existing Daily and Weekly reports associate Registry data and transactions
to specific Registrars by naming each report with a specific Registrar Id. The
Registrar report provides a mapping between these Registrar Ids and other
associated Registrar information such as name, credit, billing address, contact
info, and location.

b. Completeness
A data file transfer is complete if all data files transferred from the source
machine are present on the destination machine.

c. Correctness
A data file transfer is correct if each data file on the destination machine has
the same information content as that on source machine.

d. Integrity
A data file transfer has integrity if no data file was altered by a third party
while in transit.
e. Regular Expression Algebra
The regular expression algebra is a powerful data description language. The data
structure description can be as specific or generic as necessary.

f. Verification Report
The verification report produced by the Verification Process indicates whether a
Data File meets the authentication requirements. The report has 2 sections:
Actions

This section describes each of the actions taken against the Data File and
whether those actions met "SUCCESS" or "FAILURE".

Results
This section describes the results of the Verification Process. If there was a
"FAILURE" in the Actions section then the Results section will describe details
of the failure and indicate that the Data File is corrupt and cannot be
verified. If no errors are present the Results section will enumerate the Report
Files contained within the Data File and indicate that the file is valid.

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.

VeriSign's long history of providing highly scalable and reliable infrastructure
solutions for critical network services has enabled us to build organizational
core expertise in registry systems. Over the past 13 years, VeriSign has
demonstrated the technical capabilities to successfully design, develop, and
operate critical Internet infrastructure. VeriSign has set many of the standards
now universally adopted by the industry.

VeriSign Advantages:
+ 100 percent availability of Domain Name System (DNS) infrastructure over the
past 7 years
+ Currently support over 38 million domain name registrations with a peak of 19
billion queries per day
+ Provide the Internet industry with extensive technical expertise and leadership
+ Demonstrated proven innovation and commitment to future enhancements.

This section outlines VeriSign's comprehensive technical capabilities, including:
* Description of Technical Capabilities. VeriSign' proven system architecture,
rigorous processes, and operational management have resulted in flawless
performance operating the .net registry.
* Information About Key Technical Personnel. VeriSign has assembled a dedicated
team of industry leading technical experts with an unparalleled breadth and
depth of qualifications and experience.
* The Size of the Technical Workforce. VeriSign employs a robust technical
workforce dedicated to all functional registry operations.
* Access to Systems Development Tools. VeriSign engineers use of a complete
suite of productivity tools to aid in the development, quality assurance
testing, deployment, and maintenance of .net registry services.
* Significant Prior Technical Achievements. VeriSign's technical achievements
have been the result of long-term commitments to research, development, testing,
and operational experience.

The successful operation of these critical registries is core to VeriSign's
corporate strategy. Our company has invested heavily to provide the right
people, infrastructure, and processes focused on delivering superior performance
and stability.


Description of Technical Capabilities

VeriSign's superior technical capabilities are evidenced by perfect performance
over many years. Our ability to consistently meet SLA metrics is highlighted in
Table 5(a)-1, with additional key performance metrics listed in Table 5(a)-2.
Even with a large number of registrars and tremendous transaction volumes,
VeriSign has operated .net with no SLA violations and the best industry
performance for unplanned outages. Our commitments to performance are found in
Table 5(a)-3. The specific technical capabilities are discussed below in the
context of VeriSign's high-level architecture, functionally tailored technical
environments, registry administration of resolution systems, monitoring, and
registry management.

High-Level Registry Architecture
The registry architecture is comprised of three major functional units:
provisioning, distribution, and resolution. Every hardware component in the
VeriSign global registry environment is designed with either local or site
parallelism. When examined as a single system, VeriSign has the most available,
integrated architecture for providing registry services compared with any other
registry operator serving DNS queries.

The provisioning system is built on the three-tier architecture that VeriSign
designed: gateway, application, and database, as shown in Figure 5(a)-1. This
design has been generally copied by competing registry operators since the
creation of new TLDs in 2000. Gateway servers communicate with registrars using
the provisioning protocol. These gateway servers then interact with application
servers containing business logic for conducting the management and maintenance
of the registry business. The application servers store their data in the core
registry database. While this is a simple concept, this design has been
effective and VeriSign's implementation and years of fine tuning have proven our
ability to sustain excessive load against the provisioning system.

The database is the heart of this architecture, where all the essential data
provisioned from registrars through the gateway servers is stored. Separate
servers query the database, extract updated zone information, validate that
information, and distribute it around-the-clock to the worldwide name resolution
sites. Other database servers periodically load copies of the primary database
to provide Berkeley Internet Name Domain (BIND) zone file extracts (as a name
resolution backup mechanism), Whois update extracts, and data warehousing updates.

The resolution component is built on the advanced transaction lookup and
signaling (ATLAS) infrastructure, VeriSign's award-winning content verification,
distribution, and lookup infrastructure. We will provide greater detail about
ATLAS later in this section. Our resolution system handles a daily average query
volume in excess of 14 billion DNS queries at 100 percent availability. This
infrastructure is a cornerstone of the Internet, enabling resolution for the
.com and .net domains around the world, as well as for a number of other TLDs.

VeriSign has invested heavily in this architecture and infrastructure. We are
very proud of the capabilities of this system and its ability to provide
continuous resolution server uptime and accurate query response, to the point
that .com and .net name resolution is assumed by the public to be "always on."
Within this section of the proposal, we will discuss the components behind this
high-level picture, including: registry administration, resolution, monitoring,
and registration (provisioning).

Security and stability of the .net registry can only be achieved by a company
that is:
* Financially stable with the resources to invest in the infrastructure
* Fully scalable at both the registration and resolution level
* Secure, supported by an infrastructure with full disaster recovery capability
* Operated by technical experts for engineering design, operation, and maintenance
* Supported by 24x7x365 network monitoring and management


Computing Environments
VeriSign maintains individual computing environments to support the distinct
product life-cycle functions from concept development through deployment of
fully operational systems for the .net Registry. Figure 5(a)-2 illustrates the
relationships between these environments. These environments include:

* Applied Research
* Engineering Development
* Quality Assurance
* Operations Staging
* Operational, Test and Evaluation (OT&E)
* Monitoring
* Production

For a detailed description of each of these environments, please refer to
www.verisign.com/nds (Section 5(a)).

VeriSign's Infrastructure Engineering group is chartered with testing,
developing, and maintaining corporate-wide infrastructure standards. The
best-practices developed by this group underpin the standards for architecture
and design of systems used throughout VeriSign. We maintain an environment in an
isolated network with access restricted to only the Infrastructure group to
define and maintain consistent, reliable standards for all hardware, software,
networking and security solutions before they are introduced into the production
environments.


Information About Key Technical Personnel 

Biographies of our skilled executive, management and staff are detailed in Table
5(a)-4. There are 4 distinct features to VeriSign's registry administration:
1. Resolution. We operate from our award-wining ATLAS platform that is scaled to
support over 200 billion queries a day. This is discussed in detail in Section
5(b)ii.
2. Registration. we have a multi-tiered environment that is highly secure and
stable. We currently support the largest number of registrars and offer the
fastest response times in the industry. Details are provided throughout Section
5(b).
3. Monitoring. VeriSign developed a proactive monitoring system to ensure the
stability of the Internet. This system monitors all DNS and root traffic and is
shared with several government bodies.
4. Management. Our staff is firmly committed to providing the highest quality
DNS service available. For VeriSign, this is a core business, and a core
competency; we do not believe we are the best because we are the oldest, but
instead that we are the oldest because we are the best.


Size of the Technical Work Force

VeriSign collectively has over 600 years in DNS management. Our company's
skilled executives, management and staff, graphically depicted in Figures
5(a)-3, and 4, are recognized as industry leaders. Our technical staff is
comprised of over 919 employees, of which over 140 are dedicated to providing
excellence to our registry administration.


Access to Systems Development Tools

VeriSign has mature processes, procedures, and methodology. From full lifecycle
development to Information Technology (IT) management, VeriSign is the premier
registry provider because we have quality practices well-designed to deliver the
highest-quality product.

VeriSign benefits from the use of a complete suite of productivity tools to aid
in the development, quality assurance (QA) testing, deployment, and maintenance
of our registry services. VeriSign uses a combination of the best commercial
tools, as well as publicly available shareware. The primary suite of tools used
for requirements, development, configuration, and defect tracking is Borland's
Together suite. Table 5(a)-5 provides a summary of the tools currently used by
VeriSign Engineering and Operations.

VeriSign has ample access to a variety of tools to support the full lifecycle
process from idea conception through development, and ultimately, deployment.
This helps increase the quality of products and services brought to market by
the VeriSign registry and also increase the stability and security of the Internet.

Product Development Lifecycle Methodology
VeriSign is very proud of our efficient Product Development Lifecycle
Methodology. This approach, based on industry best practices from other leading
software and infrastructure companies, allows us to be responsive to market
needs while at the same time maintain appropriate governance over our resources
to ensure that our product deliveries are reliable and of high quality. One of
the key components of this methodology is our "New Project Initiation" process
(NPI).

The NPI process (Figure 5(a)-5) is the means by which all projects begin. As new
products are conceived, or follow-on releases for existing platforms are
identified, all stakeholders convene to review the NPI request. This group is
comprised of decision makers representing Business Operations, Product
Management, Customer Service, Reporting, Finance, Sales, Marketing, Engineering,
and Operations. The NPI approval process involves progressing requests through
three distinct gates, or decision points. At each gate, the NPI team governs
which projects will receive funding and approval to continue. The succession of
gates is reflective of how a product or release concept matures as requirements
are further defined.

Development Process

Change process and evaluation methodology are important to provide overall
quality in system development and management, as shown in Figure 5(a)-6.
VeriSign has established processes to ensure that any component being released
to production has been exhaustively evaluated for features, functionality,
stability, and security. Performance testing is required for our hardware and
software running mission critical applications.

For more information on these processes, please refer to www.verisign.com/nds
(Section 5(a)).


Significant Prior Technical Achievements

As the current .net service provider; VeriSign is committed to providing the
highest levels of performance and service in the industry. Our solution will
maintain the existing services provided. VeriSign's technical achievements
highlight our focus on key infrastructure enhancements for .net which have been
possible only through dedicated industry leadership and long-term commitments to
research, development, testing, and operational experience. These achievements
can be recognized in current services and enhancements as well as a number of
notable pilots that are in progress as shown in Table 5(a)-6. The duration of
time we have offered each service shows VeriSign's long-term commitment to this
industry and to our ability to lead with new innovative products and services.

Current Services
The following examples highlight our technical achievements through our track
record of innovation (refer to Innovation discussion in Section 3(b)i).

ATLAS

VeriSign's analysis of DNS trends and forecast for future requirements
identified a major DNS concern in the late 1990s. Our conclusion at that time
was that a BIND-based resolution platform would not meet our forecasts for
security, functional capabilities, performance, and capacity requirements.
Additionally, the cost of scaling the infrastructure to meet the rate of query
growth was a concern. Even a minor linear growth of registered names, combined
with a modest growth of Internet usage (measured as average daily lookups per
registered domain) creates an exponential growth of total DNS queries.

Additional functional requirements, such as Internet Protocol Version 6 (IPv6)
and DNS Security Extensions (DNSSEC) added to these concerns, which led to an
analysis of systems that would support next-generation Internet demands. The
conclusion was that existing DNS solutions would not be adequate; therefore,
VeriSign began development of an advanced transaction lookup system, ATLAS.

VeriSign completed years of development and testing before beginning deployment
of ATLAS. ATLAS has grown to support not only the DNS infrastructure on the
Internet, but also, through its advanced architecture, separate instances of
ATLAS now support Internet digital certificates, traditional, and
next-generation telephony networks. ATLAS has been running core components of
VeriSign's businesses since 2002. Today, VeriSign's ATLAS infrastructure has the
capacity to support well over 200 billion lookups per day. The actual capacity
is not disclosed as a security measure. Currently, ATLAS processes nearly one
million updates each day with an average of 14 billion DNS queries every day
with peaks over 19 billion, running the .com and .net top level domains (TLDs).

Separate instances of the ATLAS infrastructure for telephony support local
number portability (LNP), calling name (CNAM), do not call, and other telephony
database services, accessible over both SS7 and IP protocols. ATLAS is
integrated with VeriSign's own SS7 network, providing database services that
major telephony providers rely on daily.

ATLAS has the highest reliability and scalability. ATLAS supports greater than
250 million record database sizes, with the highest query volumes, and the
greatest services levels compared with any other registry operator; ATLAS has
proven this capability in its Internet and telephony businesses.

Application Isolation. Even though the ATLAS platform supports many different
features, applications, and products, VeriSign deploys completely dedicated
ATLAS instances for separate applications, tailoring the redundancy,
scalability, and reliability to the application needs. The ATLAS instance for
DNS includes 14 sites, plus 3 hot spares and growing, with total redundancy at
every site, dedicated to .net and .com resolution.

Some of the applications and features ATLAS supports include:
* DNS
* OCSP Responder
* RFC 3261 SIP
* H.323 v2 and v4
* PacketCable 1.2 CMSS
* Interoperability between SIP, CMSS, and H.323, across equipment from leading
vendors
* ENUM, CMSS, or SIP access to VeriSign's ATLAS infrastructure for route resolution
* T.38 fax relay
* V.90/V.92 traffic support
* RTP flow control through the border gateway
* G.711, G.723.1, G.729a CODEC types
* Real-time call detail record generation
* Routing on a variety of criteria, including called number, calling number,
originating network, call type, number patterns, time of day, and day of week
* Customizable route plans per enterprise
* Ability to provision routes without requiring changes on enterprise
provisioned equipment
* LNP, do-not-call, toll-free database, and CNAM queries over SS7, SIGTRAN, and SIP.

ATLAS uses a multi-hub-and-spoke architecture, consisting of multiple data
centers communicating with any number of distributed resolution sites, as shown
in Figure 5(a)-8. The data centers house the authoritative data sets, almost
exclusively managed in online transaction processing systems based on Oracle
databases. Real-time data updates are extracted from these databases of record,
and are validated and distributed to the remote DNS resolution sites. All the
programs for extraction, validation, distribution, and lookup are custom
software developed in C++, and are maintained on several major Unix operating
systems, including IBM AIX, Intel/Opteron, Linux, FreeBSD, and Sun/Opteron
Solaris. The C++ compiler of the native platform is used for AIX and Solaris,
while GNU's compiler is used for the remaining platforms.

Other key technical achievements are provided throughout this proposal. They
include: a comprehensive solution for IPv6, the first International Domain Name
(IDN) implementation, a RAPID DNS implementation, a comprehensive (Heads-Up
Display (HUD) monitoring tool, authoring several technical standards, and
hosting several technical and business consortium to promote the implementation
of technical solutions.


Conclusion

VeriSign's long history of providing highly scalable and reliable infrastructure
solutions for critical network services has enabled us to build organizational
core expertise in registry systems. Over the past 13 years, VeriSign has
successfully designed, developed, and deployed infrastructure to
cost-effectively support breakthrough technologies. VeriSign has set many of the
standards now universally adopted by the industry. Our technical experts
regularly provide education and share best practices for maintaining stability
and security of operation. The successful operation of these critical registries
is core to VeriSign's corporate strategy. Our company has invested heavily to
provide the right people, infrastructure, and processes focused on delivering
superior performance and stability.

We will commit to four areas of technical service enhancements from the existing
.net contract:
1) Increased performance specifications and SLAs (refer to Appendices D and E)
2) Match user demand with network expansion (growing the constellations) to meet
stability and security requirements.
3) Expand monitoring to include more proactive monitoring.
4) Continue work to promulgate existing services and increase user choice.

The .net registry provides a series of robust services, including IDNs, IPv6,
ConsoliDate, and DNSSEC pilot. Each of these services has been in development
and testing (in some instances for years), prior to inclusion in the registry to
maintain the stability and performance of the .net registry.


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

Facilities are the foundation for building, operating, and maintaining reliable
platforms that guarantee the uptime of critically hosted Internet services.
VeriSign classifies its major data centers as critical facilities, and also
operates services from outsourced facilities that are used to host a number of
our DNS name server sites. All facilities are available for inspection upon request.

VeriSign Advantages:
+ Facilities declared Critical Infrastructure by U.S. government
+ Over 30 business offices and 18 technical facilities worldwide
+ Long-term investments in robust, fully redundant facilities and systems
+ Integrate comprehensive, world-class security into all facilities and systems
+ Thorough background checks and screening of all employees and contractors with
periodic review.

This section outlines the general description of VeriSign's facilities and
systems for the .net registry. Throughout this section, we describe all system
locations with the specific types of system being used in each facility, including:
* Description of all System Locations. VeriSign carefully selects facilities and
locations based on well-established criteria for each system.
* Specific types of systems being used, their capacity, interoperability, and
general availability. All systems in VeriSign data centers are designed and
operated 24x7x365 to the highest specifications requisite for critical
infrastructure services.
* Level of Technical Security. VeriSign provides world-class security for all
data centers. This security prevents against data tampering, system hacks, and
physical break-ins. It includes 24x7x365 security and biometric access controls.
* Detailed description of building details, hardware and software systems, and
environmental equipment. VeriSign buildings are hardened and fully secured, with
infrastructures that are designed, built, and managed specifically to support
critical Internet infrastructure services VeriSign data centers maintain fully
redundant environmental systems to provide reliable services
* Internet Connectivity. VeriSign data center facilities maintain redundant
Internet connections with diverse high capacity service.


VeriSign currently operates the .net registry from its major data centers in the
continental United States and hosted resolution facilities across the globe.

Our major data centers are hard shell, fully secured, and supported critical
infrastructure buildings designed, built, and managed to the highest possible
standards. Facilities failure would compromise the mission critical objective of
providing uptime reliability necessary for critical services supporting the
Internet. Verisign has invested enormous resources into building the most
reliable data centers possible by:
* Partnering with the best critical facility design engineers in the world,
drawing on their combined knowledge and experience to design and build the most
robust possible critical data centers possible, each designed to provide as
close to 100 percent Internet uptime as technically possible.
* VeriSign data centers so secure, reliable, and important to the Internet
infrastructure that they have been designated as critical infrastructure sites
by the United States Department of Homeland Security since 2001.
* VeriSign data centers that incorporate and operate on multiple redundant
support systems designed to maximize service uptime.
* Employing world-class engineers to manage and operate the data centers, using
best possible maintenance standards regardless of cost.
* Periodically replacing critical infrastructure equipment well before end of
lifecycles, using the best new equipment possible.
* Using cutting edge technology to support availability requirements by linking
multiple data centers together to provide the most robust and reliable solutions
possible.
* VeriSign data centers use multiple and redundant extremely high bandwidth
optic fiber.
* VeriSign data centers are fully secured by the best possible electronic
surveillance systems, guarded by highly trained and capable security teams, and
remotely monitored 24x7x365 from a highly classified Global Security Operation
Center.


Description of All System Locations

VeriSign has set the industry standard for registry availability by delivering
scalable, secure, and stable registry services with the global presence required
for critical Internet infrastructure. VeriSign operates the .net TLD in
facilities designed specifically to support large-scale, domain name registries.
Services for essential elements of the Internet infrastructure must be housed in
fully redundant, world-class facilities to support all registry operations to
reliably meet growing demands on registry systems. This section discusses
VeriSign's selection criteria and locations.

The Naming and Directory headquarters, located in Dulles, Virginia, provide the
management of registry facilities for all registry technical functions. These
include the fully redundant, functionally identical primary and alternate
primary facilities for the SRS and the registry database, our global
constellation of DNS services hosted at carrier grade facilities, Customer
Service, and the Network Operations Center (NOC). Figure 5(b)i-1 shows the
locations of VeriSign facilities for .net.

The primary data center is located within 10 miles from the Dulles, Virginia
headquarters and provides production services for the shared registration system
(SRS), the registry database, zone generation and distribution, and Whois. The
location for the data center was chosen to enable the operations staff to
maintain high-volume; real-time data synchronization between the primary and
alternate primary data centers with the ability to quickly relocate personnel,
yet sufficiently distant enough to isolate it from a catastrophic event at the
alternate primary data center.

The alternate primary data center is functionally identical to the primary data
center. This data center provides fully functional registry systems.


Specific Types of Systems Used, Capacity, Interoperability and General Availability

The infrastructure supporting the primary data center is depicted in Figure
5(b)i-2. The systems in each facility have the capacity to operate the .net
registry well into the next decade and are designed to operate 24x7x365. The
design, functions, and operation of these systems are described in the following
paragraphs.

Electrical Systems. The electrical supply for the primary data center features
design elements that are common to all data centers. If the normal utility
should fail (storms, construction accident, brownout, etc.), all three
generators are signaled to start after 15 seconds by the programmable logic
control (PLC). The uninterruptible power supply (UPS) units use battery power to
provide critical power to the data center and base building until the generators
provide emergency power or the normal utility returns. Once started and running,
all generators automatically supply emergency power to the main distribution
boards via the paralleling switchboard, until the normal utility returns. The
load shed capability, a fuel savings measure, allows the generators to shut down
and start automatically as the load requires. The NOC annunciator panels reflect
UPS and generator operation status. The Infrastructure Monitoring System (IMS)
is monitored by the NOC for all mission critical equipment.

Load Balancing. Registry services are load-balanced within the data centers.
Each data center has independent infrastructure and security. This design,
coupled with the ability to load-balance and/or shift services between the
primary data center and alternate primary data center facilities, provides for
the most robust infrastructure imaginable for the .net registry.

Heating, Ventilation, Air Conditioning (HVAC). Each data center's HVAC and
humidity control system is designed to a minimum of N+2 redundancies. This means
that two HVAC and/or humidifier units could fail (or be taken down for
maintenance), and still provide proper cooling and humidity.

Fire Suppression. Primary fire suppression is provided by a clean agent (FM200)
gas with individually activated sprinkler heads as secondary. The sprinkler
system is a preaction system, which means that compressed air keeps water from
the overhead pipes in the data center to avoid the risk of water leaks damaging
equipment. In the event of an FM200 discharge, all data center HVAC equipment
would be turned off to allow the clean agent to suppress any combustion. Only
authorized emergency response personnel can reset the system and HVAC equipment
will automatically restart. However, FM200 will not damage equipment. A data
center equipped with FM200 can be back up and running after a discharge, as soon
as the reason for the discharge is identified and fixed. No equipment cleanup is
required. Data centers, as well as UPS and battery rooms are fully protected by
FM200 gas.

Zone Protection. At the data center facilities, an extra step has been taken by
designing two separate data center zones in one facility. Each data center zone
has its own electrical infrastructure, HVAC, humidity control, and fire suppression.

Air Handlers (Air Conditioning [AC] Units). Each of these units is designed to
supply conditioned air into the subfloor to maintain the data center
temperature. Condensate pumps below each unit dehumidify the return air and pump
excess water into adjacent building storm drains. There are also water leak
detectors located underneath each unit. Each unit has a built-in alarm panel.
Air handlers, by design, are not on UPS backup due to electrical load demands.
If a power outage occurs, the units will momentarily shut off, restart within 15
seconds, and indicate a power restart alarm.

PermAlert Leak Detection Monitor. This unit uses a braided cable in the subfloor
to monitor the area for water leaks. Water will create an electrical path at the
cable and send the PermAlert unit alarm, giving the approximate distance to the
detected leak.

Fike Alarm Panel. This panel is located in the entrance area of the data center.
It monitors all the ceiling and subfloor smoke detectors in the data center and
the UPS room and battery rooms. This panel has a remote information display
(RID) unit in the NOC, which is manned 24x7x365. This is a fully cross zoned,
automatic, clean gas fire suppression system that fully complies with National
Fire Protection Agency (NFPA) 2001.

Remote Monitoring Panels in NOC. There are four generator annunciator panels,
four UPS annunciator panels, and the Fike Alarm system RID panel located in the
NOC. These panels are labeled and provide light emitting diode (LED) lights and
alarms for any change in the status of the aforementioned equipment. In
addition, the IMS mission critical equipment monitoring system is monitored by
the NOC.


Remote Facility Systems
The following specifications define VeriSign's standards for our global
constellation of DNS services that are hosted at carrier grade facilities .The
facility operator provides HVAC and other environmental components, including,
but not limited to UPS, power, breaker panels, lightning, and fire suppression,
all of which must be operational 24x7x365.

Space/Power. Physical (rack space) requirements vary by site and include
provisions for growth. Electrical service includes primary and backup power
requirements noted below:
* Power generators:
 - Dedicated to the building
 - At least twice the capacity of the electrical power of the data center
 - 48 hrs of emergency fuel reserve
* UPS:
 - Engages immediately upon power interruption to support the data center,
including cooling systems.
 - Continues to operate until power generators start up.
 - Full load battery reserve time of 15 minutes to transition to the standby
generator system


Network. The facility provides access to multiple network providers with a
minimum of 1 Gigabit (burstable) Internet connectivity.

Security. Physical access to the space is restricted to facility operator and
VeriSign personnel (or subcontractors hired by either party) who are directly
involved with the operation and support of the VeriSign Servers or who are
performing obligations of either party under a master services agreement.

Escort and/or Monitored Access Service. The facility operator provides lobby
security where badges are issued to visitors, who must sign in and be escorted.

The facility operator provides a suitable number of security personnel to patrol
the site on a regular basis, and monitor the security equipment installations at
all times throughout the year. The facility operator provides fax/email
equipment to enable VeriSign to communicate its access requirements.


Level of Technical Security

A world-class security team provides security for all VeriSign data centers.
Security measures common to all three of the discussed data centers, and at all
of VeriSign critical facilities are:
* Data center employees, including security, who go through extensive pre-hire
security backgrounds, including criminal and credit
* Highly trained, 24x7x365 security force ready to deploy the appropriate
trained emergency response protocols and procedures
* 24x7x365 secured single entrance/exit
* Tiered security zones using escalating biometrics and identification badge
access control
* Redundant monitoring from both on premises security and from the Global
Security Operation Center.

The 24x7x365 video surveillance of the external grounds, emergency generators,
exterior doors, UPS rooms, transfer switch rooms, transformer rooms, and
registry services are load-balanced between Data Center A and Data Center B in
the primary data center. Each side of the data center has separate
infrastructure and security. This design, coupled with the ability to load
balance and/or shift services between the primary data center and alternate
primary data center facilities, provides for the most robust infrastructure
imaginable for the .net registry.


Description of Building Details, Hardware, Software, and Environmental Systems

VeriSign data center facilities provide the secure underlying physical
infrastructure required to support a growing critical Internet infrastructure at
a time when external attacks (physical and logical, malicious and nonmalicious)
are an ever-growing reality. A detailed description of buildings, hardware and
software systems is provided in Table 5(b)i-1. All facilities are available for
inspection by ICANN.

VeriSign has carefully considered the choice of operating its Internet services
from VeriSign owned data center facilities or outsourced data center hosting.
Outsourced data centers are usually caged off spaces within large collocation
centers, which represent a reliability risk and also have other operational
constraints. Building and owning reliable and scalable data centers with
inherent redundant critical infrastructure is prohibitively expensive for all
but the most successful and reliable companies. The cost to build a large,
first-class data center runs into the tens of millions of dollars, and to fully
populate the data center with cutting edge servers runs into the hundreds of
millions of dollars.

VeriSign has opted to invest in owned facilities for all major data centers.
Owned facilities are not always practical or affordable in cases where a large
number of sites are necessary to extend our global network coverage.
Facility security must address the entire spectrum of threats, including:
inadvertent or malicious activity, natural disasters, and terrorist activities.
The data center facilities possess the most obvious characteristics of security,
including:
* Low profile (e.g., no external markings or signage)
* The facilities are isolated from easements, rights of way, and adjoining tenants
* Hardened against regional weather events (e.g., high winds or hurricanes)
* Located outside flood areas
* Multi-level physical security, including 24x7x365 onsite security force, badge
readers, and biometric access control devices
* 24x7x365 video surveillance.


Internet Connectivity

Internet connectivity is a critical element for any facility supporting registry
and global DNS functions. Sufficient bandwidth is the primary defense against
Denial of Service (DoS) and Distributed Denial of Service (DDoS) attacks.
Internet connectivity is provisioned through multiple providers and through
multiple physical routes. The data centers have multiple DS-3 and OC-3
connections to the Internet provisioned through diverse providers. At data
center facilities, redundant Internet connections enter the facility through
diverse cable conduits, travel to the border routers via separate conduits
within the facility, and terminate at border routers positioned in separate
cabinets in different sections of the data center. Name servers positioned with
collocation partners have a minimum of diverse 1 Gigabit connections. A
redundant, diverse wavelength division multiplexing (DWDM), dedicated optical
fiber ring is used to connect the data centers. Figure 5(b)i-3 depicts the
network connectivity at the .net sites.


Conclusion

VeriSign data centers are designated Critical Infrastructure by the U.S.
government, meaning they warrant additional protection in the event of a
national emergency. VeriSign provides world-class security for all data centers;
all systems are designed and operated to the highest specifications requisite
for critical infrastructure services. Our comprehensive technical and physical
security prevents against data tampering, system hacks, and physical break-ins.
Each VeriSign data center facility maintains redundant Internet connections with
diverse high capacity service. These provide the bandwidth for all services and
support functions and have the capacity to support the forecasted demand for .net.



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

It is critical that the .net operator provide extremely stable and high
performance resolution for this critical TLD. VeriSign has managed the largest
DNS constellation in the world for more than a decade with 100 percent
resolution availability. We have sustained this performance track record through
extraordinary growth in Internet usage and under increasing complex security
threats.

VeriSign Advantages:
+ 100 percent uptime for DNS resolution for over 7 years
+ Resolution supported by our award-winning ATLAS platform
+ Support for 20x average daily load
+ Lowest packet loss and fastest response times in the industry

The performance capabilities of this system exceed the capabilities of any other
registry. VeriSign is committed to continue providing the greatest stability
with the best performance on our world-class resolution system.

This section presents VeriSign's solution for stability of resolution and
performance capabilities, including:

* Response Times and Packet Loss Targets. Within a resolution site, our goal is
5 millisecond response time and no packet loss. We strategically locate our
resolution sites to distribute queries evenly among our global constellation and
to provide low response time and packet loss rates to all DNS clients throughout
the Internet. In practice, our monitoring shows that we meet or exceed ICANN's
Cross-Network Nameserver Response Time requirements while other registries do not.

* Availability of Authoritative Name Servers. Over the past 7 years we have a
track record of 100 percent availability of the .net resolution system. We
maintain this high level of availability with extraordinary capacity, a
redundant architecture, a cautious approach to maintenance, and extensive
monitoring.

* Processes, Tools, and Automated Monitoring to Ensure Accuracy of Zone Data for
Resolution. We maintain absolute zone data integrity through use of checksums
for file transfers, a comprehensive approach to data validation before
publication, a process that audits the zone once it is published, and extensive
end-to-end monitoring of the system from zone data generation through publication.

* Diversity of DNS Infrastructure. The .net DNS infrastructure relies on two
completely separate name server implementations of a primary system and a
warm-standby backup and uses diverse hardware and operating system software so
that no single failure or vulnerability can affect the entire system.

* Diversity and Redundancy of Network and DNS Infrastructure to Handle Bandwidth
Congestion and Network Failures of ISPs and Host Providers. The use of diverse
ISPs at our resolution sites, combined with the large number of sites, ensures
that the .net name server system can continue to function even in the face of
one or more network failures and congestion.

1. Response Times and Packet Loss Targets

(a) Measurement Perspectives

When considering DNS response times and packet loss, it is important to specify
exactly how and where these performance measurements are made. VeriSign
distinguishes performance based on measurements from two different perspectives:

(i) Intra-site performance is measured from the perspective within each of
VeriSign's current 14 worldwide resolution sites, without regard to external
factors beyond the site itself. We have very specific DNS resolution performance
goals:

* DNS response time under 5 milliseconds (5 ms). The time period from when a DNS
query is received at a resolution site, processed by our ATLAS authoritative
name server, to when a response is sent will not exceed 5 milliseconds. In
practice, our ongoing monitoring confirms that we consistently meet or exceed
this performance target at every one of our resolution sites.

* DNS packet loss of zero percent (0 percent). We strive to answer every DNS
query that reaches our resolution sites. Any level of packet loss within our
sites is unacceptable and represents a problem that must be corrected. Our
network engineers and system administrators troubleshoot any reports of packet
loss until the underlying problem is identified and corrected.

(ii) Internet performance refers to the latency and packet loss measured at
various points across the Internet. This measurement is not an easy task because
of the size and breadth of the Internet.

VeriSign's goal with .net resolution is to have the lowest latency and packet
loss possible to every possible Internet client. Achieving this goal means
deploying the maximum number of authoritative name servers in an optimal
distribution.

(b) Number of Sites

For reasons relating to maximum DNS packet size, the historical maximum number
of authoritative name servers for a single zone has been 13. Recent experiments
have shown that anycast, when used conservatively and sensibly, can expand the
number of name servers.

Choosing appropriate locations for our resolution sites is a complicated process
that is described in Section 5(b)vi. Our goal is to optimize the strategic
distribution of constellation sites all over the world. An optimal distribution
results in roughly even distribution of DNS queries among all the sites and
roughly even latency and packet loss to all DNS clients. We have stringent
facilities requirements for resolution sites that are detailed in Section 5(b)i.

Resolution site distribution undergoes constant refinement; we adjust site
locations as traffic patterns and other requirements change. 5(b)vi describes
this process in detail.

We currently use anycast technology to expand the number of resolution sites
beyond the traditional maximum of 13. We first applied anycast technology to the
j-root server to increase its capacity and reliability in the wake of the DDoS
attacks of October 2002. (The j-root servers are live at 15 sites around the
world.) Other root operators have deployed anycast as well, and our joint
experience proves that judicious use of anycast provides an excellent mechanism
for increasing the number of authoritative name servers for a zone. The root
zone is an excellent example, because some of its servers are anycast while
others remain unicast for stability and diversity. A total reliance on anycast
(that is, anycasting all of a zone's name servers such as the current
implementation used for .info and .org) is a questionable operational practice
because of unexplained problems and outages presumed to result from Border
Gateway Protocol (BGP) routing anomalies.

We have applied anycast conservatively to the .net name servers. In July 2004,
we added a 14th resolution site using anycast in Seoul, South Korea. A 15th site
in Beijing, China is planned for the first quarter of 2005, and more sites in
traditionally underserved and emerging markets are planned for 2005. Details of
these expansion plans are provided in Section 5(b)vi.

(c) Cross Network Name Server Performance Requirements

ICANN's Cross Network Name Server Performance Requirements represent a good
starting point for minimum quantifiable measurements of name server performance
for latency and packet loss.

VeriSign constantly monitors our own name server performance across several
dimensions, all of which are discussed in greater detail in Section 5(b)xvi,
System Outage Prevention. One trend we measure is latency and packet loss from
eight of our resolution sites to all of our other sites. Figure 5(b)ii-1 shows
typical cross-site latency measurements. The graphs in this figure show that
many inter-site roundtrip times from each monitoring site to multiple resolution
sites are below 100 milliseconds. The graphs also show almost no packet loss.

This same monitoring software also takes latency measurements of other TLD name
servers. As a contrasting example, measurements to the .org and .biz
authoritative servers for the same time period, shown in Figure 5(b)ii-2,
indicate higher average latency. The latency measurements show erratic response
times, which are an indication of under-provisioning and poor management. The
same graph also shows more packet loss to these servers than to the VeriSign
.net authoritative name servers.

VeriSign is committed to externally measure performance of less than 100
millisecond response time averaging less than 1 percent packet loss per month
with less than 5 percent packet loss in any 5 minute period.

2. Availability of Authoritative Name Servers

The availability of the .net authoritative name servers can be considered from
two perspectives: the availability of the system as a whole and the availability
of individual name servers.

(a) Name Server System Availability

From this perspective, all the .net name servers are viewed as a system. The
system is considered available if a sufficient number of name servers with
adequate capacity are responding to .net queries. See Appendix D for detailed
availability specifications. VeriSign's goal is nothing less than 100 percent
uptime for the .net name server system. We have met this goal for the past 7 years.

Many factors contribute to this uptime record:

* Extraordinary Capacity. We have .net name servers deployed at our worldwide
resolution sites, and each site is over-provisioned with excessive capacity.
This surplus of sites and capacity means that the .net name server system can
continue to function even when some sites are unavailable, such as in the event
of an ISP failure or a DDoS attack. For security reasons, VeriSign does not
discuss performance capabilities in detail. We can guarantee that the .net
system can continue to serve even peak query levels with only a fraction of the
14 sites available in the event of an unforeseen catastrophic failure.

* Redundant Architecture. Each resolution site is designed with a highly
redundant architecture, which is described in the next section. The resilience
and reliability of each individual site contribute to the overall system's
historical high availability. VeriSign designs redundancy at all levels into all
our systems.

* Cautious Approach to Maintenance. We have three hot standby sites, which are
exact copies of the resolution sites deployed globally. When we perform
scheduled maintenance on a resolution site, we first transfer that site's
various services to one of these backup sites. With a site's services handled by
a standby site, we can safely perform maintenance without any fear of
interrupting or impacting a production service. When maintenance is complete, we
transfer service back to the main site after exhaustive testing. Thus we do not
need to take an outage for even routine maintenance and upgrades. Standby sites
are described in more detail in Section 5(b)viii.

* Monitoring. Our extensive monitoring infrastructure, which ranges from
standard tools to monitor health of individual systems to customized tools that
report DNS-specific statistics, allows us to quickly identify and address problems.

More details on the processes we have to increase system availability are
described in Section 5(b)xvi, System Outage Prevention.

(b) Individual Name Server Availability

VeriSign also strives for 100 percent uptime of individual name servers at our
resolution sites. At each site, the .net zone is served by ATLAS, our
proprietary highly performing, highly scaling, and highly available name server.
A single .net name server site comprises the multiple systems that are part of
an ATLAS name server installation, along with various supporting network
equipment. Figure 5(b)ii-3 shows a high-level architecture illustrating the
redundancy of our ATLAS resolution sites.

The diagram clearly shows how all components at a resolution site are deployed
in at least a redundant pair configuration. This redundant architecture, present
at each of the 14 resolution sites, helps ensure that a site itself can
withstand a failure of any single component (and in some cases, multiple
components) and continue to handle queries.

The highly redundant architecture of each resolution site and the redundancy of
the overall system, along with our careful maintenance approach and
sophisticated monitoring, combines to make the .net name server system one of
the most reliable pieces of computing infrastructure in the world.

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

VeriSign considers data integrity to be an extremely serious issue. A company's
Internet presence is now a critical resource; it is therefore vital that the DNS
delegation information contained in .net always be published completely and
accurately. This section describes some of the checks VeriSign has in place to
ensure that .net zone data is always published correctly. More information about
the zone distribution and publication process is provided in Section 5(b)viii.

(a) Checksums for File Transfer

VeriSign produces .net zone data in several formats, as explained in Section
5(b)vi. Regardless of the format, whenever a file containing .net zone data
needs to be moved, we calculate a MD5 checksum over the file. The source file
and the checksum, contained in a separate file, are copied to the destination.
At the destination, another MD5 checksum is compared against the transferred
file and compared against the source checksum. This process allows us to detect
any errors in transit. Even local copies of zone data within a file system
follow this process.

When a name server loads zone data, it verifies the MD5 checksum associated with
the file as well. ATLAS was designed with this verify-on-load feature and our
engineers retrofitted this feature into Berkeley Internet Name Domain (BIND) as
well. Zone data, therefore, is completely integrity protected from generation to
name server load.

(b) ATLAS Validation

Before zone data is distributed to the ATLAS name servers at the resolution
sites, a rigorous validation process verifies the file as part of our serious
commitment to absolute data integrity. The file is loaded by a local ATLAS name
server, who contents is then compared against the registry database to ensure
that the published data will match exactly. Only then is the file published to
all resolution sites.

(c) ATLAS Auditing

The ATLAS auditor is a separate component that continually verifies that the
data served by name servers at the resolution sites matches the contents of the
.net registry database. Auditing complements the validation process.

(d) Monitoring

VeriSign has developed and implemented extensive monitoring for all aspects of
the .net registry. Some monitoring tools are standard, while others were
developed in-house to suit our particular needs. All our monitoring systems are
described thoroughly in Section 5(b)xvi.

We developed a graphical Heads Up Display (HUD) to show the instantaneous
performance and status of the .net name server constellation. Specifically with
regard to data accuracy, the HUD uses a color code to display the status of each
resolution site. This monitoring software constantly probes each .net name
server and uses color codes to indicate potential problems with a site. The HUD
also shows the status of individual near real-time updates as they propagate to
all the resolution sites. Any propagation delay of these updates, which
ultimately would cause inconsistent data among the resolution sites, is clearly
visible on the display.

4. Diversity of DNS Infrastructure

VeriSign believes diversity at all levels of the .net registry system is an
important factor in the system's stability and security. Diversity is related to
redundancy. A system with redundant components can survive the failure of one of
those components. Diversity can be considered another way to add redundancy to a
system. With sufficient diversity, no single vulnerability, failure, or attack
can affect the entire system.

At the DNS infrastructure level, we have diversity in name server software level
and in name server host hardware and operating system.

(a) Name Server Software Diversity

All .net name servers run ATLAS, which was deployed starting in November 2002.
Since that time, ATLAS has performed well, and we are very confident in its
stability and security. Because the .net zone is such a critical piece of
Internet infrastructure, we have designed diversity into the .net authoritative
name servers at the DNS software level.

We run BIND name servers in a warm standby mode as a backup to ATLAS at each
resolution site. These BIND name servers are always running with an up-to-date
copy of the .net zone. In the event of a critical ATLAS failure, these BIND name
servers can begin answering queries because a systemic failure of .net cannot be
tolerated under any circumstances.

(b) Name Server Host Hardware and Operating System Diversity

In addition to the diversity of DNS software mentioned above, we deploy diverse
hardware and operating systems for the computers on which this software runs.
ATLAS runs on two completely different hardware and operating system
combinations, guaranteeing that no single vulnerability can affect every
resolution site.

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

VeriSign designs for diversity and redundancy at all levels of the .net registry
system. In addition to the diversity specifically related to the DNS
infrastructure described above, all other aspects of the resolution system are
engineered with diversity and redundancy in mind. The way in which this
diversity and redundancy help overcome network-related problems is described below:

(a) DNS and Network Diversity

VeriSign's diversity of our resolution sites continues down to the network
level. We have two different network designs for our resolution sites. Each
design uses the same network components, as shown in Figure 5(b)ii-3, but from
different vendors. There is no vendor overlap between the two designs, so any
failure or vulnerability of a given vendor's equipment will not affect all of
our resolution sites.

At a higher level, our resolution sites do not depend on a single ISP. Our 14
resolution sites use a wider array of providers, so that a problem with a single
vendor's network will not affect all of our resolution sites.

(b) DNS and network redundancy

Earlier in this section, we described the completely redundant architecture of
our resolution sites, as shown in Figure 5(b)ii-3. We also described redundancy
at a higher level. There are 14 .net name server locations to handle DNS
queries, and just a fraction of these sites would be sufficient to answer even
the peak query loads seen today.


Conclusion

VeriSign currently manages the largest DNS constellation in the world and has
done so more than for a decade. Our system will continue to sustain 100 percent
resolution, the highest levels of stability compared with any other registry.

Our performance capabilities of this system exceed the requirements of our
current service level. VeriSign has over-provisioned extraordinary capacity and
redundant architecture, a cautious approach to maintenance and extensive monitoring.

VeriSign is committed to continue providing this world-class resolution system
for .net, meeting or exceeding our SLAs with the greatest stability and the most
performance.



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

Operational scalability is the ability to service increasing registry workloads
and the ability to ensure the system can be extended to handle the anticipated
and unanticipated demands as needs grows. To ensure a high level of service,
VeriSign uses various Quality of Service (QoS) technologies at every layer of
the .net registry.

VeriSign Advantages:
+ Proven and reliable provisioning and resolution systems have met extraordinary
scalability demands over many years
+ Experienced staff provides security and reliability through proven ability to
deflect continual abuse, inadvertent misuse of services, and DDoS attacks
+ Rapid problem resolution and root cause analysis to continually improve
processes and operations

This section presents VeriSign's approach to providing operational scalability,
including:

* Scalability sufficient to handle the projected growth of the .net registry
* DNS query capacity, including peak periods and projected growth
* DDoS attacks, viruses, worms, and spam
* Restart capabilities


Operational Scalability Sufficient to Handle Existing Registry Database and
Projected Growth

Extraordinary and unpredictable demands due to aggressive business growth or
even malicious DoS attacks are a fact of life on the Internet. We are able to
predictably deliver uninterrupted service even when demand exceeds historic peak
volumes.

VeriSign registries have maintained the operational capacity and scalability to
support domain name registrations as the demand has grown by orders of
magnitude. Initial registration rates have grown from 400 new registrations per
month in 1993 to a current rate of 1 million new registrations per month. Since
the introduction of the SRS in 1999, transaction workloads have grown by a
factor of 300, with a peak daily volume of more than 225 million transactions,
while the average transaction response time has been reduced to less than
one-twentieth of its original value. The number of registrars using the SRS to
conduct business has also grown dramatically, as shown in Figure 5(b)iii-1.

Transaction Volumes. In 2001, transaction volumes rose dramatically as
registrars began competing for deleted names, running large arrays of systems
capable of consuming 100 percent of the available .net registry's resources.
Rates of 3 million registration attempts per hour for .net are not uncommon.
Figure 5(b)iii-2 shows the historical daily average and peak SRS transactions by
quarter. The increase in 2002 was largely due to the competition for deleted
domain names. VeriSign worked with registrars and modified our operational
procedures and technical systems to greatly improve transaction efficiency for
registrars and the registry. A registry operator must have significant
scalability expertise to support this type of unpredictable behavior.

Dataset Increase. Figure 5(b)iii-3 shows the number of domain names and active
domains registered in the SRS database. This growth in registered domains was
accompanied by a rapid corresponding growth in transaction volumes. Based on
forecasts from historical data, projections of average and peak transaction
volumes are shown in Figure 5(b)iii-4. Figure 5(b)iii-5 shows the anticipated
growth of registered domains.

Scalability of VeriSign's Provisioning System

The provisioning architecture that was designed in 1999 continues to satisfy
today's demands. In addition to the Network Layer, the SRS is a three tiered
system to manage the existing load and provide sufficient scalability to address
projected growth. These tiers (see Figure 5(b)iii-6) are the Gateway Tier,
Application/Business Logic Tier, and Database Tier.

Network Layer. Our SRS network infrastructure provides bandwidth in excess of 1
Gigabit per second from multiple network providers. Additional bandwidth is
provisioned should the normal workload approach 50 percent. This provides highly
available, fault-tolerant network connectivity. The SRS is tuned such that each
registrar receives an equivalent slice of bandwidth. This is done through the
use of QoS equipment. This equipment also allows us to deflect DDoS activity,
throttle aberrant behavior, and regulate workloads to preserve system response
times.

Gateway Tier. The Gateway Tier manages registrar connections into the SRS by
stripping off the secured socket layer (SSL) encryption and forwarding commands
to the Application Layer. The Gateway Tier was designed to protect the business
logic from potential compromise by placing the registrar connection management
outside an additional firewall layer of network security and placing the
application layer inside the firewall.

Business Logic Tier. The Business Logic/Application Tier was designed to manage
the business logic of the SRS. To support both short- and long-term growth, the
Business Logic/Application Tier, along with the Gateway Tier, was designed to
scale proportionally with the needs of the registrar community. Scaling is
achieved using horizontal scaling as described below.

As the demands on the system increase, additional hardware can be safely added
to the SRS in the form of sets to accommodate the increased growth. Each set of
hardware consists of multiple gateway servers, which connect to an application
server. Adding a new set of hardware can provide an increased number of
connections into the SRS, while avoiding any impact on the existing sets. As
demand increases, scaling in the SRS can be achieved with a simple and
transparent increase in the number of sets in the system. This methodology
ensures our ability to scale and simultaneously addresses the need to maintain
high levels performance.

Database Tier. This tier is dedicated to managing the most essential asset of
the SRS -the data and historical transactions associated with all the .net
domain names. The Database Tier is designed to be scalable for both storage for
the domain name base and compute power. The current .net database is served on
the same system as that of .com. This system manages over 38 million domain
names and is capable of scaling, at its current design, to handle 250 million
domain names. The design point for the primary database was set in 2000 during
the migration to the current IBM systems, 5 years ahead of its need. We are
currently prototyping the next generation database that is being designed to
meet the .net registry needs for the next 5 years.

Capacity Planning

VeriSign has invested considerable effort and resources in delivering system
capacity to meet forecasted demands. We collect extensive amounts of data on
system performance. Dedicated operations staff analyzes this data for trends,
compare the results to historical data, and take proactive steps to ensure the
SRS scales and performs as expected.

Design Principles

VeriSign uses both vertical and horizontal scaling solutions to provide a highly
scalable application. Our systems are designed, implemented, and operated with
operational scalability as a key focus, as demonstrated by the following design
principles:

* Design systems for loads greater than peak by using peak as a starting point.
VeriSign's systems are designed to perform consistently and predictably through
anticipation of loads even greater than known peaks.
* Design for scalability to promote the growth of the .net TLD. We use the data
collected from capacity planning efforts, and incorporate design metrics that
ensure our ability to address future needs.
* Regulates system workloads to prevent crisis situations by using various QoS
technologies at every layer of the .net registry to regulate workload.
* Constantly monitor systems and QoS to protect registrars and Internet users
whose business would suffer if registry performance deteriorated.

Pool System

In response to the demand for recently deleted domain names, VeriSign designed
and deployed a pool system that ensures equivalent access and maintains
consistent system performance for the batch pool and non-batch pool activity.
Traditional registration activity, which accounts for over 95 percent of the
registration activity, is protected from what could otherwise be a daily
degradation of services.


Scalability Sufficient to Handle DNS Queries Including Peak Periods and
Projected Growth

Resolution scalability is ensuring that access to the DNS lookup service is
maintained under the most severe conditions. Using our ATLAS technology and
significant network capacity, we have deployed a highly scaleable, diverse
solution that meets our current and future DNS resolution needs.

Current Peak Periods and Projected Growth

Between March 2001 and October 2004, DNS query rates for .com and .net grew from
just over 3 billion queries per day on average to over 14 billion queries per
day, with peaks of 19 billion. This is a growth rate of over 350 percent (Figure
5(b)iii-7). Although .net comprises approximately 15 percent of our .com and
.net domain name registrations, .net is responsible for approximately 30 percent
of the DNS queries. The peak for .net queries routinely exceeds 60,000 queries
per second. During a DDoS attack, this query rate can easily exceed many
multiples of the routine peaks.

Scalability of DNS Resolution

DNS resolution is the most critical component to maintain Internet stability.
Poor resolution can cripple Internet traffic and negatively impact a vast number
of daily business transactions. During a DDoS attack, the query rate may be
several times the typical peak. We place the highest priority on delivering 100
percent availability and we work diligently to maintain the capacity to support
growth without sacrificing performance. VeriSign's patented ATLAS technology
ensures that we can scale to achieve this lofty objective.

By 2011, we project that DNS query rates for .com and .net will grow to over 120
billion queries per day (Figure 5(b)iii-8). Given historical growth rates of
Internet hosts and forecasted growth of new devices, .net is projected to
account for approximately 40 billion queries per day, which will require a DNS
capacity of 800 billion queries per day. The capacity of our current ATLAS
generation supports loads exceeding 400 billion daily queries, with planning
efforts underway to ensure the next generations of VeriSign's DNS solutions can
handle millions of queries per second well before 2010.

Network Capacity and Segregation

To accommodate ever-increasing DNS traffic, every site in our DNS resolution
constellation is provisioned with at least one Gigabit of network bandwidth with
redundancy and fault tolerance facilitated through multiple network providers.

Each site is located at a major telecommunications peering point in which
various large ISPs have established hubs for management of their portion of the
Internet backbone. In 2005, we are scheduled to expand our constellation
footprint with an additional site in Asia and plans for future sites in South
America.

Capacity Planning. Extraordinary and unpredictable demands, in the form of
legitimate commerce or malicious DoS attacks, are a fact of life on the
Internet. Our centralized DNS data store, fed by statistics relayed by the
various monitoring applications located at each site, currently houses daily
statistics dating to the year 2000. Data is collected every 4 seconds and stored
with an extremely fine granularity at the IP, TCP/UDP, and DNS levels. The
database and related tools allow for on-the-fly report and graph generation. Our
technical staff uses these tools to analyze any combination of statistics for
any specified time period and compare new trends against historical data. These
records also feed our detailed uptime and traffic growth analysis and reporting
efforts.

Our continuous monitoring and planning initiatives enable us to trend demand
versus usage and legitimate versus malicious activity. These valuable statistics
help build the right scenarios to test our ability to maintain this "always on"
capability. Stress testing, load testing, and performance testing are emphasized
to deliver a robust and stable system. Our current DNS solution has been
designed and tested to scale well beyond 400 billion queries per day, with peaks
of 2.3 million queries per second.


DDoS attacks, viruses, worms, and spam

The experiences we have garnered over the years have led us to realize that
existing guidelines for DNS operators are not adequate for critical TLDs that
are continually under attack (both intentional and unintentional). The Root Name
Server Operational Requirements (Request for Comment [RFC] 2870) provides
guidelines for root zone management that also serve as a guide for the operation
of other major zones such as the .net TLD.

Section 2.3 of RFC 2870 states: "At any time, each server MUST be able to handle
a load of requests for root data, which is three times the measured peak of such
requests on the most loaded server in then current normal conditions."

Experience in managing the resolution of .net and other major TLDs led VeriSign
to implement a capacity requirement much larger than recommended in RFC 2870.
This includes availability during DDoS attacks, increases in network traffic due
to viruses and worms, spikes that occur as a result of occasional third-party
DNS configuration errors, and spam. VeriSign's position on managing these types
of events is a simple one: to be able to subdue an attack on the Internet, one
must first be able to withstand it. If the event can be withstood, it can then
be analyzed, allowing for the necessary countermeasures to be implemented. This
approach has served us well and ensures our ability to withstand extreme
increases in query load.

VeriSign's DNS constellation has experienced extreme fluctuations in DNS traffic
as a result of DDoS attacks, viruses, worms, and spam; however, some of the most
significant spikes have come from unintentional misconfigurations of DNS entries
by various individuals and corporations. Due to our vigilant monitoring and
practice of over-provisioning resolution capacity, none of these events has
impacted the availability of DNS services for .net, even though some of these
events have caused peak load to increase by more than 200,000 queries per
second. As Internet usage continues to rise, these events are certain to
increase in frequency and intensity. Specific examples of these incidents are
extremely sensitive. Due to security concerns, these are not publicly disclosed

One of the most effective tools for resolving end user configuration errors has
been the rapid update of DNS information. Because 95 percent of .net updates are
available on our global constellation within 3 minutes, correcting a
configuration error can be quick and straightforward.


Restart Capabilities

Restart capabilities allow the registry operator to rapidly recover from any
catastrophic event and ensure minimal interruption to the Internet community
worldwide. These capabilities are addressed for the provisioning systems and DNS
resolution services.

Provisioning System Restart Capabilities

The redundancy built into SRS architecture allows for very flexible restart
capabilities. This is demonstrated by the fact that VeriSign operated the .net
registry at an exceptional reliability exceeding 99.98 percent over the past 3
years. In addition, VeriSign provides the ability to rapidly recover the .net
registration systems from events that can disrupt registry services. This is
accomplished by maintaining a fully operational alternate primary site that is
built as an exact copy of the primary.

Under most circumstances, restoring service at the alternate primary data can be
accomplished within 30 minutes from the time the event is identified. Since
registry transactions flow through the alternate primary data center in
real-time as part of normal business, connectivity to the facility is ensured.

Procedures for Testing Restart. Well-developed and thoroughly documented
procedures are vital for restarting .net registration services. The procedures
must be rehearsed regularly to minimize outage time and maintain data integrity.
VeriSign periodically tests failure scenarios and the procedures for restart. We
maintain a staging environment that provides the opportunity to practice
database and system restart without impacting production operations.

During production maintenance periods, we also take the opportunity to test
high-availability database failovers. These procedures include database failure
scenarios and test our ability to restart production databases and application
servers within minimal time standards.

DNS Restart Capabilities

VeriSign's DNS constellation has operated at 100 percent availability since
1997. Still, the possibility of a catastrophic failure remains a reality. The
ability to restart a DNS service after such an event is complicated by the fact
that any restarted service will experience load spikes as clients turn to it for
service. The ATLAS architecture includes two attributes that mitigate this effect.

The first attribute is an approach to congestion avoidance that answers the
maximum number of requests within reasonable timeouts to avoid excessive
queuing. In the ATLAS architecture, this congestion avoidance is implemented by
the protocol engine (PE), which allows the lookup engine (LUE) to continue to
perform at maximum rates. The standard testing procedures for ATLAS resolution
sites include saturating the network with queries.

The second attribute of ATLAS that helps it withstand extreme loads is simply a
very large capacity. Having enormous capacity at individual sites lessens the
burden and coordination required during restart, and minimizes the critical
overload period.

VeriSign maintains a minimum of three additional sites, known as hot standby
sites. These sites are activated when any of the resolution sites are taken
offline for routine maintenance, or if there were an unplanned loss of service.
As a result of these regular maintenance activities, we have extensive
experience restarting a DNS site. This operation is transparent to end users. If
the need occurs, we can switch operations from a failed DNS resolution site to
any of our three hot-standby sites within an hour.


Conclusion

VeriSign has built proven and reliable DNS and SRS systems that have exceeded
every operational scalability challenge over the past decade. Our systems
provide the operational scalability sufficient to handle the existing registry
database and projected growth. Our provisioning system has successfully
supported extraordinary and unprecedented demands through meticulous capacity
planning while using the scalable design of the SRS and database.

Our resolution forecasting, capacity planning and early deployment of scalable
systems have ensured exceptional DNS responsiveness with 100 percent
availability. The resolution infrastructure currently deployed supports a
request load at least 20 times higher than peak loads, and capacity is
continually being increased which mitigates risks from DDoS attacks, viruses,
works, and spam.

The redundancy built into the SRS and DNS architecture of VeriSign's .net
registry and the procedures rehearsed regularly allow for very flexible restart
capabilities.



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

The Registry-Registrar Model and Protocol describe the operational structure
used for registry-registrar interaction and the communications language used
between them. The structure and language are important because they define and
constrain the features and functions available to both registries and
registrars. A poor model or a poor protocol can place needless restrictions on
the features available to Internet users and the business models available to
registries and registrars. Additionally, the various models and protocols have
privacy implications for the holders of domain names.

VeriSign Advantages:
+ Authorship of Registry-Registrar protocols
+ Experience operating both RRP and EPP
+ Offer the lowest risk, highest performance, and most stable registry-registrar
model and protocol for .net

This section describes VeriSign's .net registry-registrar model and protocol
proposal:
* Registry-Registrar Model and Protocol. VeriSign will continue to support the
existing "thin" registry-registrar model using the Registry-Registrar Protocol
(RRP) documented in RFC 2832. We will deploy the Extensible Provisioning
Protocol (EPP) in 2005 as part of a transition plan that has been coordinated
with the registrar community to minimize stability risks. We will also explore
the possibility of a separate transition from the "thin" registry-registrar
model to the "thick" registry-registrar model in cooperation with the ICANN
community.
* Availability of a Shared Registration System. VeriSign consistently exceeds
our SRS requirements for SLA availability. We will continue to provide the most
stable and reliable SRS in the domain name industry.
* Processing Times for Standard Queries (add, modify, delete). VeriSign's SRS
consistently delivers the best performance. Our monthly average response time of
15 milliseconds for add, modify, and delete transactions and 10 milliseconds for
query transactions is more than 10 times faster than other registry operators.
* Duration of Any Planned or Unplanned Outages. VeriSign consistently meets and
exceeds our SLA requirements, providing a stable, reliable SRS for our registrar
customers.


Registry-Registrar Model and Protocol

In 1997, the United States Department of Commerce (DoC) issued an RFC on DNS
administration. The RFC solicited public input on issues relating to the overall
framework of the DNS administration, the creation of new TLDs, policies for
domain name registrars, and trademark issues. The comments received led the DoC
to publish two papers to explore the issues associated with changing the
InterNIC model. The first paper, "A Proposal to Improve the Technical Management
of Internet Names and Addresses," and known more commonly as the "Green" paper,
was published in January 1998. Discussions followed, and the concepts presented
in the Green paper were refined into a proposal that was presented in a second
paper titled "Management of Internet Names and Addresses." This second paper,
published in June 1998, is more commonly known as the "White" paper.

Both the Green and White papers described a model for competitive registrars
working with a shared registry. When this model was put into practice, two
distinct models ("thin" and "thick") of registrant data management evolved.

A thin registry model is a data management model in which information associated
with each registered domain name is distributed between the registry and the
sponsoring registrar. The registry maintains delegation information needed to
publish the DNS zone, while the registrar maintains information describing the
registrant and other contacts (such as technical, administrative, and billing)
associated with the domain.

A thick registry model is data management model in which the registry maintains
copies of all information associated with registered domains, including
registrant and contact information. Registrars typically maintain their own
copies of registration information; therefore, registry-registrar
synchronization is required to ensure that both registry and registrar have
consistent views of the technical and social information associated with
registered domains.

Registry-Registrar Protocol: The "language" used by registries and registrars to
exchange information is known as a protocol. While different registry-registrar
communities have used different protocols over time, two protocols have been
developed and widely deployed to implement the concepts described in the Green
and White papers.

Network Solutions, Inc., (NSI) Registry-Registrar Protocol (RRP) has been used
in the management of .net since April 1999. Designed and developed by NSI (and
later VeriSign) architects, and first documented publicly as Informational RFC
2832, this protocol is tailored for use in the thin registry model currently
used for .net.

The Extensible Provisioning Protocol (EPP), designed and first developed by
Scott Hollenbeck of NSI (and later VeriSign), was first published in November
2000. EPP was designed to provide features unavailable in RRP. It addresses
requirements of additional registries, for example, by providing features to
support both thick and thin registry models. EPP also supports provisioning of
products other than domain names. EPP was adopted by the Internet Engineering
Task Force (IETF) "provreg" working group and published as a series of
Informational and Proposed Standard RFCs (3730, 3731, 3732, 3733, 3734, and
3735) in March 2004.

VeriSign's Solution: VeriSign plans to deploy EPP for use with .net in the first
half of 2005. This effort will require a transition from RRP to EPP. VeriSign's
transition plan provides the lowest risk solution for migrating from RRP to EPP
by allowing registrars to operate both protocols in parallel until both registry
and registrar implementations of EPP can be confirmed to be completely
operational. The VeriSign transition plan has been developed in conjunction with
the registrar community, ensuring that acceptance and adoption will proceed with
minimal risk.

Both RRP and EPP have been extended to add support for functions not described
in the core protocol specifications. VeriSign's implementation plan includes
support for current RRP extensions used by .net (including migration of those
extensions to an EPP implementation), while gradually adding support for EPP
extensions to support new features, such as those defined for ICANN's redemption
Grace Period and DNS security.

VeriSign proposes to continue parallel support for RRP, while deploying and
testing a fully RFC-conformant implementation of EPP. Continued use of RRP,
while gradually transitioning to EPP, provides several advantages that help
preserve the stability of the .net gTLD:

* Registrars have gained significant operational and business logic experience
with VeriSign's implementation of RRP. Initial use of RRP, with the existing
VeriSign infrastructure, ensures that transition risk to another registry
operator, with a newly developed implementation of RRP, is absolutely eliminated.

* VeriSign has been able to optimize its RRP implementation to the point of
being able to support peaks of more than 183 million transactions per day, and a
sustained daily average of more than 170 million transactions per day for a
month, and up to 300,000 transactions per minute. No other registry operator has
demonstrated similar processing capabilities with RRP.

* RRP is stable. Parallel use of RRP will support registry operations that have
no timetable dependencies on the migration to EPP.

* Both registries and registrars are still gaining experience with EPP, which
became a proposed standard in March 2004. Initial implementations are likely to
have defects, and performance limitations that can only be discovered and
corrected over time.

VeriSign will use its existing RRP implementation, designed and developed by the
original authors of the protocol, as a springboard to a full migration to EPP.
Our RRP implementation has been refined, optimized, and tailored to ICANN
processes over the course of 5 years of high-pressure, high-volume registry
operations. RRP provides registrars with levels of real-time service and
performance unmatched in the domain name industry. Satisfactory levels of
stability, reliability, and error-free performance are guaranteed with this
implementation of RRP.

VeriSign has been the driving force behind the specification of EPP and has been
developing implementations of EPP for several years. Our first implementation
was developed in 2001, based on Internet-draft EPP specifications for the
provisioning of Internet keywords. A second implementation was developed and
deployed in 2001 to support operations of the .name gTLD registry. That
implementation has been refined and updated over time and is still in use today.
Finally, VeriSign has developed and deployed an RFC-conforming version of EPP
for the provisioning and management of domain names in the .cc, .tv, and .bz
country code top-level domains (ccTLDs). An active project is in place to deploy
EPP for use in the provisioning and management of domain names in the .com and
.net gTLDs in 2005.

Our early implementations of EPP have already been subjected to several rounds
of development and formal QA testing. With protocol stability and transition
costs being a significant concern in the ongoing management of .net, VeriSign
will provide registrars with extensive "hands-on" support for several months to
facilitate the transition from RRP to EPP. During the transition period,
registrars will be able to access consistent back-end registry data using both
RRP and EPP. Free client software development kits (SDKs) that interoperate with
other EPP servers will be available in multiple programming languages to
minimize the amount of software development required of registrars. An isolated
operational test and evaluation (OT&E) environment will be available for
registrar testing before "live" operations, allowing registrars to develop and
test their software systems with no risk to "live" data or systems. Issues,
defects, and errors found during OT&E testing will be corrected rapidly and
deployed in both the OT&E and "live" environments, ensuring that both
environments use the exact same software code bases, and that transition will
require little more than minor changes to client configuration parameters. A
detailed description of the transition plan for retiring RRP and deploying EPP
is provided in Section 8-9.

The migration solution proposed by VeriSign is one that has been developed in
coordination with the registrar community as part of the migration to EPP for
the .com gTLD. Unlike the earlier transition of RRP to EPP that was proposed and
implemented by PIR/Afilias as part of the .org migration, our solution allows
registrars to update and deploy their systems using registry-provided tools and
services on a schedule that works for them. Our transition effort will be
conducted as a partnership between VeriSign and its registrar customers.


Availability of Shared Registration System

The availability of the SRS directly impacts the ability of the registrar
community to operate its businesses efficiently. SRS availability is affected by
multiple factors, including unplanned outages and planned outages for scheduled
maintenance or system upgrades.

The registry must also maintain SRS availability and performance, while
providing registrars with equivalent access and supporting the large transaction
volume without performance degradation. VeriSign currently sets a minimum of 15
connections for each registrar with 3.5 Gigabits per second of bandwidth equally
divided among all registrars.

The principal indicator of VeriSign's QoS approach is historical availability of
the SRS, which has been consistently above 99.9 percent over each of the past 7
years and has averaged 99.98 percent since January 2002. This level of ensured
availability is of the utmost importance to registrars because unexpected or
extended outages create operational and business challenges.

Table 5(b)iv-1 compares published gTLD availability statistics; the information
summarized is reported monthly by each gTLD and is posted on the world wide web
at http://www.icann.org/tlds/monthly-reports/. Note that .info and .org do not
report planned outages exceeding the Planned Outages SLA as unplanned outages.

Table 5(b)iv-1 shows that during comparable periods, VeriSign consistently
delivers the highest planned availability for .net that is well above the .net
SLA, while other registries frequently miss their SLA. The overall impact to
registrar business is not obvious in the gross percentages; however, more
detailed analysis highlights the registrar impact from the average duration of
outages and chronic excess time required for planned outages.


Processing Times for Standard Queries

VeriSign delivers exceptional processing times for SRS queries. VeriSign's
performance and testing on the effects of load on the registry system are
discussed in detail in Section 5(b)v. VeriSign will commit to improved SLA
response times of 50 ms for add operations and 100ms for delete and modify
operations for 95 percent of all transactions.

Actual response times and the standard deviation of those times vary greatly
among the TLDs operated by different registry providers. The exceptionally rapid
response times for .net consistently exceed those of other registries.
Inconsistency in response times of other registries is indicated by the large
standard deviation. VeriSign's load and stress testing has shown that a large
response time deviation is an indicator of inability to scale under increasing
transaction loads. This appears to be the case in other registries where
increasing response times are closely correlated to increasing transaction
volumes. The standard deviations reported reflect only deviation of monthly
averages, since more granular information is not reported. Average times are not
reported for .biz. This information is published monthly on the world wide web
at http://www.icann.org/tlds/monthly-reports/.

* .net (VeriSign):
 - 15 ms average add/write response time
 - 6.6 ms standard deviation add/write response time
 - 10ms check/query response time
 - 0 ms standard deviation check/query response time

* .com (VeriSign):
 - 15 ms average add/write response time
 - 6.6 ms standard deviation add/write response time
 - 10 ms check/query response time
 - 0 ms standard deviation check/query response time

* .biz (NeuLevel):
 - 99.7 percent within 3 sec (3000 ms) average add/write response time
 - unknown standard deviation add/write response time
 - 99.9 percent within 1.5 sec (1500 ms) check/query response time
 - unknown standard deviation check/query response time

* .info (Afilias):
 - 823 ms average add/write response time
 - 552 ms standard deviation add/write response time
 - 212 ms check/query response time
 - 115 ms standard deviation check/query response time.

* .org (PIR/Afilias):
 - 1527 ms average add/write response time
- 539 ms standard deviation add/write response time
 - 168 ms check/query response time
 - 140 ms standard deviation check/query response time.


Duration of Planned or Unplanned Outages

Scheduled maintenance is required for a registry to maintain predictable,
reliable service. Scheduled maintenance is announced at least 30 days in advance
of each planned outage. We also remind registrars of scheduled maintenance at 7
days, 48 hours, and a final announcement the day of maintenance. These planned
outages are scheduled during 0100 to 0900 GMT on Sunday to minimize the impact
on registrar operations. Planned outages will not exceed 45 minutes per month,
with a target SLA of 99.99 percent availability.

Occasionally, system maintenance tasks, such as a major database upgrade, cannot
be performed within the 45 minute maintenance window. Once per year, VeriSign
may incur a 4 hour planned outage. No more than once every 3 years, VeriSign can
incur one extended planned outages of up to 8 hours in duration. Extended
planned outages represent total allowed planned outages for the month. Extended
outages have been required for the .net registry only twice in the past 4 years.
Before a planned outage, the maintenance on the .net registry is staged and
rehearsed in an operations staging area to minimize the risk of a problem with
the system or a problem with the time require to complete the maintenance. Table
5(b)iv-1 shows the results of this practice with VeriSign never exceeding the
planned outage SLA. The planned outages for the .net registry have always been
within the SLA terms and never exceeded the time announced for scheduled
maintenance.

As shown in Table 5(b)iv-1, the frequency and duration of VeriSign's unplanned
outages are the lowest in the industry. Outages can be caused by any number of
factors; our experience has shown that unplanned outages are not caused by a
single event, but most occur from a combination of events that include unique
failures of hardware and/or support systems. This reinforces the need for
in-depth monitoring and immediate access to experienced staff for
troubleshooting as well as access to third-party support staff to quickly
restore systems, regardless of external dependencies. The .net registry has not
had an unplanned outage that caused any data corruption or was caused by a
problem with the registry system itself. The architectural redundancies of the
.net registry have prevented a number of incidents, such as a routine hardware
failure or loss of electrical power, from becoming outages. These are often
resolved without any impact noticeable to registrars.


Conclusion

VeriSign offers the lowest risk, highest performance, and most stable
registry-registrar model and protocol for .net. Our engineers are recognized
industry leaders in the design, development, and deployment of these
technologies. Our demonstrated excellence in operating .net stands in sharp
contrast to the documented performance of our competitors. We are committed to
maintaining the same levels of stable performance that we have demonstrated to
date, and we are equally committed to exceeding our historic performance levels
in the future.



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

The primary online transaction processing (OLTP) database is the most critical
element of the .net registry provisioning function. To support .net at current
levels, the registry operator must demonstrate the ability to support over 5
million domains and transaction peaks of 100,000 operations per minute without
degraded performance or increased risk of data corruption.

VeriSign Advantages:
+ Unparalleled, proven reliability with 100 percent data integrity and low downtime
+ High performance platform designed to process registry functions
+ No Data Loss architecture complete with fully redundant, alternate primary site
+ Incremental zone propagation hosted on award-winning ATLAS platform

The Oracle OLTP database used by VeriSign (currently version 9i) has delivered
years of scalability, performance, and security to .net registrars and Internet
users. Our long-term relationship with Oracle has resulted in over 13 years of
experience managing the current .net database with a record of 100 percent data
integrity, no data loss, and unparalleled uptime.

Our .net registry database architecture is scalable to over 250 million
registrations while still operating within our SLAs and providing robust
business continuity capabilities. This description includes a description of the
following database capabilities:

* Database Software, Size, Throughput, Scalability. VeriSign emphasizes the
performance, throughput and scalability of the .net database in every decision
made to the .net database architecture.
* Procedures for Object Creation, Editing, and Deletion. Every modification made
to objects within the .net registry database is audited and traceable back to
the registrar, session, and transaction that initiated the modification.
* Change Notification. We have developed a notification framework that can scale
to millions of messages.
* Registrar Transfer Procedures. VeriSign is fully compliant with the most
recent transfer policies intended to protect the interests of registrants and
ensure the stability of the .net domain.
* Grace Period Implementation. Verisign uses an extensible grace period
framework that supports an array of grace period rules and permits rule changes
to occur in real-time and without system outages.
* Availability with Respect to Unplanned Outage Time. VeriSign's .net database
system maintains multiple live copies of the OLTP database both onsite and
offsite to provide data recovery without data loss from a complete failure of
all primary data systems.
* Response Time Performance. VeriSign's .net database processes check
transactions in less than 10 milliseconds and add transactions in less than 20
milliseconds, while processing transaction volumes that vary from 30 million to
over 200 million per day.
* Ability to Handle Current Volumes and Expected Growth. The .net registry
database architecture has been engineered to handle enormous growth leveraging
Oracle's partitioning features.
* Reporting Capabilities. VeriSign maintains a real-time copy of our databases,
which is used strictly for reporting purposes; this prevents report processing
demands from degrading the performance of the registry database itself.


Database Software, Size, Throughput, and Scalability

This section discusses the primary databases required for the .net TLD,
including the registry, resolution, and Whois databases.

Registry Database

The .net registry database uses Oracle technology and is designed and tested to
host a minimum of 250 million registrations, while operating within strict
performance levels. The database provides robust business continuity
capabilities that exceed projected capacity requirements over the next 6 years.
It has a proven history of handling more than 200,000 transactions per minute on
a continuous basis, with peaks of more than 300,000 per minute and more than 4
billion per month. In handling this massive transaction volume, VeriSign's .net
registry consistently exceeds the best SLAs in the industry; typically
processing check commands in an average of less than 10 milliseconds and add
commands in less than 20 milliseconds. Figure 5(b)v-1 illustrates the average
daily transaction volumes, and the average daily peaks for the period from Q2
2000 through Q3 2004.

The reliability and scalability of our database architecture are based on the
application of a diverse set of hardware and software systems. The technologies
listed below are a subset of the technologies used to run the .net registry and
are considered the best of breed in the industry:

* IBM High Availability Cluster Management Protocol (HACMP) is a dual-node
cluster of redundant database servers that host the registry database. If one
server of the cluster fails, the architecture automatically fails to a second
server so that database processing can continue with minimal disruption.
* EMC Symmetrix Remote Data Facility (SRDF) synchronously mirrors the entire
primary database in real-time to a remote EMC storage device, while EMC
Timefinder software is used to make frequent, identical copies of the database
for backup, reporting, and other purposes.
* Oracle Partitioning segments large volumes of data grouped by month and year
so that database responsiveness and performance can remain stable as size increases.

The .net registry database leverages these technologies to create a scalable,
fault tolerant database architecture where copies of the database are replicated
and stored in different locations, as shown in Figure 5(b)v-2. VeriSign enjoys
preferred-vendor relationships with IBM and Oracle and has a technical
representative from EMC working onsite.

The .net database is replicated within the primary data center facility, in
addition to being replicated to a geographically diverse alternate primary site.
EMC SRDF software provides real-time replication of the .net registration
database to the alternate primary site. In case of site failure, the full .net
registry data is available in near real-time at the alternate primary site. The
alternate primary site is designed to replicate the primary site database
systems and uses identical servers and storage, so that registry activities can
continue with no performance or functionality degradation. VeriSign frequently
rehearses the failover procedure to ensure that the site is fully operable in
the event of a disaster.

Multiple copies of the database significantly reduce the possibility of data
loss or corruption and allow for rapid recovery of services in the event of a
disaster. Tape backups and transaction logs are generated and stored in the
unlikely event that they are needed. Refer to Sections 5(b)x and xi for
information on backup and data escrow processes and Section 5(b)xviii for more
information.

Resolution Database
Our zone generation process, described in detail in Section 5(b)vii, begins with
a change of .net zone information in the SRS database. VeriSign's award-winning
and innovative ATLAS system then extracts zone information and changes from the
database. Incremental zone file updates are extracted from the database within 1
minute, then validated and subsequently distributed via a secure virtual private
network (VPN) to another set of distribution servers at each site in the
VeriSign DNS constellation, which is described in detail in Section 5(b)xviii.
The zone updates are then loaded into multiple in-memory databases for
publication, making the new information available for DNS query resolution. In
addition, a full copy of the .net zone file is extracted twice daily to provide
a recent full copy of the .net zone.

Whois Database
The VeriSign Whois system, described in Section 5(b)xii, offers domain name,
name server, IP address, and registrar search capabilities. Redundant Whois
databases at each data center provide dependable Whois service. Each Whois
database is based on a duplicate, point-in-time copy of the primary .net OLTP
database servers.



Procedures for Object Creation, Editing, and Deletion

Verisign maintains stringent procedures for the creation, editing, and deletion
of any object within the .net registry database. Modification to objects can be
traced to the appropriate registrar using transaction and session level auditing
within the application. Verisign maintains auditing fields within every object
that captures when it was last modified and by whom. Pre- and post-copies of
each object are captured when a transaction has completed. All objects within
the database adhere to these procedures including domains, name servers, IP
addresses, both RRP and EPP statuses, and their associated links. All historical
data, dating back to 1999, is archived to a separate Oracle database with the
full transaction and object modification history.

This tracking is particularly important for financial transactions, and the
integration of the .net registry with the VeriSign Registrars Billing and
Collection System (RBACS), which is detailed in Section 5(b)ix.


Change Notification

Registrar interaction with the .net registry database occurs either through an
Application Program Interface (API) or through a web-based tool. Change
notifications for registrars using the Registry Registrar Protocol (RRP) are
delivered by email. With the introduction of VeriSign's implementation of EPP,
notification of registry changes occur through poll queue messages to support
increased automation of registrar operations. Our poll queue implementation uses
Oracle Advanced Queuing and can scale to thousands of registrars and millions of
messages. Refer to Section 5(b)iv for more information on the benefits of
registry interaction through EPP.


Registrar Transfer Procedures

VeriSign is fully compliant with the Inter-Registrar Transfer Policy that
protect the interests of registrants and enhance the stability of the .net domain.

The following process outlines domain name transfers between registrars:
* The requesting registrar processes a transfer request on behalf of the
domain's registrant.
* The transfer request includes a minimum of a 1-year extension. Our EPP
implementation, described in Section 5(b)iv, allows registrar to specify
multi-year extensions with transfer requests.
* The registrar of record has 5 days to acknowledge or reject the transfer
request through the SRS.
* If acknowledged, the transfer is immediately executed.
* If rejected, the transfer is cancelled, and transfer fees are credited to the
requesting registrar.
* If the registrar of record does not respond within 5 days, the transfer is
automatically processed by the system and the transfer is completed.

In the event of the default, acquisition, or closure of a registrar, the .net
database has a bulk transfer capability to transfer domain registrations to
another registrar either en masse or according to a specific list of domain
registrations, per ICANN's specification.


Grace Period Implementation

Grace periods, pending periods, and overlapping periods comprise a complex set
of rules with a large number of corner cases and what-if scenarios. VeriSign has
implemented and refined the specific rules covering these cases and maintains a
library with tens of thousands of test cases. These are critical to adequately
validate proper functionality is maintained through every system update and
ensure registrars are correctly credited for any transactions that fall within
the grace period rules.

In the current .net database, grace periods are configurable. In the event that
changes to the current grace period implementations are considered, VeriSign is
prepared to cooperate fully with ICANN and the Internet community with regard to
proposed changes.

A detailed description of system behavior for each type of grace period is
available in VeriSign's Registrar Reference Manual, which is available on
request or through our website. The following paragraphs contain brief
descriptions of the various grace periods:

Add Grace Period. This is a specified number of calendar days, currently 5 days,
following the initial registration of a domain. The system ensures that if a
domain is deleted or explicitly renewed during this grace period, then the
appropriate business logic is executed.

Explicit Renew Grace Period. This is a specified number of calendar days,
currently 5 days, following the explicit renewal of a domain. The system ensures
that if a domain name is Transferred, Deleted, or Explicitly Renewed during this
grace period, the appropriate business logic is executed.

The Auto Renew Grace Period. This is a specified number of calendar days,
currently 45 days, following the auto renewal of a domain. The system ensures
that if a domain is Transferred, Deleted, or Explicitly Renewed during this
grace period, the appropriate business logic is executed.

Transfer Grace Period. This is a specified number of calendar days, currently 5
days, following the transfer of a domain. The system ensures that if domain is
Transferred, Deleted or Explicitly Renewed during this grace period the
appropriate business logic is executed.

Redemption Grace Period. This is a specified number of calendar days, currently
30 days, following the deletion of a domain name that is outside the Add Grace
Period. The system permits a registrar to restore a previously deleted domain name.


System Availability with Respect to Unplanned Outage Time

VeriSign's .net database systems can fully recover from a complete failure of
all its primary data systems to an alternate data center site without data loss.
The reporting database is an archive database of all registry transactions since
the very first day of registry operations. It can be updated from the primary
database without downtime and can respond to queries 24x7x365. As with all
complex hardware and software systems, every risk and contingency must be
considered and accounted for in prevention and recovery processes. For the
volumes and load that the .net registry database must support, VeriSign believes
that recoverability starts with the design of the database and continues into
the hardware architecture, software architecture. Our investment in the .net
database architecture supports VeriSign's commitment to system availability of
99.99 percent. Refer to Section 5(b)xviii for detailed description of these
recovery procedures.


Response Time Performance

The .net OLTP database must provide consistently rapid responses. Historically,
most registry transactions are commands to check domain availability and to
register domains. The .net registry will continue to process check commands in
less than 25 milliseconds seconds, add commands in less than 50 milliseconds,
and modify and delete commands in less than 100 milliseconds. Refer to Table
5(b)v-1 for a comparison of historical performance and proposed service levels.
Section 5(b)xiv provides information about response time performance under peak
capacities.


Ability to Handle Current Volumes and Expected Growth

Based on thorough consideration of the following architectural design and
implementation factors, VeriSign's database has remained stable and scalable:

Capacity. The current VeriSign .net database has a demonstrated ability to
process more than 5,000 transactions per second (300,000 transactions per
minute) during peak periods. Beyond handling transactional volume, the .net
registry database is also designed with capacity ample enough to store
information associated with 100 million domain name registrations. To meet
capacity requirements dictated by overall registry activity and registrar
demand, the .net registry database must be integrated with the entire registry
architecture. Our database has been designed as a component of the entire
system, including server performance, bandwidth, network architecture, business
rule logic, batch processing, monitoring and reporting, data backup, escrow, and
disaster recovery. The system supports a high transaction volume that varies
over time, with minimal variation in response time and central processing unit
(CPU) use, as described in Section 5(b)xiv.

Scalability. VeriSign's database is designed to support sustained loads of over
200 million transactions per day with daily peaks of over 250 million
transactions. VeriSign designs its registries to meet unexpected growth demands
for every variable, including growth in the number of registrars, transaction
volumes, and database size. In addition, the .net registry database has the
capacity to scale well beyond current growth projections. The database is
horizontally scalable to support the most optimistic growth forecasts over the
next 6 years by increasing capacity of the storage arrays.

Reliability. VeriSign has operated the .net registry with unparalleled
reliability and availability with 100 percent data integrity and with no
unplanned outages due to database failures. Our .net database has a
well-established history of providing the performance, availability, and data
accuracy necessary for reliable and trusted operations. These qualities of
VeriSign's database have been achieved through: a proven and highly available
architectural design, a high degree of technical and operational database
expertise, and by maintaining a close relationship with a carefully selected
group of hardware and software vendors. These combined factors help minimize the
risk of data loss and service outages.


Reporting Capabilities

VeriSign maintains a real-time copy of our databases for reporting purposes to
prevent processing demands from our reporting process from degrading the
performance of the registry database itself. This database copy, called the
Critical Data Archive (CDA), is used by the reporting component of RBACS,
described in Section 5(b)ix, to generate a variety of daily, weekly, and monthly
reports. In compliance with equivalent access requirements, each registrar has
access to their data in identical report formats. The CDA is also used to
generate the monthly ICANN registry reports.

The various audits that VeriSign undergoes as part of our normal operations rely
heavily on these robust reporting capabilities. The full list of VeriSign
audits, their scope, and their frequency is described in Section 5(b)xiii.


Conclusion

VeriSign's experience with Oracle 9i is the foundation for the fastest, most
reliable database system deployed by any TLD registry operator. VeriSign
maintains critical database administration procedures and monitoring
capabilities to deliver the overall reliability, availability, and performance
of the various .net registry database systems.

VeriSign maintains data centers that contain identical hardware and software
systems. Fail-over is rehearsed frequently to confirm the viability of each
site. Each data center is fully functional as a primary site with no degradation
of performance. In the case of a system fault, we can fully recover from a
complete failure of all its primary data systems to a remote data center site
without data loss.

VeriSign processes transactions with the most consistent, rapid response times
of any TLD, while processing transaction volumes that range from 30 million to
over 200 million per day. These transactions rely on our proven implementation
of the complex interdependencies associated with grace periods and pending periods.

VeriSign's database architecture has remained stable and scalable because
VeriSign designed and built this powerful, innovative data store, based on
thorough consideration of capacity, scalability, reliability, security, and
equivalent access.



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

The quality of service for a registry depends on global network coverage, which
is essential to maintaining the stability of .net and ensuring continuous
business operations. VeriSign has created a vast constellation of resolution
servers for .net that provides the fastest and most reliable service possible
with the highest degree of protection. VeriSign is the only registry operator
that has a proven infrastructure which can provide the stable and robust service
this critical TLD necessitates. Unlike TLDs hosted by other registry operators,
.net has not had a resolution failure in the seven years it has been under
VeriSign's stewardship.

Verisign Advantages:
+ Over 7 years of experience providing global network coverage without failure
+ Robust and diverse infrastructure with 14 sites strategically located to
support high demand and provide local redundancy
+ Time-proven tools and resources to monitor and quickly respond to
ever-changing Internet needs
+ Planned expansion already underway in support of growing and emerging markets

VeriSign has partnered with premier hosting providers in the United States,
Europe, and Asia to deliver fast, reliable DNS responses. Resolution sites are
carefully selected, then continually monitored and reevaluated against the
ever-changing Internet traffic requirements. This ensures that existing sites
are measured against regional demand and that new sites are added in the most
strategic locations available.

In the following section, we will explore the following facets of global DNS
service delivery for the .net TLD:
* Geographic Network Coverage. How DNS resolution network performance is
measured and how this impacts the selection of physical locations for .net name
servers
* Physically Diverse Sites. The evolution of VeriSign's network coverage,
detailing the 14 .net resolution server locations as they relate to network
topology and geographic traffic demands
* Support of Growing and Emerging Markets. VeriSign's future plans for
dramatically increasing the global .net footprint to meet the ever-changing
needs of growing and emerging markets


Geographic Network Coverage

Global DNS coverage is determined by the geographic distribution of name servers
with the capability for each site to provide adequate capacity. The reliability
and stability of any global TLD dictate that DNS responses are given quickly by
providing answers close to the point where a query is generated. The standard
measure for DNS performance is round trip time (RTT) measured from the time a
lookup is issued to the time at which a response is received. Current ICANN
guidelines call for DNS query RTTs of less than 300 milliseconds (as measured
from four root name server locations: US East Coast, US West Coast, Europe and
Asia). There are two major factors that affect RTTs for DNS lookups: latency and
number of network hops. Both of these factors can be managed by locating the
answer close to the point of question, from both a physical and network standpoint.

Verisign has continually sought to locate .net name servers in geographic
locations where demand is the highest. In selecting locations for the global
.net resolution footprint, VeriSign researched the prime geographic areas
through which Internet traffic is exchanged. The Internet backbone, according to
the Global Internet Geography Report issued annually by TeleGeography, Inc.
(Figures 5(b)vi-1 and 2), would logically necessitate name servers in the United
States, Europe, and Asia.

However, it is not enough to simply locate sites within these targeted
geographic areas; we must also consider the connectivity to the specific sites
relative to major Internet peering points. There is a direct relationship
between the number of hops and DNS performance for individual users. For this
reason, VeriSign carefully selects hosting partners for .net resolution sites
who provide premier facilities that offer only the closest connections to the
Internet's major backbone providers. VeriSign continually researches demand and
performance to evaluate the effectiveness of existing sites and to propose new
candidate locations for TLD resolution servers. The evolution of the specific
locations that Verisign has chosen for .net DNS service hosting is described below.

The .net global footprint by year's end in 2000 consisted of 11 name server
sites to support the resolution of DNS queries. Until this time, the .com, .net
and .org zones were hosted on the j-root name servers. Starting in early 2000,
VeriSign began a large-scale rollout, seeking to deploy dedicated name servers
for these critical TLDs at distributed sites around the globe. These 11 sites
were selected based on approximation to global peering points to minimize the
number of hops for the maximum number of users. Once deployed, these 11
locations (Figure 5(b)vi-3) collectively became known as our resolution
constellation.

As Internet traffic grew in Asia, Europe, and South America, it became evident
that additional sites were needed to support growing demand. Not only was DNS
traffic dramatically increasing as more Internet users came online, but also the
geographic dispersion of queries was widening. Through vigilant monitoring and
ongoing research, the global footprint of .net resolution servers has been
continually adjusted to meet changing demand. Four years later, the view of
geographic network support for .net looks considerably different (Figure 5(b)vi-4).


Physically Diverse Sites

Today, VeriSign provides diverse geographic coverage through 14 .net resolution
sites in eight countries, with five additional countries slated for deployment
in 2005. This evolution included the relocation of almost all the original sites
deployed in 2000, as well as additional deployments at three new locations, all
within the past four years.

Given the distribution of .net hosts and DNS query load, 60 percent of the .net
resolution sites are now located on the East and West Coasts of the United
States, and the remaining 40 percent are hosted in Europe and Asia. For maximum
coverage, growth allowance and physical redundancy, no less than three sites are
maintained in each targeted geographic area.

Hosting Site Selection

Network proximity to major peering points remains a primary factor in site
selection for resolution services. In addition, VeriSign applies several other
factors in determining the specific locations to host a resolution site. As
detailed in Section 5(b)i, Proposed Facilities and Systems, site selection of
each resolution location is an important consideration for the continued
security and functionality of the .net registry. VeriSign defines and evaluates
multiple criteria for the selection of each site, including:
* Connectivity through a minimum of two separate network providers
* Facility's environmental controls and redundancy
* Geopolitical stability and physical security
* Ability to recruit and retain skilled personnel

VeriSign has invested in both internal and third-party research to identify
prime targets for hosting DNS resolution service to ensure that .net resolution
servers are positioned in the most strategic locations to achieve the best
levels of service to the regions in which they are hosted. Each of the locations
in North America, Europe and Asia and strategy for site placement is further
explained in our more detailed response at www.verisign.com/nds.

Site Selection: A Case Study

While seemingly intuitive, it is not always a simple matter to determine the
ideal network location for a .net name server. For a TLD of this importance, it
is not enough to choose any well-connected site within a major metropolitan
area. Sites must be continually evaluated for performance to determine actual
usefulness to the geographic region in which they are located. For example, the
original .net installation in Hong Kong was one of only two sites located in all
of Asia. Daily monitoring and input from Internet users revealed round trip
times exceeding 300 milliseconds for queries originating in this region. Average
traffic was less than 60 percent of loads observed at other .net resolution
sites. This site was the worst performing and most underused .net DNS
installation. The daily snapshot shown in Table 5b(vi)-1 shows DNS traffic
growth from 2002, and is representative of normal traffic distribution across
the 13 .com and .net DNS sites, listed by highest traffic load to smallest.

Upon further investigation, VeriSign's Operations staff determined that although
this site was hosted within a premier Tier 1 data center; network connectivity
limitations resulted in increased latency for responses. In many cases, .net DNS
lookups originating in Hong Kong were resolved by servers in the United States
due to faster response times. Therefore, in 2003, this site was relocated to
Singapore, resulting in a significant improvement in both performance and load
dispersion among the Asian name servers, as shown in Table 5(b)vi-2. This is
just one example of the ongoing investment that is required to evaluate and
continually improve service for this critical domain.

Performance and Growth Evaluation

Without the proper tools, personnel and time investment, it is impossible for a
registry operator to assess the effectiveness of its geographic network coverage
or identify growth areas for better global service. VeriSign's goal is to
continually evaluate server locations for their usefulness to the regions that
they serve and to analyze traffic patterns to identify potential areas for
expansion or relocation. VeriSign has invested significant time and resources
into the development of programs to research, monitor, and forecast Internet
traffic trends. These efforts allow better insight into network trends, as well
as provide performance statistics and traffic flow data regarding the current
.net DNS constellation. Global DNS service performance and growth are evaluated
using several means:

* Engineers analyze data gathered by VeriSign's extensive monitoring platform to
identify growth trends indicated at existing resolution sites.
* Monitoring data is compared to maps generated by VeriSign Research
Laboratory's NetMapper IP traffic geolocation tool to drill in on the specific
origins of traffic (Figure 5(b)vi-5).
* Engineers confirm candidate locations using third-party analysis from CAIDA,
RIPE, and commercial research firms which track worldwide network capacity and
Internet growth trends.

Given the detailed statistics collected at the resolution sites (see Section
5(b)xvi), VeriSign Engineers are able to easily identify and analyze growth
patterns. Figure 5(b)vi-6 shows the actual growth rates in received traffic over
the past 2 years for each of the geographic regions in which VeriSign hosts .net
resolution servers.

Overall monitoring data reveals far greater growth in traffic at Asian and
European resolution sites than in the United States. This would indicate that
new sites are warranted in the geographic areas currently served by existing
servers in Asia and Europe. To identify these emerging markets, VeriSign
engineers must further investigate the origins of the traffic being received at
these sites.

The NetMapper project was developed with the goal of providing operators with a
view into the origins of DNS traffic, as shown by each of the .net name server
sites. NetMapper IP maps have served as a useful tool for tracking the
geographic origin of queries that are actually resolved at existing .net
resolution sites. Figures 5(b)vi-7 and 8 are representative of the Internet
backbone at two locations in the VeriSign network that identify particular
regions of increased activity.

The Atlanta .net name server installation (Figure 5(b)vi-9) shows significant
traffic from Brazil, Argentina, and Australia; the Singapore resolution site
(Figure 5(b)vi-10) shows increased traffic from India, China, and Australia.

These two maps are particularly interesting as they show queries from Australia
resolving at .net DNS sites as close as Singapore and as far away as the East
Coast of the United States. This is a prime example of a geographic area that
could be better served by a resolution site in-county, in theory decreasing
overall round trip times for these users. These and other NetMapper views have
helped VeriSign's engineers confirm general growth patters indicated on the
resolution constellation and identify target areas for expansion.


Support for Growing and Emerging Markets

As detailed above, VeriSign's efforts to support growing markets have resulted
in the relocation of multiple resolution sites to support the dramatic growth of
Internet traffic in Europe, Asia, and North and South America. In addition to
these sites, VeriSign has also identified five additional growing or emerging
markets which are targeted for further expansion:

* Australia
* Africa
* South/Central America
* Middle East/India
* Eastern and Central Europe.

Given these target markets, VeriSign engineers developed a scaled-down platform,
known as Regional Resolution Sites (RRS), which are sized to meet regional
demand and, therefore, are less expensive to deploy and operate. Regional
resolution sites will improve local connectivity in growing and emerging markets
and increase the visibility and granularity of Internet usage patterns. Other
benefits include:

* Better end user experience
* Improved protection against DDoS attack and other malicious attacks because of
added capacity and localization of attack traffic
* Faster DNS lookups for .com and .net.

While international connectivity and proximity to major peering points remain
considerations in the selection of new locations, these factors are often of
less importance for emerging markets. Some of the candidate locations are
remarkably lacking in significant network bandwidth; this is the very reason for
their consideration. Areas without easy access to major international peering
points are perhaps the most in need of regional service to improve response
times by decreasing the number of network hops and overall latency for DNS requests.

On the other hand, higher traffic growth areas, such as China and South America
warrant site location in the most well-connected points within the continent
given the large number of users in the region that will likely utilize the site.
A more detailed description of emerging market identification and key
considerations for each of the targeted expansion sites are detailed below.

Australia
Australia is a prime target for the deployment of a RRS in 2005. With average
traffic loads comparable to other major cities such as Beijing and Singapore,
Sydney perfectly fits the profile for the anycast solution. Sydney is also the
only major peering point within the continent (Figure 5(b)vi-11), so this is a
natural choice of location for the new installation. Site evaluation and
selection will begin in early 2005 with a deployment target of late 3Q 2005 or
early 4Q 2006.

Africa
The African continent has become an increasingly feasible expansion target, with
Internet bandwidth growth rates of 71 percent in 2003 and 41 percent in 2004.
Bandwidth costs are projected to continue decreasing with the growth of network
connectivity and increasing numbers of Internet providers. Candidate locations
include less connected parts of the continent, such as Kenya, where bandwidth

limitations cause high latency for DNS lookups to other parts of the world.

Perhaps the lowest demand area of all the proposed expansion sites, Africa is of
special interest because early site deployment will allow for historic traffic
growth monitoring for this region as Internet usage gradually increases.
Location evaluation is currently underway, with targeted deployment in mid-2005.

Central and South America
In 2002, VeriSign relocated a .net resolution site to Miami, FL, a major peering
point for Central and South America, to better serve Internet users in this
region and to track overall growth for these areas. Monitoring at this site has
shown a consistent increase in traffic, presumably the result of continued
growth of Internet usage in these regions. Increasingly better connected,
engineers have a variety of locations (Figure 5(b)vi-12) from which to choose
for site deployment.

Brazil, Chile, Peru and Argentina all offer possibilities, with Brazil leading
the candidate countries with the best connectivity and highest Internet usage
rates on the continent. Brazil actually ranks 10th on the list of countries with
the highest number of Internet users, just behind Canada and France. However,
Argentina is also a prime target for consideration given its high inter-regional
connectivity to Chile and Brazil. Location evaluation is currently underway, and
this deployment is slated to be an early expansion target for 2005.

Middle East/South Asia
The Middle East is perhaps the most rapidly emerging market with Internet usage
experiencing almost 230 percent growth since 2004, higher than any other
geographic region in the world. Connectivity is also increasing in these
regions. Telegeography's 2004 Global Internet Geography report specifically
calls out these regions, forecasting rapid Internet growth in the next year.
This report details major connectivity additions which are planned to be
completed in 2005, including several fiber installations connecting the Middle
East to South Asian sites such as India, Sri Lanka, Bangladesh, as well as to
Europe and East Asia.

Given both the current limited access to international peering points where .net
resolution servers are located, and the anticipated connectivity growth between
Middle Eastern countries and to/from outside regions, this typifies a "best of
both worlds" location for the deployment of an anycast server. Early deployment
will better serve this area with regional resolution to decrease round trip
times to sites further away. However, as connectivity and Internet usage
increases, this could grow to a high-traffic resolution site, providing service
to South Asian countries as well as Eastern and Central Eurpoe.

Eastern and Central Europe
Of the top 20 countries in Europe ranked for Internet usage, 6 are located in
Eastern and Central Europe, with two, Poland and Russia in the top 10. Verisign
engineers are seeking to both provide faster .net resolution to these and other
countries in this region and to redistribute load from the busiest resolution
sites in Western Europe. More research is needed into strategic location targets
which will begin in 2005.


Conclusion

VeriSign's global constellation is designed and managed with one thought in
mind; providing the highest quality service, rapid response times, and 100
percent availability. This is implemented through rigorous selection of remote
sites, constant re-evaluation of those sites, and taking into consideration not
only physical location but also network diversity. 

Market need and user demand drive site selection, resulting in a highly focused
network expansion plan for the coming decade. Many critical network services
rely on the VeriSign constellation. VeriSign has achieved flawless resolution
service by continually enhancing our geographic sites, layering redundancy and
increasing security. Finally, we remain firmly committed to continue the
expansion and improvement on this coverage to growing and 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.

The .net zone comprises information about more than 5 million second-level
domains, including nearly 13 million name server records and almost 200,000
address records. Many authoritative name servers, including those used by nearly
every TLD, have names ending in .net. More than 58 percent of all Internet hosts
rely on .net (source: "Net TLD Project: Measuring the Role of .net in the
Internet," Matthew Zook, Ph.D., ZookNIC Consulting, April 20, 2004.) Any
inaccuracy in, or unavailability of, .net zone information would have a
significant impact to the Internet community beyond just .net registrants.
Therefore, it is essential that the .net registry operator has the proven
ability to generate the .net zone file reliably, accurately, and securely. It is
also important to have the ability to generate .net zone file information in
near real-time. This capability satisfies the increasing expectations of .net
registrants, who want changes to their second-level domain information to be
visible in the Internet's DNS infrastructure more quickly than in the past.

VeriSign Advantage:
+ Commitment to, and investment in, highly accurate .net zone generation
processes and technologies, which result in reliable services for critical
Internet infrastructure

This section addresses:

* Zone file generation, including procedures for changes, editing by registrars,
and updates. Any changes to .net zone information result from create, delete, or
modification actions initiated by ICANN-accredited registrars, VeriSign customer
service representatives, or automated batch processes. Registrars do not edit
.net zone information directly, but change data through the SRS, or through the
web-based Registrar Tool.
* Frequency, security, process, interface, user authentication, logging, and
data backup. VeriSign updates the .net zone in near real-time with updates
generated approximately once every 15 seconds. These updates are visible in all
.net name servers within approximately 1 minute. The zone information is
generated on secure servers in a private network. Registrars use the SRS or the
web-based Registrar Tool to make changes to .net zone information. These
protocols use the SSL to provide a secure communications channel; registrars are
authenticated with a digital certificate, source IP address range and user name
and password. All applications that are part of the .net registry, including
zone generation, write extensive log files. Authoritative zone file information
is stored in an enterprise data storage system from EMC with mirrored Redundant
Array of Independent Disks (RAID) protection and offsite real-time replication.

VeriSign has demonstrated a proven record of success, having generated the .net
zone reliably, accurately and securely for 13 years. Recently, after a period of
thorough testing, we have begun updating .net zone information in near-real time
to increase the level of service to the Internet community.


Procedures for Changes, Editing by Registrars, and Updates

Any changes to .net zone information result from create, delete, or modification
actions initiated by ICANN-accredited registrars, VeriSign customer service
representatives, or automated batch processes.

Registrars do not edit .net zone information directly, but change data in the
SRS. More information about SRS protocols are available in Section 5(b)iv.
VeriSign also distributes the registrar tool to registrars, which provides an
easy graphical user interface (GUI) to perform common administrative tasks, such
as adding, modifying and deleting domain names and name servers.

In addition, authorized VeriSign customer service representatives make changes
in the SRS on behalf of, and with the consent of, registrars using web-based
customer service tools. Regularly scheduled automated batch processes also
change data in the SRS database. These batch processes implement published
business rules, such as automatic renewal of expired domains and the Redemption
Grace Period (RGP).


Update Process and Frequency

A description of VeriSign's .net zone file update process first requires some
background on ATLAS, the award-winning resolution platform that VeriSign developed.

VeriSign developed the ATLAS name server because no off-the-shelf solution could
be found to handle the unique requirements of the .com and .net TLDs. ATLAS's
economic scaling properties allow us to provision overwhelming capacity to
satisfy the extreme performance and reliability demands of these largest and
busiest of all TLDs. One of the ways ATLAS provides such high capacity is by
placing an in-memory relational database holding the .net zone information at
each resolution site. This in-memory database contains a subset of the core .net
registry database and allows DNS queries to be answered at tremendously high
rates. The standard zone file format defined in RFC 1034 is not well-suited to
the task of updating these in-memory databases at the resolution sites as data
changes in the SRS. Instead, ATLAS distributes the database using replication
files designed to support transactional database updates and several levels of
data integrity verification. These files are analogous to RFC 1034 zone files,
but have a different format and include database metadata.

The .net registry system still produces an RFC 1034-compatible zone file, which
is used by our BIND-based warm-standby backup DNS infrastructure and for
publication to participants in our TLD Zone File Access Program. Our BIND-based
backup system is described in Section 5(b)ii.

The remainder of this section describes how the .net registry system generates
both the ATLAS-specific zone information and RFC 1034-compatible zone files in a
reliable, accurate, and secure manner.

ATLAS

ATLAS updates .net zone data in a three-step process of extraction, validation,
and distribution. Figure 5(b)vii-1 shows the ATLAS architecture and the
extraction, validation, and distribution components.

Extraction. A process called extraction produces zone information for use by
ATLAS in two formats from the core .net registry database.

The first file format is called an Initial Send File (ISF), which is somewhat
analogous to a traditional RFC 1034-compatible zone file. An ISF contains
complete information about the .net zone. ISFs are produced twice per day at
12-hour intervals. An ATLAS name server only needs an ISF when the server
process is initially started up so it can load the .net zone contents into its
in-memory database. In this way, the ISF serves the same purpose as a
traditional zone file. After an ATLAS name server loads from an ISF, it receives
subsequent updates to .net zone information through the near real-time
incremental update feature.

This near real-time update feature uses a second zone information file format,
the Send File (SF). Each SF is simply a list of all changes (in the form of
additions, modifications, or deletions) to the .net zone since the previous SF
was generated.

The extraction process generates SFs continually as changes occur in core
registry database, resulting from RRP transactions and other activity. The
extraction process generates a new SF approximately every 15 seconds.

Validation. Before an ISF or SF is distributed to the ATLAS name servers at the
resolution sites, a rigorous validation process verifies the file as part of our
serious commitment to absolute data integrity. Both ISFs (containing complete
.net zone information) and SFs (containing a list of recent changes to .net zone
information) are subject to this same validation process.

This process runs on a validation server, which duplicates the operational
environment at the resolution site as closely as possible. A validation server
is essentially a captive name server with additional verification capabilities.
First, the validation process checks the file for syntax and other obvious
errors. Then, it loads the file and compares the contents of its in-memory
database with the core registry database to ensure that both match. If the two
match, then the information in the file was processed successfully and the file
can be safely sent to the ATLAS name servers at the resolution sites, and the
data contained in the file will be properly published. Any discrepancies
indicate a potential data integrity problem, so an alarm is triggered and human
intervention is required. The validation process verifies every record in every
file, both ISF and SF, in this manner. VeriSign has a patent pending on this
innovative data validation process.

Distribution. Once the file passes validation, it is distributed to the
resolution sites in a process described in more detail in the next section,
Section 5(b)viii, Zone File Distribution and Publication. The ATLAS name servers
at each resolution site process files as they arrive. ISFs are extracted,
validated, and processed twice per day; however, SFs are extracted, validated,
and processed in a continual stream as the core registry database changes. In
the case of an SF, the entire process of extracting a batch of changes,
validating them, and distributing them to all resolution sites takes about 1
minute on average.

RFC 1034-Compatible Zone Files

The .net registry system also produces an RFC 1034-compatible .net zone file
twice per day at 12-hour intervals. This file is used for mainly for two purposes.

* As described in Section 5(b)ii, VeriSign runs BIND name servers in a warm
standby mode as a backup to ATLAS at each resolution site. These BIND name
servers are always running with an up-to-date copy of the .net zone, which they
load twice per day from this RFC 1034-compatible zone file. In the event of a
critical ATLAS failure, these BIND name servers could begin answering queries
after a simple load balancer configuration change at each resolution site. While
ATLAS has been extremely stable in production, and we are quite confident in its
reliability, we use the BIND warm backup to be prudent and conservative. A
systemic failure of .net cannot be tolerated under any circumstances, and this
solution offers additional protection and peace of mind.

* RFC 1034-compatible zone data files for .net are also used for the TLD Zone
File Access Program, which allows access to the .com and .net zone files by
participants who sign an agreement governing the use of the files. More
information is available at
http://www.verisign.com/products-services/naming-and-directory-services/
naming-services/com-net-registry/page_001052.html


Security

The preceding zone file generation processes are automated using thoroughly
tested software on secure servers in a protected network. Zone file distribution
occurs over VPNs to each of our DNS resolution sites. Administrative access to
each component in the system is limited to authorized VeriSign administrators.
Each server is built using a locked-down operating system image from a standard
build and scanned for security vulnerabilities before being put into production.
Each server is further monitored and scanned periodically for security
vulnerabilities once in the production environment.

Section 5(b)xiii describes the security of VeriSign's .net registry systems in
much greater detail.


Interface

The interface to make changes to .net zone information provided to registrars is
through the SRS and access through the web-based Registrar Tool. There is no end
user interface per se to the zone generation process itself.


User Authentication

Registrar authentication for SRS access with the RRP API uses SSL certificate
authentication, source IP address authentication, and application-based
authentication with registrar user name and password. Registrar authentication
for changes with the registrar tool uses the registrar user name and password.

Each zone generation, validation, distribution, and publishing process uses
server and application authentication to ensure only authorized accounts are
used to update .net zone information. Each generation and validation process is
authenticated at the application level using server account information, and at
the database level using account information specific to the particular process.
Each distribution and publishing process is authenticated at the application
level using server account information. Each process is designed to provide
notification to the NOC if access is attempted by an unauthorized account.


Logging

VeriSign applications log .net zone file updates at each phase of the
registration process. In the registration process, activity from the RRP API,
and EPP API, and registrar tool is logged by the specific applications. Database
transaction logging occurs in the SRS and serves as the authoritative source for
all transaction information. Each zone generation and validation process is
logged by the application and error-checked using our distributed monitoring
system. Each zone file update, and any errors in the generation or validation
process, are included in the logs. The logs are periodically reviewed by system
administrators to make certain appropriate validation criteria are met.


Data Backup

Authoritative zone file information is kept in the .net SRS using an enterprise
data storage system from EMC with mirrored RAID protection and offsite real-time
replication. Generation of zone files is performed using a server connected to
the enterprise storage system. Each distribution and resolution server, in turn,
uses mirrored data storage to provide data protection in case of hard drive
failure. A compilation of recent zone file updates is kept on each distribution
server. The compilation provides for fast publishing times after server
maintenance. Backup processes and technologies are described in greater detail
in Section 5(b)x.


Conclusion

VeriSign currently delivers reliable .net zone file generation processes and
commits to continuing highly accurate .net zone generation processes and
technologies, resulting in reliable services for critical Internet infrastructure.



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

VeriSign delivers distribution, publication, and resolution services based on
technologies that promote data accuracy and that enable the rapid growth of the
.net gTLD. VeriSign provides .net domain name system (DNS) resolution services
from our constellation of DNS resolution sites. VeriSign follows mature and
rigorous procedures for distributing the .net DNS zone files.

VeriSign Advantage:
+ Distribution, publication, and resolution services, based on technologies that
promote data accuracy and that enable the rapid growth of the .net gTLD

This section describes zone file distribution and publication processes, including:

* Locations of Name Servers. VeriSign serves .net from 14 resolution sites
located in the United States, Europe, and Asia. We also use three warm standby
sites for maintenance and emergency capacity.
* Procedures for and Means of Distributing Zone Files. Zone files are validated
and then distributed over a secure virtual private network. The end-to-end
publication time is within 3 minutes 95 percent of the time.

The .net operator must have the proven ability to quickly and accurately
distribute .net zone information to a set of name servers distributed around the
world. Our customers demanded rapid update of .net zone information: registrants
wanted the domain name changes they made at registrars to be reflected quickly
in DNS. VeriSign responded with ATLAS and its rapid update feature. With other
registries, it can take 5 minutes or even an entire day for changes to appear in
DNS. But VeriSign guarantees changes made to the SRS will appear in DNS within 3
minutes 95 percent of the time.


Locations of Name Servers

VeriSign provides .net DNS resolution services from our constellation of 14 DNS
resolution sites, which are located throughout the world, as shown in Figure
5(b)viii-1. We select resolution sites based on a rigorous process involving
multiple factors, as detailed in Section 5(b)vi, Geographic Network Coverage.
Site locations are adjusted over time as conditions, such as Internet traffic
patterns change.

Each site has multiple load-balanced systems running ATLAS, our proprietary
high-performance name server. ATLAS is fully compliant with all relevant DNS
RFCs, including RFCs 1034 and 1035 which are the core of the DNS specification.

Each site is managed remotely over secure VPNs and monitored around the clock.
Each site is based on a redundant server architecture and uses a complete set of
redundant hardware components and supporting network infrastructure to eliminate
single points of failure. For example, each site has a minimum of 2 gigabit
Ethernet connections and is served by at least two separate Tier 1 network
providers. The diversity of network providers is important so connectivity
issues for a single provider do not interrupt services. Resolution site
architecture is discussed further in Section 5(b)ii, Stability of Resolution and
Performance Capabilities. Each resolution site around the globe must adhere to
strict facility standards established by VeriSign.

Standby Sites

In addition to the 14 main resolution sites, VeriSign uses three warm standby
sites. The standby sites have identical configurations to the main resolution
sites, including all the redundant system and network components, along with
similar Internet connectivity and bandwidth. These sites are used primarily for
maintenance, but can also be activated to provide emergency resolution capacity,
such as in the event of a DDoS attack. For security purposes, we do not publish
the locations of these sites.

To perform extensive maintenance on a given main resolution site, we redirect
all the services provided by the main site to one of the standby sites. The
standby site concept is possible because each of the 14 main resolution sites
uses provider independent IP address space and VeriSign controls the
announcement of this address space, using the BGP routing protocol. To activate
a standby site, we first configure the site's equipment with the same IP
addresses, as the main resolution site it will stand in for, effectively
"cloning" the main site. After verifying that all systems at the standby site
are ready to handle service, we withdraw the BGP route announcement at the main
site and announce the same address space from the standby site. The effect is
that all traffic moves from the main site to the standby site with only a brief
outage for that particular site as the Internet routing information changes. We
can then perform the necessary maintenance at the main site without worry.
During this time, individual name servers and resolvers throughout the Internet
continue to use the site's services, unaware that they are accessing the standby
site instead of the main site. This process is reversed to restore service to
the main site.

Our hot standby sites have been a significant factor in allowing us to maintain
our unparalleled track record of 100 percent uptime for .net resolution services
for the past 7 years.

Expansion Using Anycast

VeriSign plans to increase the Internet footprint of .net DNS resolution
services by using a technique called anycast. Anycast allows a service to be
replicated in multiple locations using Internet routing. Anycast works by
configuring multiple instances of a service in different locations, but each
with the same service IP address. Each instance announces its availability using
the BGP routing protocol. The global Internet routing table shows multiple ways
to reach the service at this IP address, just as when an organization's network
is connected to the Internet via multiple providers and announces the same
address space to each provider. In both cases, Internet routing chooses the best
route from a given client to the destination server. With a multihomed network,
the client always reaches the same destination. In the case of anycast, the
client reaches the topologically closest anycast instance, as determined by BGP.
But it doesn't matter which instance a client reaches, because all are
configured with the same IP address and provide the same service.

Anycast is now a proven method for increasing the number of name servers for a
given DNS zone. Many of the operators of Internet root name servers now use
anycast to expand the number and geographic scope of their name servers.
VeriSign, one of the original root name server operators, uses anycast to expand
the j-root server to 15 geographically distributed locations throughout the world.

VeriSign has also used anycast to expand the number of .net (and .com)
resolution sites beyond the traditional DNS protocol-imposed limit of 13. In
July 2004, a site in Seoul, Korea, became the 14th site in our global resolution
constellation as an anycast instance of b.gtld-servers .net: services for
b.gtld-servers .net are now offered from both Sunnyvale, California and Seoul,
Korea.

We plan to add an additional five .net resolution sites over the next year in
emerging markets. Section 5(b)vi, Geographic Network Coverage, describes our
expansion plans in more detail.


Procedures for and Means of Zone File Distribution

Section 5b(vii), describes how VeriSign generates .net zone information in two
file formats: traditional RFC 1034-compatible format and an internal format
suitable for ATLAS' database replication needs. Zone information in both file
formats is distributed to all the resolution sites. Throughout the rest of this
section, the term "zone file" refers to files in both formats.

VeriSign follows mature and rigorous procedures for distributing the .net DNS
zone files. After generation, each zone file is validated against the .net SRS
database. Any validation error will stop the distribution process and prevent
erroneous information from being published on the Internet. After validation,
zone files are ready for distribution to the resolution sites.

We do not use the standard DNS zone transfer protocol, which is not well suited
to a large zone such as .net. The zone transfer protocol is wasteful of
bandwidth because it does not allow incremental changes; the entire zone file
must be sent each time the zone is transferred. The standard zone transfer
protocol is also based on TCP, which does not perform well in difficult
conditions of high network latency (delay) and packet loss.

Instead, VeriSign developed our own zone file distribution mechanism. This
mechanism supports incremental transfer of large zone files, eliminating the
need to send the entire file. We also developed our own UDP-based file transfer
protocol that is designed to perform well, even in the face of the difficult
network conditions. Our zone file distribution mechanism copes well with less
than ideal network conditions. In practice, this protocol works extremely well
in distributing .net zone information quickly and efficiently to all resolution
sites.

The zone files are distributed via secure VPN to each resolution site. Every
zone file is generated with a cryptographic checksum that is verified every time
the file is transferred. After this checksum is verified at the resolution site,
the file is loaded by the name server.

Each point of the distribution and publication process is monitored by two
separate monitoring systems. The VeriSign distributed monitoring system checks
for server health and application health. VeriSign's custom DNS monitoring also
monitors the status of a generated zone file and its serial number along each
point in the distribution process. The serial number, assigned at the time of
file generation and based on the time of day, provides an effective method to
identify and track each zone file as it is being distributed and published.
VeriSign's extensive monitoring systems are described further in Section
5(b)xvi, System Outage Prevention.

Zone File Publication with ATLAS

ATLAS provides advanced publication features that contribute to high-performance
resolution of .net DNS queries. ATLAS uses an innovative in-memory database that:

* Allows ATLAS to perform the .net DNS resolution services and to simultaneously
receive the .net zone file data feed from the central distribution servers. Zone
changes are incorporated at the resolution site, while queries continue to be
answered.
* Offers advantages over commercial database products, such as Oracle. Since all
zone data is stored in memory, queries for even less popular .net domain names
and name servers are answered quickly. Name servers, based on commercial
database products, result in longer query response times caused by slower access
to zone data, which must be retrieved from disk.

ATLAS uses advanced techniques for scrubbing the data sets in memory and
comparing every instance across all sites to catch data anomalies before a bad
response can be returned. In the case of DNS resolution for TLDs, a single
record error for a domain can cause widespread disruption of services on a scale
unthinkable for most industries dependent on the Internet.

As a result of these features of VeriSign's award-winning ATLAS architecture,
query response times measured internally consistently average less than 5
milliseconds.

Conclusion

VeriSign distributes and publishes .net zone information quickly and accurately.
Registration changes are guaranteed to be reflected in DNS within 3 minutes 95
percent of the time, and in practice, changes appear in less than 1 minute. Both
our guarantee and our ongoing performance are the fastest in the industry. In
addition to supporting these rapid updates, our proprietary ATLAS platform
includes other features critical to a TLD of .net's importance, such as
comprehensive data validation and efficient and reliable zone file distribution.



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

VeriSign provides registrars 24x7x365 access to the registry billing and
collection system with functionality that is fully integrated with the SRS.
VeriSign uses multi-tiered system security and conducts a variety of periodic
third-party audits of our systems and networks.

VeriSign Advantage:
+ ICANN-accredited registrars benefit from VeriSign's experience in providing
advanced billing functionality, including online maintenance of account
information, improved invoice format and content, and reporting.

This section outlines VeriSign's billing and collection systems, including:

* Technical Characteristics. VeriSign's billing and collection system
functionality is fully integrated with the SRS.
* System Security. VeriSign uses multi-tiered system security and conducts a
variety of periodic third-party audits of our systems and networks to maintain
secure billing and collection systems.
* Accessibility. VeriSign provides registrars 24x7x365 access to the registry
billing and collection systems through the Registrar Tool with extensive
detailed and summary reporting.


Technical Characteristics

System security, accessibility, auditability, and reliability are the
cornerstones of the VeriSign Registrar Billing and Collection System (RBACS).
ICANN-accredited registrars benefit from the ability to operate and manage their
businesses based on the functionality of this advanced Oracle-based system. This
system is fully integrated with the VeriSign SRS and has been tailored during
years of service to the needs of registrar business operations.

The RBACS is comprised of three main components, as depicted in Figure 5(b)ix-1.
First, the main financial and invoicing component consists of Oracle Financials
(Oracle 11i) and is responsible for debiting and crediting registrar accounts
and for generating monthly invoices. The web-based Registrar Tool provides
registrars with 24-hour access to their SRS account information, the ability to
modify certain account parameters, and the ability to set permissions. Finally,
the reporting engine delivers a variety of accounting and operational reports
that registrars use for financial reconciliation and business operations.

While registrars have 24-hour self-service access to their SRS account
information through the web-based Registrar Tool, registrars can also access
additional assistance 24x7x365 by contacting the VeriSign Customer Service Desk
(CSD). VeriSign personnel can provide help to registrars not only through the
direct use of the Registrar Tool but also through a variety of support systems,
including the VeriSign Customer Service Representative (CSR) Tool and Clarify
Issue Tracking System to provide responsive and reliable customer service.

Finally, VeriSign is committed to frequent improvement to the RBACS through the
introduction of additional functionality and more advanced tools to assist
registrars in managing their businesses. Consolidated invoicing and additional
reporting are examples of recent improvements, and, with the deployment of our
EPP implementation described in Section 5(b)iv, VeriSign will introduce the
VeriSign Registrar Console that will serve as the platform for registrars to
access EPP-enabled registry functionality and will replace the existing
Registrar Tool.

Registrar Financial Requirements: VeriSign establishes registrar financial
requirements during the new registrar setup process. Within 24 hours of the
receipt of a registrar accreditation notice from ICANN, VeriSign sends the new
registrar a Welcome Package that includes the Registrar Credit Application and
the Registrar Data Information Sheet, which captures billing contact information
and can optionally be completed on the VeriSign website.

Once VeriSign receives both the Registrar Credit Application and the Registrar
Data Information Sheet, VeriSign creates an account for the registrar in the
RBACS. This process also allows each registrar to provide a payment security in
the amount identified on the Registrar Credit Application and required in the
Registry-Registrar Agreement. Registrars have three options available to satisfy
the payment security:

* Deposit Account (funded via check or wire)
* Irrevocable Letter of Credit
* Payment Security Bond

Once secured, the payment security amount establishes the registrar's credit
limit within the SRS. Registration volumes during the monthly billing cycle may
not exceed the registrar's credit limit. To assist registrars in monitoring
their available credit balance, the RBACS generates and transmits low balance
notices similar in form and content to the sample provided in Figure 5(b)ix-2
when remaining credit balances fall below the registrar-configurable threshold.

Batch processes will continue to automatically send the registrar low balance
notifications six times daily until the registrar sends VeriSign funds to bring
its available credit to an amount above the registrar established threshold. If
a registrar's available credit reaches zero dollars, the registrar will no
longer be able to perform billable transactions within the SRS.

Registrars can apply for emergency credit from VeriSign 24x7x365 to allow them
to continue to conduct billable transactions within the SRS. Our process for
granting registrars emergency credit is well-established and strictly followed
to treat all registrars in an equivalent manner.


System Security

Registrars access the SRS through the Registrar Tool or through an API to
perform registration activities. All billable transactions performed by
registrars in the SRS are passed to the RBACS via an API in near real-time. Each
SRS session is authenticated and encrypted using two-way SSL protocol. In
addition to SSL protection, all registrars are contractually obligated to
authenticate every client connection with the SRS using both an X.509 server
certificate and its password. All registrar self-service functions are performed
via the Registrar Tool, which also requires registrar specific user IDs and
passwords. Each individual registrar is responsible to safeguard his user name
and password and to notify VeriSign within 4 hours of learning that its password
has been compromised in any way, or if its server certificate has been revoked
or compromised in any way.

VeriSign undergoes a variety of periodic audits of our systems and networks,
including the RBACS. Penetration tests are performed by an outside company and
include numerous tests for exploits, versions, and patch levels. Various groups,
such as Klynveld Peat Marwick Goerdeler (KPMG), regularly perform Statement on
Auditing Standards (SAS) 70 and British Standard (BS) 7799 audits to validate
the effectiveness of the security measures that VeriSign uses. Detailed
information on security audits is available in Section 5(b)xiii.


System Accessibility

VeriSign provides registrars full-time access to the RBACS through the Registrar
Tool. In addition, the RBACS delivers reports and invoices on the schedule
described below, and customer service support is available to all registrars.
Access to customer support as well as reports, the Registrar Tool, and invoice
information is granted to all registrars on an equivalent basis. Finally,
VeriSign monitoring systems, operations personnel, and outage prevention
procedures, all detailed in Section 5(b)xvi, cover RBACS to promote efficient
and reliable registrar operations.

System Auditability

Registrars require easy-to-use tools and reports to assist them in managing
their business. The VeriSign RBACS meets this need by providing daily, weekly,
and monthly reports that are available to registrars via a secured file transfer
protocol (FTP) server. To assist registrars in their ability to monitor their
registration activity throughout the month, VeriSign generates daily and weekly
reports for each of our registrars, as listed in Table 5(b)ix-1.

Registrars are able to use these reports to monitor their registration
activities and to reconcile their activity to the monthly billing reports. These
reports are published on the first day of each month and provide registrars with
a means to reconcile their monthly invoices to their transaction activities,
listed below:

* Registrations (including deletions within the grace period)
* Transfers (including deletions within the grace period)
* Auto-renewals (including deletions within the grace period)
* Explicit Renewals (including deletions within the grace period)
* Restores
* Syncs
* Non-Refund Deletions

The monthly reports include the transactions for the previous month as well as
the grace period deletes for the previous month. The grace period deletions are
flagged with a deletion date. The domains that are deleted outside the grace
period will continue to be listed on separate reports. These "non-refund"
reports include all deletions from the previous month that occurred outside the
grace period, whether or not they were added, renewed, auto-renewed, or
transferred during that month or during a prior month.

The reports reflect the actual activity for the period that affected the
registrar deposit account. The registrars receive one monthly invoice reflecting
the counts for all billable activity for the month and the detail behind the
summary counts on the invoice are provided in the detail reports identified
above. The system associates a transaction ID with every transaction that occurs
in the system. These transaction IDs provide an audit trail of all financial
transactions allowing registrars, as well as VeriSign personnel, to easily trace
activity during the audit process. Figures 5(b)ix-3 and 4 provide a sample of
the new invoice format that VeriSign recently made available to registrars.

System Reliability

As with the SRS, the Oracle 11i billing system reliability and availability are
paramount to VeriSign's ability to provide registrars with an accurate view of
their financial status with the registry. The financial systems that support the
registry have had online availability of 99 percent over the past 2 years.
Typically, errors are identified within 4 hours of occurring and corrected
within 4 hours of identification. We expect the Oracle 11i availability to
increase to 99.9 percent when an infrastructure upgrade is completed in January
2005.


Conclusion

VeriSign operates a highly secure and reliable billing and collections system
that includes a web-based Registrar Tool, allowing registrars to add users, set
permissions, view credit limit/account balance information, look up credit
transaction history, and set low balance percent threshold. This self-service
allows registrars to quickly make changes and access information necessary to
operate efficiently and effectively. Our comprehensive daily and weekly activity
reports provide registrars a variety of operating metrics for use in financial
and operational planning. Registrars receive clear and concise invoices on the
first business day of each month that include all products to make
reconciliation and processing fast and easy. Finally, registrars have immediate
access to monthly transaction reports to aid invoice reconciliation. VeriSign's
comprehensive solution to billing and collections is reliable and customer focused.



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

VeriSign has developed a comprehensive backup and escrow system to protect the
data of the .net registry. Backups that pertain to procedures, techniques, or
hardware are used to help recover lost or destroyed data, or to keep systems
operating. These are essential items to ensure continuity of service for a
stable and reliable system.

VeriSign Advantages:
+ Protection of registry data is maximized by a layered architecture supported
by robust data backup procedures.
+ Operational five-tiered architecture to ensure critical data backup reliability.

This section describes VeriSign's approach to data backup and the procedures
necessary for recovery.
* Frequency. VeriSign's SRS system has a tiered backup architecture
incorporating real-time backup of data to multiple disks, full database
snapshots made several times a day, and full backups to tape every day.
* Procedures. Data from the mirrored disks are backed up to snapshots, which are
then used to create daily tape backups. Additionally, the data is mirrored in
real-time across a fiber link to a fully redundant alternate primary site, and
separate database transaction logs are compiled and downloaded to our escrow
agent on a daily basis.
* Hardware and Systems Used. Our SRS data backup and recovery system is composed
of a primary site with a secondary backup site. Each site uses a combination of
multiple EMC Symmetrix storage frames for live and snapshot databases and IBM
3584 high-speed tape libraries.
* Data Format. The SRS data is stored in used the native Oracle 9i data format
under compression.
* Escrow Agents. Our escrow agent is Iron Mountain Intellectual Property
Management, and our long-term data storage facility is operated by Iron Mountain.
* Retrieval of Data/Rebuild of Database. VeriSign's recovery procedures are
choreographed around our five-tier backup architecture. Depending on the nature
of the failure, recovery can be performed in a matter of minutes with our
redundant EMC Symmetrix storage frames or within 48 hours from tape in the
worst-case scenario.

Because of the importance of the .net registry to the stable operation of the
entire Internet, our backup procedures are critical to our ability to safely and
confidently operate the registry. VeriSign's five-tiered structure using
industry-leading storage hardware and software for protecting critical data
provides the following:
* Maximum protection against the corruption of critical data
* Maximum confidence in the ability to never drop or lose a single real-time
transaction, which is especially important in an SRS environment that is
processing 300,000 real-time transactions every minute
* Ability to quickly restore data


Frequency and Procedures for Backup of Data

The VeriSign five-tiered hardware and software structure, shown in Figure
5(b)x-1, is focused on the maximum protection of the primary .net registry
database. This database is the most important element of any registry
provisioning function.

Tier 1. Enterprise Symmetrix Remote Data Facility (SRDF) replication technology
ensures integrity of data replication across database storages and provides high
performance replication. Each disk drive in the EMC Symmetrix storage frame is
fully mirrored, with significant automated checking for physical corruption and
failover. Additionally, VeriSign creates periodic business continuance volumes
(BCVs), or snapshots, from the primary database. These BCVs provide the ability
to quickly restore the primary database in the event of an emergency. This also
allows us the ability to perform various administrative batch activities (e.g.,
reports and backups) without affecting the performance of the primary OLTP
database. This architecture is critically important to maintaining SLAs in an
environment with high transaction volumes and significant transaction peaks.

Tier 2. VeriSign uses the BCVs created in Tier 1 to generate tape backups from
the OLTP database. These tapes are stored in a tape library at the primary data
center facility. VeriSign uses enterprise tape storage software to store data
onto tape libraries. Copies of these tapes are created daily and stored at a
short-term offsite tape storage facility. These tapes are accessible within 10
minutes to operations personnel. The data on these tapes includes database
transaction logs, which can be used to recreate transaction history in the case
of recovery and contribute to overall data integrity.

Tier 3. Each real-time operation against the primary OLTP database is
synchronized to the primary EMC Symmetrix enterprise storage frame, which then
is synchronized to a secondary Symmetrix enterprise storage frame at the
secondary site using SRDF technology. This synchronization ensures that all OLTP
database transactions are replicated in real-time to a secondary database at a
different location and facilitates the rapid recovery if needed.

Tier 4. Daily full backup tapes are transported weekly from the short-term
offsite tape storage facility to a secure long-term offsite tape storage
facility operated by a third-party storage vendor. These tapes are retrievable
in a few hours at the request of specifically named and authorized individuals.

Tier 5. OLTP critical transaction logs are compiled and packaged for daily
download by the escrow vendor. The data is available in the event that registry
services are lost, and the data is needed to recreate registration information.


Hardware and Systems Used

Detailed backup procedures developed specifically for registry operations
through years of operations experience, and supported by state-of-the-art
hardware and software, help deliver reliable and efficient data processing,
storage, and retrieval. VeriSign uses hardware and backup systems from leading
vendors, including EMC and IBM. These proven systems enable us to confidently
support our assertion that we do not lose registry data.

Hardware. VeriSign uses EMC Symmetrix storage systems to back up the online .net
registration database. In the backup processes associated with Tier 3, the data
resides on mirrored storage at the primary site with fully synchronized data at
the alternate primary mirrored storage site. A full copy of the database is
taken each day and backed up on tape using the IBM 3584 tape library with an
expansion frame and a minimum of 16 tape drives and 721 available tape slots.
This solution is capable of physically storing up to 144 Terabytes (TB) of data
in the library. This tape media has a storage life of up to 30 years. The tape
drives are each capable of data transfer rates of 35 Megabytes per second (MB/sec)

With the 16 drives, the backup solution can currently back up 2 TB per hour, 48
TB per day. At the current size of the .net database, 400 full tape backups of
live data, or 133 full backups of archived .net data, could be performed per
day. Although VeriSign is capable of such numbers, it is unlikely since EMC BCV
technology is used.

The BCV allows us to take a point-in-time snapshot of the .net database within
minutes and mount it to a server anywhere on the network where backups, database
restores, or reporting functions are performed. IBM P-Series servers are
deployed to provide the tape storage capabilities for the Veritas NetBackup
software. Each site has a master server and multiple media servers that connect
to the tape library via a storage area network. This allows for securely
directing data from each separate network environment to tape without the
concern of competing backup jobs limiting bandwidth or drive usage.

Disaster Recovery. In addition to primary backup solution, VeriSign has a
disaster recovery solution that uses the same architecture and implementation.
Any tape that is written at the primary site can be recovered from the offsite
facility and recovered at either site in case of emergency.

As a failsafe there are redundant 2 Gigabit (Gb) fiber circuits between the
primary and alternate primary sites that can be used to back up .net data in a
matter of minutes. If the entire primary facility were lost, the disaster
recovery backup solution can perform backups of the .net disaster recovery
systems immediately (once databases are recovered). This solution is always
online and operational. The primary and alternate primary sites are listed in
Tables 5(b)x-1. The software specifications are listed in Table 5(b)x-2.

Software and Systems Solutions. VeriSign uses leading software and systems
solutions with proven technology to provide a robust software backup solution
for the .net gTLD. We use the Oracle relational database for the .net
registration system, which is deployed on a pair of database servers clustered
using IBM High-Availability, Cluster Management Protocol (HACMP) software. This
software provides protection against database server or network failure. The
database servers are connected to an EMC Symmetrix storage array. The database
uses EMC TimeFinder software to provide mirrored storage protection on the EMC
Symmetrix storage arrays. In addition, EMC SRDF provides further protection
against site failures by replicating data in real-time to the secondary
registration site.

A snapshot of the database is backed up to tape daily using Veritas NetBackup
software, which is used for application and database backups onto an IBM tape
library. The NetBackup software consists of two main packages:
* Media Server
* Master Server

Media Server. The Media server maintains information about the storage devices
and individual tapes. It is responsible for managing information related to:
* Location of stored data
* Data contents of each volume (tapes, disks, etc.)
* Condition of the volumes (how old, etc.)

Media server functions cover four main areas:
* Media Management: the tape location, age, and index of data stored on each tape.
* Device Management: the drives available for backup.
* Robot Management: tape inventory in the tape library. 
* Maintenance Management: tape drive cleaning. 

Finally, the media server groups tapes in two ways to accomplish the tape
management role:
* Volume Pools. Each tape belongs to a volume pool that determines what the tape
will be used for such as incremental or full backups
* Volume Groups. Tapes also belong to a volume group that determines where a
tape is located, such as in a robot or offsite

Master Server. The NetBackup master server software uses the services provided
by the media server to provide the following backup, archive, and restore functions:
* Unattended full and incremental backups
* Administrator initiated manual backups
* User directed backups/restores
* Scheduling and reporting

Tape backups are generated from the primary .net database and system
configurations and are stored in a tape library at the primary data center
facility. Each day, copies of these tapes are created and stored at a short-term
offsite tape storage facility. These tapes are accessible within 10 minutes to
operations personnel. Daily full backup tapes are transported each week from the
short-term offsite tape storage facility to a secure long-term offsite tape
storage facility operated by Iron Mountain, the leading media storage facility
in the United States.

These tapes are retrievable in hours at the request of specifically named and
authorized individuals. Backup retention is conducted in accordance with
agreements between VeriSign and ICANN.

Veritas NetBackup performs scheduled cleaning of tape drives, testing of media,
and tracking of media usage to ensure quality tape backups. Tapes are purchased
in bulk and refreshed near the end of the tape life-cycle. Media destruction is
performed by Iron Mountain.

VeriSign uses several methods to promote successful backups. Veritas NetBackup
provides a GUI interface for visual inspection of backup processes. Veritas also
provides a command-line interface that offers the ability to script backup
commands and poll results. VeriSign uses this command line interface to automate
backups in processes, such as the database snapshot. The results of a backup are
then distributed through email and monitors.

Frequency and procedures for data backup. Full backups of the .net database and
database archives are performed daily. The full backup is a point-in-time
snapshot of the live database. A full backup can be used to restore the database
to the exact condition it was in at the time of the snapshot. The full archive
backup is a collection of all critical database archives. Therefore, VeriSign
can extract historical .net reports, such as the number of domains registered
one year ago, compared to current registered domains.

The backup, which is automatically initiated through the use of a script,
performs the following functions:
1) Creates a snapshot (mirror) image of the live .net database
2) Makes multiple copies of the database, which are then mounted on reporting
and backup servers
3) Initiates the tape backup and remains mounted (in case it is needed for
restoration purposes) until the following day
4) Dismounts the copies and restarts the snapshot process.
Once the full backup has been completed, a flag is sent to the database server,
which begins the data archival process and a script upon successful completion.
At this time, the tape is ejected and sends out a notification from the tape
library, and is placed in a fireproof safe located in another building. Once
every week, Iron Mountain picks up the tapes for storage at its
climate-controlled facility.


Data Format

Data kept on tape storage remains in a native binary format compressed to
improve the volume of storage on each data tape.


Identity of Suggested Escrow Agents

VeriSign currently provides escrowed data of the .net registry database through
Iron Mountain. The registry data is packaged, compressed, encrypted, and
deposited to the escrow agent via secure file transfer. VeriSign performs the
compilation, processing, and packaging of .net TLD data required for escrow.

VeriSign provides this in an electronic format. Under this arrangement, the .net
gTLD database transaction logs are electronically delivered in a secure mode on
a weekly basis to the escrow agent, as well as incremental updates on a daily
basis. The data escrow agent receives the data, conducts verification testing
for completeness and integrity, and stores the data onto DVD. This process
ensures that current registration data is always available. The terms of the
escrow agreement also specify the conditions under which the data will be released.


Retrieval of Data/Rebuild of Database

If a situation occurs that requires data recovery, the severity of the event
determines the specific procedures that VeriSign executes. In the event of a
failure of the primary EMC Symmetrix data storage device, the database would be
recovered from a secondary EMC Symmetrix data storage device at the alternate
primary data center. This second device is maintained up-to-date with real data
mirroring from the primary OLTP database. Therefore, the recovery time is
minimal and the confidence in data integrity is high. Should the primary data
center be rendered completely offline, registration functions would be recovered
at the secondary data center as well. A dedicated EMC Symmetrix data storage
device has been kept up-to-date in real-time, promoting a speedy and reliable
recovery.

With all this data protection, redundancy, and reliability in place, it is
difficult to envision a scenario in which data recovery from tape would be
necessary. However, this contingency has been planned for as well. There are
three EMC Symmetrix frames located in various data center facilities that could
be used to restore data in the event of an emergency. In a worst-case scenario,
where all online copies of the .net registration database are completely
destroyed and the primary data center facility is offline, full recovery of .net
registration functions could be accomplished in less than 48 hours at one of
VeriSign's other facilities. DNS functions, the most critical functions for the
stability of the Internet, would not be impacted. A description of backup
procedures for shared systems, development, operational test and evaluation
environment and corporate services is available at www.verisign.com/nds.

Systemwide Backups. This default type of backup captures all locally mounted
file systems on a given computer system. These are backups can be used in
recovering system configuration and application files needed in case of complete
system failure. This data is kept short-term and does not include critical data,
such as financial records.

Individual Backups (Non-Systemwide). These backups are specifically designed to
capture only the files necessary to recover critical data that is kept
long-term. An example of this would be the backup of the registry database. This
type of backup reduces the number of tape media required, which makes cost and
recovery/search speed much less than a systemwide type backup.

Backup Personnel. VeriSign backup personnel have unique insight in that they
have participated in the architectural, engineering, and operational aspects
that went into the planning, provisioning, and deployment of the backup
solution. These employees have also attended numerous third-party training
courses on the hardware and software components that make up this solution.
These third parties include Iron Mountain, Veritas, and EMC. Training is kept
up-to-date with the latest software versions to come from each vendor. Backup
and recovery methods are continually tested by VeriSign to ensure timely and
accurate recovery in disaster recovery scenarios.


Conclusion

Backups provide the last line of defense against data loss. VeriSign considers
backup processes and procedures a critical facet of our solution and uses
hardened methods to verify that back-ups are made in an accessible and
retrievable format. Some of the primary features and benefits include:
* EMC Symmetrix storage of live database which provides real-time backup of data
to facilitate data retrieval.
* EMC SRDF, which provides rapid recovery of data to minimize operational
downtime and maintain high levels of availability.
* EMC BCV, which reduces stress on the OLTP database and supports data recovery
by providing snapshot of database for backups and batch processes
* Our tape libraries, offsite storage, and relationship with our world-class
escrow provider ensure fast, secure recoverability.



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

An escrow agreement between the registry operator, the escrow service provider,
and ICANN is essential to ensure business continuity and stability of the .net
TLD. In a single week, the average number of modifications to .net registration
data includes nearly 200,000 transactions, including new domain names, deleted
domain names, and modifications of name server IP addresses and transfers
between registrars. The registry operator must have an escrow arrangement in
place with ICANN and a reputable escrow agent. VeriSign has an existing data
escrow service for the .net TLD. This agreement will continue into a new .net
agreement without interruption, thereby never creating a window without escrow data.

VeriSign Advantages:
+ A tested, end-to-end solution for data escrow and recovery
+ Comprehensive insurance arrangements

This section presents VeriSign's comprehensive escrow solution. We define our
solutions for:
* Arrangements for Data Escrow. VeriSign has a long-standing contract with Iron
Mountain Intellectual Property Management for data escrow services.
* Data Formats. VeriSign completes daily and weekly deposit of reports and
meta-data for all ASCII and non-ASCII domain name registrations. These are
tested for accuracy to avoid failure to restore due to data corruption.
* Insurance Arrangements. This contains a description of the property, business
interruption, and general liability insurance that VeriSign maintains.
* Backup Plans for Data Recovery. The process that VeriSign would undertake to
retrieve and restore escrowed data is regularly tested and refined to ensure
execution of the plan.

Failure to have all escrow arrangements in place, even for a short time, could
result in a significant data loss. The risk of a registry failure by a new
operator during a transition period is significant and should warrant
verification that a fully verified escrow process is in place before any
transition of a critical registry, such as .net.

VeriSign tests all backups to ensure the data formats are accurate and the files
are not corrupted. We have a verified, proven record of delivering completeness,
correctness, and integrity of the data within each escrow file.

Organizations with Internet services built on .net domains rely on the
continuity of their domain registrations. Escrow provides ICANN, .net
registrars, and registrants with a high level of confidence in the continuity of
the registration information managed by the registry operator.

In the event of a catastrophic registry loss or termination of the Registry
Agreement, failure to have a verifiable escrow arrangement, or a failure in
retrieving data from escrow could cause irreparable damage. With more than
25,000 changes to registration data in the .net registry database every day,
reconstructing the .net TLD would be extremely difficult, if not impossible,
without current data. This would certainly not be possible in a timely manner.
Data backup by a registry is important for continuity by the registry operator.
In the event that any registry operator is unable or unwilling to deliver data
from a primary or backup source, data escrow with a neutral third party provides
ICANN with this capability.

While VeriSign has architected multiple layers of redundancy in the registry
platform that provide levels of failure prevention, our escrow arrangements and
processes are essential to maintaining the stability of the .net TLD and
ensuring business continuity and will remain in place.


Arrangements for Data Escrow

VeriSign has a long-standing relationship with Iron Mountain Intellectual
Property Management (Iron Mountain), formerly DSI Technology Escrow Service, for
data escrow services for the .net TLD. With over 30 years of experience, $1.5
billion in revenues, and the broadest service platform serving the most global
markets, Iron Mountain is the "leader in records and information management
services." Refer to Iron Mountain's website at www.ironmountain.com more
information about the company and its escrow services.

Our .net Escrow Agreement has been in place since 30 November 2001 with
automatic yearly extensions. In accordance with Appendix S of the .net
Agreement, VeriSign is compliant with all requirements to provide periodic
updates in escrow of registry data in an electronic format mutually agreed on by
ICANN and VeriSign.

VeriSign and Iron Mountain have a proven, rigorous escrow process with daily and
weekly deposits of registry data, as described in the following section. The
remainder of this section discusses the process flow for providing escrowed data
to Iron Mountain, the format and frequency of the escrowed data, the insurance
agreements in place, and the process for recovering and restoring data.

Escrow Process
The steps of the escrow process are listed below and shown in Figure 5(b)xi-1.
1) The report files are concatenated into a single data file.
2) The data file is compressed.
3) A digital signature is applied to the data file based on the message digest
of this file. The data file is also encrypted in this process.
4) This data file is ready for escrow.

Escrow files are then transmitted and stored on a secure FTP server in
VeriSign's data center. VeriSign provides a secure ID and password for Iron
Mountain to use when pulling the file from the secure server.

Upon receipt of the data file, Iron Mountain performs the verification process
within 2 business days of receipt of the escrow data files. The verification
process is as follows:
* Obtain the data escrow file
* Decrypt the data escrow file and verify the digital signature
* Decompress the single file
* Extract the report files using provided scripts. These scripts will produce a
Verification Report that Iron Mountain then submits to ICANN on a monthly basis
* If Iron Mountain discovers that any data files fail the validation process, it
will notify ICANN of the nonconformity within 48 hours

Once the verification process is completed, Iron Mountain will store the file in
a secure location, generate a File Listing, and forward the File Listing and
Verification Report to VeriSign via secure email. This report is forwarded
within 10 days of receipt of the data files.


Data Formats

VeriSign's escrow agreement with Iron Mountain specifies the daily and weekly
deposits of registry data, consisting of a snapshot of each registrar's data. As
shown in Table 5(b)xi-1, the weekly deposits are comprised of a complete set of
registry data. The daily deposits provide a transaction log for each operational
registrar, representing transactions that occurred over the previous 24-hour period.

The daily and weekly escrow processes encapsulate existing registrar reports,
along with certain meta-data, into single daily and weekly escrow files. The
reports contain data for both ASCII and non-ASCII domain names. The format of
this encapsulation enables the escrow service provider to verify the
completeness, correctness, and integrity of the data within the daily and weekly
escrow file.
Completeness, correctness, and integrity are defined as follows:
* A data file transfer is "complete" if all data files transferred from the
source machine are present on the destination machine
* A data file transfer is "correct" if each data file on the destination machine
has the same information content as that on the source machine
* A data file transfer has "integrity" if no data file was altered by a third
party while in transit

Weekly Escrow Files
Verisign deposits a complete set of registry data into escrow on a weekly basis
by electronically and securely transmitting a snapshot of each operational
registrar's data (the "deposit materials"). The snapshot captures the state of
each registrar's data at the time the snapshot was created. The weekly deposit
materials consist of four reports described below:

* Registrar Domain Report. This report contains all domains associated with a
specific registrar. The domain is listed once with each current status and
associated name server. Refer to Figure 5(b)xi-2 for the format of this report.
* Registrar Name Server Report (Listed with IP Address). This report contains
all name servers associated with a specific registrar. The name server is listed
once with each associated IP address. Refer to Figure 5(b)xi-3 for the format of
this report.
* Registrar Name Server Report (Listed with Domain). This report contains all
name servers associated with a specific registrar. The name server is listed
once with each associated domain name. Refer to Figure 5(b)xi-4 for the format
of this report.
* Registrar Common Report. This report contains one row for each registrar.
Fields of the report contain name, location, contact, financial, and business
information. The format of this report is shown in Figure 5(b)xi-5.
Weekly database snapshots are taken at midnight EST on Sundays and are made
available to Iron Mountain no later than 6 p.m. each Monday. Before making the
Weekly Deposit Materials available to Iron Mountain, VeriSign runs the
verification process described above to ensure the file is complete and accurate.

Notification
In conjunction with the delivery to Iron Mountain of the Weekly Deposit
Materials, VeriSign delivers a written statement to Iron Mountain, via secure
email, specifically identifying all items deposited, and stating that the
Deposit Materials have been inspected by VeriSign and are complete and accurate.
The format of the Weekly Deposit email is shown in Figure 5(b)xi-6.


Daily Escrow Files
VeriSign will securely and electronically deposit a transaction log for each
operational registrar representing transactions that occurred over the previous
24-hour period. The logs will be escrowed daily and will include all registrar
activity, such as add, delete, and transfer of a domain name. The daily deposit
materials will consist of one report described below:

Registrar Transaction Report. This report contains transactions associated with
a specific registrar. Domain operations produce one row for each associated name
server. Name server operations produce one row for each associated IP address. A
transaction ID is included to allow unique identification of transactions. The
format of this report is shown in Figure 5(b)xi-7.

Daily transactional data is made available at the close of business, six days a
week, Tuesday through Sunday, for the previous calendar day. For example,
transactional data created on Monday would be available to Iron Mountain on
Tuesday at the close of business. Before making the Daily Escrow File available
to Iron Mountain, VeriSign runs the verification process described above to
ensure the file is complete and accurate.

Notification
In conjunction with the delivery to Iron Mountain of the Daily Escrow File,
VeriSign delivers a written statement to Iron Mountain, via secure email,
specifically identifying all items deposited and stating that the Escrow File
has been inspected by VeriSign and is complete and accurate. The format of the
Daily Deposit email is shown in Figure 5(b)xi-8.


Insurance Arrangements

As a financially sound, U.S.-based, public company with robust technical
capabilities, VeriSign presents negligible risk of a sudden business
interruption to the .net registry. VeriSign maintains property, business
interruption, and general liability insurance to mitigate the risk of a
catastrophic event that would necessitate reassignment of the .net registry with
reconstitution of the registry from escrow. To further provide assurance of
.net's stability, VeriSign has the following insurance coverage and limits:

*Property Insurance
 - Coverage. Real property in which VeriSign has an insurable interest,
including personal property owned by VeriSign and property of others in
VeriSign's custody to the extent that VeriSign has legal liability for physical
loss or damage. Coverage for income lost and extra expenses incurred to avoid or
minimize the suspension of business as a result of damage to VeriSign's property
caused by a covered loss.
 - Insurer. Factory Mutual Insurance Company (FM Global)
 - Property and Business Interruption Limits. $500,000,000 per occurrence loss limit

* Commercial General Liability Insurance
 - Coverage. For legal liability as imposed by law or assumed under a contract
for bodily injury, property damage, personal injury, or advertising injury
arising from an occurrence during the policy period.
 - Insurer. Chubb
 - Limits. $5,000,000 per occurrence

Insurance program information, additional insurance coverage (worker
compensation, professional liability, and auto liability) and limits are
available upon request.


Backup Plans for Data Recovery

The primary plan for data recovery is discussed in Section 5(b)xviii, which
outlines VeriSign's detailed processes and mechanisms to restore the .net
registry. In nearly every possible scenario, VeriSign remains fully capable of
supporting data recovery and is committed to provide ICANN with full
cooperation. VeriSign is also committed to establishing appropriate measures to
facilitate data recovery and full system restoration in the most remote and
unlikely scenarios that might occur in the absence of VeriSign's active
participation. There are three major components to VeriSign's plans for data
recovery:

1) Recovery of Zone File Data. DNS resolution is the most critical aspect of
preserving operations; this data is vital to continuity of DNS operations for
.net. Due to resolver behavior, caching, and other unpredictable behavior by a
wide range of legacy services, depending on the current DNS service, this
service cannot be seamlessly transferred. VeriSign expends considerable effort
and resources to maintain a robust infrastructure. However, in the event that a
smooth transition is not possible, this must be the highest priority issue
addressed.

A complete loss of VeriSign's primary and backup DNS services would require an
immediate modification of the root zone with distribution to each of the root
zone servers designating new .net name servers. VeriSign posts a BIND formatted
zone file for .net on an FTP server, with over 1,000 zone file access customers,
many of whom download the zone daily. A DNS provider, or multiple providers with
the sufficient capacity and experience, would have to be designated to publish
the .net zone file. Upon completion of the root zone modification, DNS traffic

would begin to be routed to the substitute servers. Such a sudden change would
cause an unpredictable shift in DNS traffic.

2) Data Recovery. The data held in escrow by Iron Mountain is validated for
completeness, correctness, and integrity. Refer to Appendix R for detailed data
retrieval provisions specified in the .net Escrow Agreement.

3) System Reconstitution. Restoring the .net registry in a scenario without
VeriSign's participation would require extensive planning, development, and time
by any operator. The extensive cooperation required between registries to
execute a smooth transition is a good indicator of the difficulty and complexity
under the most ideal circumstances.

During the time required for reconstitution, assuming DNS continues to operate
with static zone information, businesses and organization would not be able to
update any data. Therefore, they would be forced to maintain the status quo
until the provisioning system is reconstituted. Given the interdependencies of
.net and nearly every other gTLD and ccTLD, the impact would be tremendous.

Simply migrating data to a new operator would not be sufficient, nor is this
expected to be the most expedient solution to restoring a secure, stable
registry. Therefore, in addition to maintaining all necessary data to restore
services from any of VeriSign's major data centers, VeriSign proposes to
maintain the following information with a third party that would be released to
ICANN in the event that VeriSign were unavailable to support a smooth transition:
* Detailed System Specifications
* Architecture Diagrams
* Technical Documentation
* Operations Guides


Conclusion

VeriSign has a long-standing relationship with Iron Mountain for data escrow
services for the .net TLD. We are compliant with all requirements to provide
periodic updates in escrow. Through a time-proven process, we have a verifiable
record of delivering completeness, correctness, and integrity of the data within
each escrow file.

As a financially sound, U.S.-based, public company with robust technical
capabilities, VeriSign presents negligible risk of a sudden disruption to the
.net registry operation. VeriSign maintains property, business interruption, and
general liability insurance to mitigate the risk of a catastrophic event that
would necessitate reassignment of the .net registry.

VeriSign has a carefully developed plan for data recovery, including provisions
for DNS restoration, provisions for data retrieval, and provisions to facilitate
system reconstitution.



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

VeriSign has operated the Whois lookup service for .net, .com, and other TLDs
since 1991. We will continue to provide these proven services for the .net
registry, work with the Internet community to improve the utility of Whois data,
while thwarting its application for abusive uses, and will lead the development
of an implementation based on the emerging Internet Registry Information Service
(IRIS) standard.

VeriSign Advantages:
+ Proven track record of providing a fast and reliable Whois service
+ Commitment to solve the problems of Whois through open standards and protocols.

The term "Whois" refers both to the data regarding a domain registration and to
the means to access the data. Both of these definitions stem from the original
definition of Whois specified in RFC 812, which described the types of data
needed for a white pages service of Network Control Protocol (NCP) host
operators of the original ARPAnet and a simple, centralized transactional
protocol for which to access the information. Later updated by RFC 954 to
describe the service over Internet Protocol Version 4 (IPv4) instead of NCP, the
Whois protocol is now most accurately described by RFC 3912.

This section describes VeriSign's publicly accessible Whois service for the .net
registry. We define this service as follows:

* Software. We provide access to Whois via the traditional port 43 Whois/Nicname
protocol interface (as defined by RFC 3912) and via a web-based interface. Our

software is custom-written to meet the high performance needs of over 500,000
queries per minute.
* Hardware. VeriSign operates the .net Whois service on five IBM servers located
at multiple sites. The architecture of our Whois service allows us to scale our
hardware both vertically and horizontally.
* Connection Speed. Our primary site is connected via two OC-3 and two OC-12
connections. Our alternate primary site is connected via two OC-3 connections.
* Search Capabilities. Our Whois search capabilities allow searches on exact
match and partial match of domain names, name servers, and registrars.
* Coordination with Other Whois Systems. VeriSign works carefully with domain
registrars to ensure that no restrictions are placed on their Whois systems. We
are also leaders in the effort to bring about the next generation Whois service,
the IRIS.
* Frequency of Updates. We currently update our Whois database twice per day,
and we are working with the various Internet constituencies to deploy near
real-time Whois updates by the end of 1Q 2006.
* Availability. Our service currently has and will continue to meet availability
performance comparable to our DNS service. We have the ability to throttle back
queries based on individual IP addresses to avoid DoS attacks.
* Processing Time. VeriSign currently processes and will continue to process 95
percent of Whois queries within 5 milliseconds.
* Registry Model. Continuity in the operation of the .net registry is
imperative; therefore, VeriSign will continue to operate the .net registry using
the "thin" registry model and promote the use of the IRIS protocol to give end
users a seamless view of registry/registrar thin data and the thick data of
other TLD registries.

This section includes a discussion of the next generation of Whois services,
IRIS. VeriSign employees are the primary developers of this important new
standard that balances global privacy concerns with legitimate needs for Whois
data access.

The failure to provide an adequate Whois service will seriously hinder the
timely resolution of many technical problems, investigatory phases of law
enforcement, and many other legitimate, non-abusive uses of domain registration
meta-data. One of the fastest growing uses for Whois data today is in the
automated, analytic engines of Internet reputation services used to prevent spam
and combat net-based identity crimes, such as phishing.

VeriSign recognizes the need to maintain the current Whois service as well as
the need for a seamless implementation of new protocol access mechanisms to
Whois data. While VeriSign has been an active participant in the creation of the
next-generation Whois system, we understand that many currently deployed Whois
clients depend on the Whois/Nicname protocol interface on port 43 (as defined by
the Internet Assigned Numbers Authority (IANA) protocol port number registry).
Many of these clients assume that the data contained at whois.internic.net
contains both .com and .net domain registration data. VeriSign is committed to
providing the necessary resources to ensure continued function for the currently
deployed clients, while promoting unhindered solutions, such as the new IRIS
protocol.


Software and Hardware

VeriSign currently answers between 300 and 400 million Whois queries per month
for .net; we are capable of handling peak capacities of 500,000 queries per
minute in peak conditions. Only .com, with between 800 and 900 million queries
per month and also operated by VeriSign, exceeds the number of queries processed
for .net. Other gTLD registry operators process no more than approximately 100
million queries per month.

VeriSign operates two Whois environments containing information from the .net
registry: whois.verisign-grs.net and whois.internic.net. As depicted in Figure
5(b)xii-1, both services contain identical information, and each environment can
be housed in a separate facility. For each environment, VeriSign operates a
web-based Whois service using standard Common Gateway Interface (CGI) methods
and a Whois/Nicname protocol interface on port 43, as specified by the IANA
protocol port registry (this is commonly referred to as the "command-line"
interface).

At each facility, the Whois servers are connected to the Internet by multiple
OC3 connections (450 Mb of network bandwidth). Redundant routers, QoS devices,
and load balancers at each site provide reliability and scalability. Finally,
refined and tested intrusion detection software and procedures provide proven
security in the Whois environment.

VeriSign's redundant Whois databases further contribute to overall system
availability and reliability. Our database servers use five IBM servers with
memory and kernel configurations tuned to deliver the fastest possible query
response. The Whois software is written by VeriSign and is fully compliant with
RFC 3912 (that obsoletes RFC 954), which was written by a VeriSign employee. It
uses an advanced in-memory database technology to provide overall system
performance and security.

The hardware and software for our service are architected so that we may scale
our Whois service both horizontally (adding more servers) and vertically (adding
more CPUs and memory to existing servers) to meet future need.


Connection Speed

We understand the importance of reliable and high-performance Internet
connections in the Whois environment. Each facility hosting the Whois service
has multiple Internet connections. The primary Whois facility connections
consist of two OC3 connections and two OC12 connections, while the alternate
primary facility also has two OC3 connections. Each facility is served by more
than one ISP. Our Whois databases are optimally tuned at the TCP network layer
to accept connections, deliver query responses, and drop the connection at
levels required to support millions of Whois queries each day.


Search Capabilities

The information contained in the .net Whois database is based on the thin
registry model. Record types that can be searched include .net domains, name
servers, and registrars. The search for name servers can be performed using IP
addresses or host names. Whois will perform a broad search, based on the user
input. Searches will match everything beginning with the input if a trailing
period ('.') or the 'PArtial' keyword is used. Using the following
keywords/characters, a user can narrow his search or change the behavior of Whois:

Expand:                  Show all parts of display without asking
FUll or '=':             Show detailed display for EACH match
SUMmary or '$':          Always show summary, even for only one match
HELP:                    Enter help program for full documentation
PArtial or trailing '.': Match targets STARTING with given string

Search Examples:
domain root
nameserver nic
nameserver 198.41.0.250
registrar Network Solutions Inc.
net.
= net
FU net
$ ibm.com
SUM ibm.com

Conducting a search for a domain, name server, or registrar using its full name
will ensure that a search matches a single record. If VeriSign implements a
thick registry during the term of the agreement, Whois search capabilities will
be extended to search for additional record types for registrants and contacts.


Coordination with Other Whois Systems

VeriSign has the ability to fine-tune access to our Whois database on an
individual IP address basis. We currently work with domain registrars to ensure
that their services are not limited by any restrictions placed on Whois.


Frequency of Whois Updates

VeriSign currently updates the .net information in Whois twice per day, and is
committed to enhancing this service with near real-time updates. Full data
extracts are performed against a copy of the registration database and copied to
the Whois servers for publication.

VeriSign has experience performing near real-time updates in the .name Whois
service. As information is updated in the .name registration database, the
information is propagated to the Whois servers for quick publication. This type
of change is not something that should be rushed into production without careful
consideration and coordination with appropriate Internet constituencies. Upon
completion of system testing and coordination, VeriSign intends to provide
real-time updates for the .net Whois service to align with the real-time
publication of DNS information as it is updated in the registration database.

While the technical requirements for real-time or near real-time updates are not
complicated, VeriSign and the Internet community must consider the impact of
more frequent updates. The Whois database will become a more lucrative target
for data mining, or other behavior changes that lead to significantly increased
queries. VeriSign intends to implement near real-time Whois updates; while it is
important to understand the assumptions of increased traffic to bandwidth,
server capacity, and rate limiting solutions, we must also consider the
non-technical impact, such as privacy concerns, needs of the intellectual
property community, and impact to registrar systems.


Availability and Processing Time

With 100 percent availability, our Whois response time is less than 5
milliseconds for 95 percent for all Whois queries. The response time, combined
with our capacity, provides the capability for the Whois system to respond to up
to 30,000 searches (or queries) per second (a total capacity of 2.6 billion
queries per day). As shown in Figure 5(b)xii-2, our Whois service has sustained
loads over 1.38 billion queries in a peak month, and we have seen query traffic
as high as 60 million queries in a single day.

To further promote reliable and secure Whois operations, the current Whois
service has rate-limiting characteristics within the software, such as the
ability to throttle a specific requestor if the query rate exceeds a
configurable threshold to prevent abusive behavior, such as data mining. In
addition, QoS technology enables rate limiting of queries before they reach the
actual servers, which provides protection against DoS and DDoS attacks. Our
software also permits restrictions on search capabilities. For example, wild
card searches can be disabled. VeriSign is generally not in favor of restricting
searches unless it is clear that the results of the search are being used in
ways not beneficial to the .net registrants. If the need arises, it is possible
to temporarily restrict and/or block requests coming from specific IP addresses
for a configurable amount of time. Additional features that are configurable in
the Whois software include help files, headers and footers for Whois query
responses, statistics, and methods to memory map the database.

Since many registrars use Whois to verify name availability during a scheduled
maintenance period, we never perform scheduled maintenance on the SRS and Whois
at the same time.

Registry Model

The information contained in the .net Whois database is based on the thin
registry model. It contains records for .net domains, name servers used to host
domains delegated in .net, and contact information for .net capable registrars.

VeriSign believes that the thin registry model is the best overall fit for .net
for the reasons: described in Table 5(b)xii-1.

As described above, the primary discriminator in favor of a thick Whois model is
the impact to end users who lack a single source of data and a consistent Whois
interface. Both of these factors are addressed through the IRIS protocol. A
sample of Whois data from thick registries shows that registry Whois data is
frequently inconsistent with the data displayed by the associated registrar.
This sample data highlights the potential end user confusion and registrar
challenges of keeping even a modest amount of data current across multiple
systems. Not all registrars are willing to disclose details about their customer
base that is inherently available through a thick registry model. The increasing
trend of registrars who offers private registrations exacerbates this problem.
Through our IRIS and coordination with registrars, we will offer seamlessly
integrated access to .net Whois data contained in the .net registry and .net
registrars that offer the advantages of a thick registry, without the
liabilities of an unnecessary conversion.

Enhancing the State-of-the-Art

In addition to continuing to deliver Whois services through the current
architecture, VeriSign announced a pilot IRIS service, based on the standard
documented in RFCs 3981, 3982, and 3983, and developed in coordination within
the IETF, with input from the registrar community. In conjunction with the IRIS
pilot, we will contribute to the further development of technical standards and
policies related to centralized Whois access. We are a leader in the Cross
Registry Information Service Protocol (CRISP) working group of the Internet
Engineering Task Force (IETF), which is actively defining this new protocol to
allow greater flexibility for coordination among Whois systems. The IRIS
protocol applies the lessons learned over the past 20 years to resolve many of
today's Whois lookup problems. In this context, IRIS offers:

* Access controls to address privacy concerns, while allowing flexible policies
in accordance with law and property rights enforcement
* Standards-based support of IDNs and other internationalization features, such
as client localization
* Standardized mechanisms for structured queries and responses
* Search continuations and entity references
* DNS label server location.

We will work with ICANN, registrars, and applicable communities parties to
determine an appropriate transition from the current Whois implementation to the
IRIS implementation. Our current plan is to implement an IRIS pilot program
early in 2005. Key to our approach is the timing for the final "cutover" from
the current version of Whois to the IRIS-based Whois capability. Refer to
Section 5(b)xvii, Ability to Support Current Feature Functionality of .net, for
more information about VeriSign's IRIS pilot.

The IRIS-based Whois system we are developing will comply with Appendix W of our
.net agreement with ICANN and demonstrates our commitment to identifying,
developing, and implementing new technologies capable of enhancing DNS

functionality. Another important VeriSign innovation related to our Whois
services is the lightweight domain availability service currently under
development. This new technology will enable more efficient domain name
availability queries to benefit registrars and Internet users.
No other TLD operator has been as active in finding true community consensus for
solutions to Whois problems. In addition to participation in IETF working
groups, ICANN task forces, and numerous privately held design team meetings of
key stakeholders, VeriSign has held public hearings and talks at the following
events:

* First UWho Consultation, August 15, 2001; Washington, DC, USA
* Second UWho Consultation, November 15, 2001; Marina del Rey, CA, USA
* Third UWho Consultation, November 19, 2001; Washington, DC, USA
* DNR WG of RIPE 40, October 1-5, 2001; Prague, Czech Republic
* Database WG of RIPE 40, October 1-5, 2001; Prague, Czech Republic
* General Session of NANOG 23, October 21-23; Oakland, CA, USA
* DNR WG of RIPE 41, January 14-18, 2002; Amsterdam, The Netherlands
* Database WG of RIPE 41, January 14-18, 2002; Amsterdam, The Netherlands
* NANOG 24 Universal Whois BOF, February 10-12, 2002; Miami, FL, USA
* CENTR General Assembly, February 21-22, 2002; Rambouillet, France
* CENTR Technical Advisory Working Group 11, July 17, 2003; Vienna, Austria
* CRISP/EPP BoF at APRICOT, February 26, 2004; Kuala Lumpur, Malaysia
* Database WG of RIPE 48, May 3-7, 2004, Amsterdam, The Netherlands
* DNS WG of RIPE 49, September 20-24, 2004, Manchester, UK.

Through our commitment for finding true community consensus to the problems of
Whois, we have also worked with the RIRs in pursuit of solutions that affect our
common constituencies. VeriSign has held private consultations and symposiums
with the American Registry for Internet Numbers (ARIN), the Reseaux IP Europeens
Network Coordination Center (RIPE NCC), and the Asia-Pacific Network Information
Center (APNIC).

Unlike other gTLD operators, VeriSign has invested resources in the development
of advanced client and server software to meet the needs of sophisticated users
and to better serve non-English speaking end users. VeriSign is unique among
gTLD operators in that we make this software freely available under common,
well-understood open source licensing terms.


Conclusion

VeriSign has a proven track record of providing a fast and reliable Whois
service to support the registry functions of .net and other TLDs. Combined with
our commitment to solve the problems of Whois through open standards and
protocols, open source software, and consistent dialog with the Internet
community, we can confidently describe our Whois service as the best in the
industry.



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

VeriSign has engineered the .net registry as a system of integrated components,
based on peak demands to deliver highly reliable, highly available, and highly
scalable registration and resolution systems for the .net registry. Our systems
and processes for stress, load, and performance testing are scaled to exceed the
projected .net capacity demands, including the addition of IPv6 and DNSSEC.

VeriSign Advantages:
+ Capacity to support over 400 billion queries daily with peaks over 500,000
queries per second
+ Registry systems proven reliable through DDoS attacks, viruses, worms, and spam
+ Scalability to meet extraordinary demand to maintain business continuity
+ Demonstrated experience in peak capacity planning and forecasting

This section describes VeriSign's capabilities for capacity planning to meet
peak demands, including:
* Technical capability for handling larger-than-projected demand for
registration or load. VeriSign proactively designs systems to scale both
horizontally and vertically in anticipation of peak load requirements, and have
demonstrated experience in maintaining excess processing capacity.
* Effects on load on servers, databases, backup systems, support systems, escrow
systems, maintenance, and personnel. VeriSign has gained unique experience as
the longest-serving gTLD operator in the world. Our operational experience helps
us understand and plan for the effects of load on all of our systems.

Since VeriSign began operating domain name registries, registration rates have
grown from 400 per month to exceed 1 million new registrations per month. Total
transaction volumes have increased at an even greater rate, with a peak daily
volume of more than 225 million transactions. However, the average transaction
response time has been reduced to less than one-twentieth of its value 4 years ago.

Over the past 4 years, VeriSign's DNS resolution demands have grown at an
exponential rate from less than 1 billion queries per day to over 13 billion
queries per day, with peaks over 15 billion per day. Although .net comprises
approximately 15 percent of the combined .com and .net registrations, .net is
responsible for approximately 30 percent of the DNS queries. The peak for .net
queries routinely exceeds 60,000 queries per second. During a DDoS attack, this
query rate can easily exceed many multiples of the routine peaks.


Technical Capability for Handling Larger than Projected Demand

VeriSign's approach to addressing peak capacities is a three-step process, which
is outlined by setting scalability strategies, scalability standards, and
capacity planning.

Scalability Strategy. VeriSign systems are designed to perform consistently and
predictably through anticipation of loads greater than known peaks. Our capacity
management begins by analyzing historical data for .net domain growth, DNS query
growth, and registrar transaction behavior. New registry services, such as IPv6
and DNSSEC are also considered. Network, server, and storage architectures are
designed, scaled, and tested to provide capacities for unexpected peak loads.
Capacity planning and monitoring provide feedback for production systems to
determine when scaling is required and when projections should be adjusted.

VeriSign has incorporated QoS considerations into the design and testing
requirements for mission critical registry services. For example:
* Hardware is selected for its ability to meet the forecasted demand for 4 years.
* Load-balanced arrays, such as resolution, gateway, or application servers, are
N+1 horizontally scalable systems.
* Core systems, such as OLTP servers and mass storage frames, use state-of-the
art equipment, and provide substantial vertical scalability.
* Component performance is profiled and analyzed to determine the effects of
various workload factors, including: transaction type, rate, and connection count.
* Provisioning systems are designed and tested to handle, at a minimum, double
the expected peak workloads, without deterioration in the QoS.
* Critical systems are tested to scale in a QA environment and re-tested in an
operations staging environment before every upgrade, configuration change, and
code deployment to verify consistent performance under stress.

VeriSign engineers have developed test cases, scripts, load generation
resources, and have the extensive experience and tools necessary to evaluate the
results. All changes to the registry system undergo the following tests before
being deployed into a production environment:
* Stress Testing. To validate that systems will perform to specification,
VeriSign conducts full load tests in the QA environment. This verifies that
systems meet capacity and performance requirements without degradation over an
extended period of time.
* Load Testing. Realistic loads are generated and applied to the system to
validate that the system will exceed the system capacity design specifications.
The loads are continually increased to determine how far beyond the design
specification systems will operate before they begin to fail.
* Performance Testing. By evaluating a series of related metrics, such as
transaction throughput, response time, and CPU utilization for each component of
the system, we test and validate the expected performance in preproduction
environments.

The following are two examples of technologies implemented by VeriSign:

The SRS network infrastructure includes QoS equipment that ensures each
registrar receives an equitable slice of system bandwidth. This equipment allows
VeriSign to identify and resolve aberrant behavior to preserve system
performance for all registrars.

1. A new form of competition has evolved resulting in highly automated, repeated
attempts to register a name. In this scenario, competing registrars run large
arrays of systems consuming all available registry resources. Traffic rates of 3
million registration attempts per hour for .net are not uncommon. VeriSign
designed and deployed a discrete pool system that maintains equivalent access,
while separating the DDoS style registration workload from the conventional
registration activity.

2. Process workload monitoring and QoS are designed to anticipate and rapidly
detect problems and discussed in Section 5(b)xvi. Our QoS metrics, detailed and
analyzed in Section 5(b)xv, exceed our SLA performance metrics.

Resolution System Scalability Standards. The ATLAS resolution system is scaled
for extraordinary demands associated with the exponential growth of Internet
communications. Worms, viruses, spam, and DDoS attacks provide constant
challenges to availability. VeriSign offers a resolution system with the
scalability that absorbs the impact of Internet events, while providing the
Internet community with continued high-performance DNS resolution services for
the .net domain.

VeriSign addresses this requirement by scaling each resolution site to the
following standards:
* Scale sufficient to handle the 4 times the projected growth of the zone file
over the next 6 years, including IPv6 longer IP-address for IPv6 and the
addition of 128-bit keys for DNSSEC.
* Scale to handle DNS query loads, including normal peaks and projected growth.
* Scale to handle events, such as DDoS attacks and traffic generated by viruses,
worms, and spam. VeriSign designs and deploys excess capacity of at least 10
times the measured peak rate on the most loaded server as a requirement. To
handle simultaneous attacks across the network, VeriSign's maintains multiple
geographically dispersed points of presence.

Registration Systems Scalability Standards. Transaction volumes and the number
of registrars, together with developments, such as IPv6 and DNSSEC, present
challenges to deploy scalability systems. VeriSign standards for .net
registration system include:
* Scale beyond historic peak volumes and projected growth
* Scale to 2 times base capacity
* Database CPU utilization less than 50 percent during peak loads
* Database memory allocations less than 40 percent of the total available
physical memory

Capacity Planning
VeriSign's dedicated capacity planning engineers work with development engineers
and QA teams to baseline performance profiles for each registry system. Results
for all transaction types are benchmarked, including: CPU usage, input/output
rates, and operations rates. The performance points provide measurable
thresholds to determine when increased capacity is required. VeriSign performs
real-time monitoring and historical analysis and reassesses the performance
points with each major architectural change in hardware or software.



Effects of Load on Servers


SRS Server Load. The SRS application and gateway servers are affected by
transaction load and connection count. VeriSign systems are designed to deliver
consistent performance during tremendous transaction spikes. A typical day's
transaction volume is shown in Figure 5(b)xiv-1. Daily peaks are the result of
demand for expired domain names. Optimum system performance is characterized
with an orthogonal test matrix. VeriSign engineers determine the most efficient
processing level for each type of system. They then tune system components and
QoS equipment to the appropriate connection and transaction rate protocol.

VeriSign has deployed excess capacity to handle twice the observed and expected
peak systems load. QoS hardware meters the incoming workload to prevent systems
from being driven to a queuing condition. Figure 5(b)xiv-2 shows a typical day's
response times with minimal effect corresponding to the daily demand surge for
expired domain names.

DNS Server Load. VeriSign places the highest priority on delivering 100 percent
availability, while maintaining the capacity to support this growth and weather
attacks without sacrificing response time. The DNS server load is comprised of
the zone file size, frequency and number of updates, and volume of DNS queries.

VeriSign's current system easily handles increases in the size of the .net zone
file. For example, the .com zone is more than 6 times the size of the .net zone
and our ATLAS resolution system stores the entire zone file in physical memory.
The effect of zone file updates on the .net DNS servers is determined by the
number of domains and name servers added, deleted, and modified. Currently,
VeriSign supports an average of more than 130,000 updates per day, while
maintaining 100 percent data accuracy and integrity. These updates are
distributed via highly available VPNs to each resolution site. While our DNS
capacity requirements are driven by the peak demand for .com and .net lookups,
.net peak queries routinely exceed 60,000 queries per second. During a DDoS
attack, our servers are scaled to support many multiples of the routine peaks.

Load on Whois Servers
VeriSign applies the same capacity methodologies to the Whois services that
apply to other VeriSign registry systems. Details of Whois service are described
in Section 5(b)xii.


Effect of Load on Databases

VeriSign's registry storage systems are continually assessed to meet future
demands. The most recent upgrade, deployed in May 2004, was designed to scale to
the projected needs for the next 4 years, with the ability to scale horizontally
without the need for a major outage. This design point includes the possibility
of conversion to a thick registry, which would add contact records to the
registry database. Upcoming technologies, such as IPv6 and DNSSEC, together with
the increasing number of registrars and .net domains, necessitate highly
scalable OLTP and reporting databases.

Database Performance. VeriSign designed the .net database systems to maintain
CPU use rates below 50 percent during the daily peak transaction demand to
maintain stable registry operations. Figure 5(b)xiv-3 shows a sample 24-hour
time range that includes the period when expiring names are released. The
minimal relative increase in system usage is compared to the increase in demand.

Database Scalability. To alleviate load on the OLTP database, Verisign uses BCV
technology to make several copies of the database to run reports, DNS, Whois,
and backups. The growth of the OLTP database and transaction logs is reflected
for each mirrored copy of the database that could be used for backups and
generation of reports. Implementation of DNSSEC will provide significant
increases of database size.

Extracts and Reporting Capacity
BCV instances are used by separate systems for the production of reports, Whois
data, and DNS data. Therefore, substantial changes in workload and batch
activity will not degrade provisioning and resolution services.


Effects of Load on Backup Systems

The VeriSign backup and restore implementation, which relies on a proven
five-tiered backup design, mitigates typical problems associated with subjecting
traditional tape backup systems to increases in data quantity if implemented on
a production network. The VeriSign approach, therefore, mitigates the risks of
increased backup times and increased restore times associated with increased
load. The details of this process are described in Section 5(b)x.


Effect of Load on Support Systems

VeriSign's support infrastructure is mature, efficient, and capable of handling
the next 6 years of projected increases in registration demand. Increases in
registration or resolution transaction load might cause residual effects within
the support systems. Typical effects include the following:

* The NOC supports .net and other domain name registries. Short-term changes in
registration demand do not directly affect these systems. Long-term changes,
such as an increase in the number of systems to be monitored, have an
incremental, but minimal overall affect.

* Security systems such as firewall, VPN, and intrusion-detection-devices, are
already sized appropriately to handle the demands of .com and .net. This
equipment is also guarded by QoS systems, which can deny overload traffic, as
described earlier in this section.

* Customer services are most affected by the number of registrars and the rate
of certifying new registrars. Customer Service has maintained consistently
superior service, described in Section 5(b)xix, as the number of operational
registrars has grown from 61 to more than 250 over the past 4 years, as shown in
Figure 5(b)xiv-4. During this time, VeriSign aggressively worked to streamline
the ramp-up process, reducing the average time for a registrar to become fully
operational by 30 percent. VeriSign has been extremely successful supporting
this growth.


Facility Support
VeriSign's facilities are prepared to rapidly scale systems in response to
increased loads. Each data center is designed with extra capacity for rack
space, power, and cooling to accommodate sufficient servers and storage systems
exceeding optimistic growth forecasts over the next 6 years.


Effects of Load on Escrow Systems

Escrow load is proportional to the total number of registered domains.
Short-term increases in registration traffic do not significantly affect
VeriSign's escrow services. Larger than projected demand for registrations will
ultimately increase the volume of data backed up for data escrow. The result is
increased generation times for data escrow reports, increased data storage for
the larger reports, and increased transfer times to the third-party escrow
agent. VeriSign has proven the ability to scale escrow systems to support more
than 35 million domains.


Effects of Load on Maintenance and Personnel

Registry system hardware maintenance is typically scheduled during off-peak
hours for load-balanced systems or during scheduled maintenance periods for
mission critical systems. Mission critical systems are designed so that the
failure of a single field replaceable unit results in performance that will meet
production demands. This type of architecture permits scheduling repairs during
off-peak hours or during planned maintenance windows.

VeriSign's registry systems are sized, based on the following system maintenance
considerations:
* N+1 or greater status for load-balanced systems is maintained at all times.
Load-balanced arrays are expanded, according to measured and forecasted demand.
* Mission critical systems are sized to operate to meet production demands, even
in degraded mode, to sustain nominal and design peak workloads.
* Mission critical systems are configured in symmetrical high availability (HA)
pairs and/or include fault tolerance. The OLTP database HA configuration
provides reliable detection of failed components.
* VeriSign maintains fully redundant data centers to shorten maintenance
periods. The maintenance can be performed at an alternate site; services are
then redirected to that site while maintenance is completed at the primary site.
* VeriSign maintains three standby resolution sites (in addition to the 14 sites
around the world) that provide the ability to maintain full resolution service
capacity without impacting availability even during peak periods.

Personnel

VeriSign's .net registry does not rely on routine manual components that are
affected by changes in registration demand. Indirect effects of increases in
registry system load include:
* Software Engineering, QA, and stress testing must support and meet higher
performance benchmarks. VeriSign has a mature development infrastructure with 5
years of experience supporting .net, and other high-volume DNS architectures.
* Network Administration must manage increased bandwidth and server use. Scaling
of network components, provisioning of multiple ISPs, and load balancing leads
to efficiencies in manpower.
* Systems Administration will see incremental increases in workload due to
larger load balanced arrays. VeriSign has achieved exceptional efficiency by
using well-developed standards and automation tools.
* Database Administration will see incremental increases in workload due to
transaction volumes. VeriSign's database and storage infrastructure provides
capacity to processed increased transactions without operator involvement.
* The 24x7x365 on-call staff can receive more system alerts and escalations due
to increased numbers of systems or the workload on those systems. Potential
system overload problems are unlikely due to the QoS design characteristics of
our registry services.
* Customer Service and Customer Affairs workloads generally increase with the
number of registrars and not with the load on registry systems.
* The 24x7x365 NOC uses VeriSign's highly automated alerting system to achieve
efficiency of scale.


Conclusion

VeriSign provides a proven history of reliable operations for the .net registry.
Our demonstrated performance includes:
* A proven, reliable SRS:
 - Eliminates the risk of transition
 - Preserves continuity of business for registrars with processes based on known
system interactions
 - Delivers assurance of QoS through demonstrated ability to handle peak loads.
* An SRS scaled for extraordinary demand driven by the secondary market for
deleted domain names:
 - Allows registrars to compete aggressively for valuable domain names, while
delivering equivalent access.
 - Maintains continuity of service of both registration and resolution systems.
* A staff experienced in peak capacity planning with demonstrated ability to
deliver systems that exceed peak demands:
 - Provides security and reliability through proven ability to deflect continual
abuse, inadvertent misuse of services, and DDoS attacks.



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

VeriSign has a stable and robust DNS and SRS system that have provided
consistent availability. In addition, VeriSign customer service has provided the
entire registrar community with industry-leading service.

VeriSign Advantages:
+ 100 percent DNS resolution for over 7 years and industry leading SRS reliability
+ Resilience to myriad forms of DDoS attacks, viruses, worms, and spam
+ Numerous proactive methods to ensure the stability and security of the Internet.

This section includes the following:
* Definition of System Reliability. The probability that a system, including all
hardware, firmware, and software will satisfactorily perform the task for which
it was designed or intended, for a specified time and in a specified environment.
* Analyze Quality of Service. VeriSign measures the availability, data accuracy,
and response times of the registration and resolution systems.
* Quantify Quality of Service. The most significant portion of the registry is
resolution; this can be summarized as being available 100 percent of the time.
The registration component has been meeting service levels above 99.9 percent
uptime.

VeriSign has designed reliability into the registry solution and sites,
resulting in a scalable and supportable infrastructure to achieve availability.
The concepts of simplicity and parallelism have been pursued in both code and
systems. Going counter to feature-rich development patterns, the number of lines
of code between the end user and the data delivered is intentionally minimized.
The result is a network of restorable components that provide both rapid,
accurate updates and name resolution lookups.


Definition of System Reliability

System reliability is the probability that a system, including all hardware,
firmware, and software, will satisfactorily perform the task for which it was
designed or intended, for a specified time and in a specified environment.

* Availability is defined as the percentage of time for which a system is
available for use. That is, A = Uptime/(Uptime + Downtime). As downtime
approaches zero, availability goes to 100 percent. Thus, where component
reliability fails, redundancy, frequent failover testing, and a supply of spare
parts reduce downtime, and therefore, increase availability.
* Operational Availability: We measure every incident where a system or any
significant component thereof becomes unavailable for any reason, and how long
it stays unavailable. The availability for the existing .net provisioning system
takes into account planned and unplanned downtime. Overall availability is the
product of planned availability and unplanned availability.
* Data Accuracy: Data accuracy is defined as the percentage of
registrar-initiated transactions that are eventually distributed to the name
servers and Whois servers with no data loss or data corruption.

Performance: Provisioning system performance is defined as the time from when
the registry receives a request to add, modify, delete, or query the .net
domain, measured starting at the registry gateway, to when the system returns a
response.

For actual DNS traffic, internal response times are measured from receipt of DNS
query at a name server until said name server provides the response.
Additionally, ICANN has established the Cross Network Name Server Performance
metrics from four geographically dispersed sites.


Analysis of Quality of Service

Our registry environment has a provisioning system with customer-facing
gateways, web servers, and ancillary servers. These hosts connect back to
application servers, which connect to a redundant database of record.
Performance is increased by adding more servers and bandwidth, and by increasing
the computational throughput of the database server. Refer to VeriSign's website
for a detailed analysis of quality of service at verisign.com/nds.

The difficulty lies in providing a consistently performing system. Quality of
Service can then be expressed in terms of availability:
*95 percent - A nonredundant three-tier provisioning system running mature code.
*99 percent - Adding local redundancy in the way of parallel network gear,
servers, and database clustering.
*99.9 percent - Adding a full, pre-equipped, four-hour failover disaster
recovery site with a zero data loss replication mechanism.

Downtime includes planned maintenance, link failures, code-related breakage,
data center issues, etc. A scalable approach to build further availability into
the SRS is to add redundant active provisioning sites, but in a manner that
doesn't introduce complex interdependencies. We can achieve 99.99 percent system
availability by making the recovery site active, but directing the application
servers at this site toward the database at the primary site. Synchronous
database commits at both sites ensure zero data loss in the event of failure.

We can similarly examine alternative approaches to resolution sites:

Single site - If .net resolution traffic peaks at 70 million queries per second,
then all DNS requests could be serviced via a single Internet feed using a fast
BIND server. However, there would be a minute or two of downtime every time the
zone file was refreshed.

Multisite - At first glance, setting up six or more 95-percent available
parallel sites should result in zero downtime for DNS resolutions. But all DNS
resolvers do not always query all advertised name servers. Network failover
mechanisms such as BGP anycast do not always respond appropriately to failure,
with slow convergence.

Local redundancy - This reduces the likelihood of any one site failing. Single
site availability in normal traffic patterns should climb to 99 percent by
adding local redundancy. Yet a single bad update still corrupts all sites.

Validation code - Code is introduced to validate updates before they are
distributed, and possibly additional code is used to compare query responses at
the resolution sites to the system of record. A DDoS attack or other asymmetric
event can increase traffic eight-fold on the resolution sites, overwhelming the
system.

VeriSign's DNS solution recognizes the shortfalls of each of these approaches by
maintaining 14 operational sites with 3 hot standby sites. Each site is fully
locally redundant to maintain service during updates. Zone updates are validated
during each step of the generation, distribution and publication process.
Detailed description of our ATLAS DNS service is provided in Sections 5(b)ii,
vii and viii).


Quantify Quality of Service

VeriSign's core SRS currently is run from one locally-redundant site, with an
equivalent alternate primary site ready to receive transactions. Each
provisioning site is comprised of about 100 servers; overall availability is
above 99.5 percent per site. The SRS also been operated in an active-active
configuration, which is necessary for further increases in overall system
availability.

Each of VeriSign's resolution sites has from 12 to 24 servers; most of these are
front-end protocol engines, which receive the Internet DNS queries and transmit
responses. In addition, a BIND backup service on separate servers also exists at
these sites, in the event of loss of ATLAS. Diverse systems are used to resist
day-zero exploits. Hardware is replaced on a 3 to 5 year cycle.

The provisioning system and ATLAS system components are described below in terms
of accuracy, performance, and availability. Detailed reliability predictions of
each component layer are made based on past performance, and overall system
operational availability is then determined [Tables 5(b)xv-1 through 3].

Analysis of Provisioning System

VeriSign is the only registry to undergo an annual audit by ICANN to ensure all
registrars are guaranteed equivalent access. Equivalent access for the .net
registry is managed via a QoS device that acts as a front-end to the SRS. This
QoS device manages two critical aspects of registrar access to the .net database:
SSL connections - Each registrar is permitted the same maximum number of SSL
connections to the database.

Equivalent access - The QoS device is configured so that each registrar has an
equivalent amount of network bandwidth.

When the SRS experienced massive load spikes, resulting from intense registrar
demand for expired and subsequently deleted domains, VeriSign quickly deployed a
unique system where registrars access the registry through three connection
pools, each with equivalent connections and associated bandwidth.

Reducing capacity for registrar connections, transaction rates, or response
times to levels comparable to other registries would require changes to
registrar systems and/or reduce their business transactions. For example, if
domain name check response times increase from 10 to 400 milliseconds,
registrars can lose customers whose first choice of domain is not available and
might be unable to offer suitable alternatives as quickly.

Table 5(b)xv-4 compares response times and the standard deviation of those times
for different registries. The exceptionally rapid response times for .net
consistently exceed those of other registries. Just as important is the
inconsistency of response times of other registries, as indicated by the large
standard deviation.

Over the past 2 years, the average time of an SRS outage has been less than 50
minutes, which includes time to identify, diagnose, and resolve the problem. The
.net registry has never exceeded the time announced for scheduled maintenance.
This provides registrars with consistent, predictable performance and rapid
restoration of service when infrequent incidents occur.

Table 5(b)xv-5 demonstrates the availability comparisons among the generic
top-level domains (gTLDs). The information summarized in Table 5(b)xv-5 is
reported monthly by each gTLD and posted at
http://www.icann.org/tlds/monthly-reports/.

The VeriSign SRS is designed with a focus on the integrity of each database
transaction. The use of well-known Oracle and EMC technologies promotes
transactional integrity. These technologies also serve as the foundation for
comprehensive and redundant logging (Refer to Section 5(b)x).

Provisioning System Availability Review

The primary provisioning site is hosted at a VeriSign data center. An
equivalent, alternate primary site is also active at a separate VeriSign data
center facility. VeriSign advertises four autonomous systems at each SRS site
through independent providers. Edge routers perform BGP load sharing. They are
used to transmit registry registrar protocol requests, Whois requests, and
various other services, such as https, FTP, and email. VPNs also are in place
from each SRS site to the individual DNS resolution sites; these are used to
transmit updates and receive log information.

Figure 5(b)xv-1 depicts RRP traffic flows and local redundancy in any of the
resolution sites. Similar paths are followed for the Whois and https traffic
into the provisioning site. Local redundancy is maintained for each piece of
equipment.

On average, the individual pieces of equipment (routers, switches, load
balancers, servers) have shown availability of about 99.99 percent. Spare
network and host equipment is available at the SRS data centers.

Switches: Load is segmented across trunked switches: one-half of the protocol
gateways are attached to one switch, while the remaining gateways are connected
to the other switch. The firewalls are similarly connected. This was a
deliberate decision to favor simplicity over a cross-connected cabling approach.

Load Balancers: Three pairs of load balancers are deployed in the provisioning
system. In each case, two load balancers are set up in an active-standby
configuration. One set of load balancers is dedicated to the RRP gateway
traffic; another is dedicated for Whois traffic; and a third is used for web,
mail, and file transfers. In each case, the active load balancer distributes
load via a round-robin mechanism to the underlying servers. The choice of
round-robin load distribution was made in favor of simplicity.

Shared services servers: Web, mail, and FTP servers are set up in an N+1
configuration.

Gateway Servers. As depicted in Figure 5(b)xv-1, two branches of gateways are
deployed at each SRS site. These gateways are divided into three groupings,
corresponding to the guaranteed, overflow, and auto-batch pools set up for
registrar transactions. If the switch or load balancer in front of the gateways
fails, that entire branch of gateways becomes unavailable. Failure determination
and recovery was determined to be simpler in this approach than channeling
traffic to an alternate switch. If one gateway branch cannot carry the entire
RRP load for the entire site; performance degradation would occur, and failover
to the alternate site becomes necessary.

Application Servers. Application servers are scaled according to the number of
gateway servers, in a 1:4 ratio. Similar to the arrangement of the gateway
servers, application servers are connected to different switches, so that if one
switch fails, the entire infrastructure is not lost. Application servers connect
to the single OLTP database.

Whois Servers. Five hosts service Whois requests from memory-mapped databases
that are rebuilt twice daily from a mirrored copy of the OLTP database.
Currently, four of the five systems are required to handle peak load.
Disaster Recovery: An identical set of production hardware exists at the
alternate primary site.

OLTP Database. As detailed in Section 5(b)v, the OLTP database is the most
critical element of the .net registry provisioning function. Thus, the OLTP
database is clustered at the operating system level in an active-passive
configuration. Data files are stored on an external EMC frame. The array fills
the role of ensuring that database commits are performed at both the primary and
alternate primary sites synchronously over metropolitan fiber links to ensure
zero loss in the event of outage. Archive/redo logs are copied to the alternate
site.

Report database. The critical data archive acts as the SRS data warehouse. It
uses Oracle transportable tablespaces to retrieve records from an array-based
copy of the OLTP database. This is necessary because aged transaction data is
periodically purged from the OLTP database. Figure 5(b)xv-2 depicts array-based
data replication between the primary and alternate SRS sites.

Analysis of Resolution Systems

For the .net name server constellation, QoS is measured primarily in terms of
the following elements:
* Performance, measured in queries per second and packet loss, for valid domains
and nonexistent domains.
* Availability of the service based on system uptime across the constellation
* Accuracy of zone file data.

VeriSign has supported the growth in average daily volumes of DNS queries, as
discussed in Section 5(b)xiv. Figure 5(b)xv-3 shows the DNS activity for a
typical day and reveals obvious peaks. Thus, resolution sites are provisioned to
support volume spikes, rather than meeting averages. The constellation sites
must still maintain the surplus capacity necessary to withstand malicious
attacks and frequent inadvertent DNS errors that can massively increase
resolution site load. VeriSign, therefore, maintains resolution capacity that is
scaled to 20 times the peak volume on the most loaded server. VeriSign also
combines capacity with overall performance by delivering response times
averaging less than 5 milliseconds with less than 0.5 percent packet loss
measured internally. From VeriSign's external monitoring of cross network name
server performance from six global locations, the response times (including
Internet latency) are well under 100 milliseconds.

Resolution Site Availability Review

Eleven of the DNS constellation sites are collocated with six partners, which
provide space, power, and bandwidth. The remaining sites are hosted at VeriSign
data centers. VeriSign advertises all the IP addresses of all constellation
sites in a single Autonomous System (AS). Peering at the individual facilities
is delegated to the bandwidth provider. Figure 5(b)xv-4 shows DNS traffic flows
and local redundancy in any of the resolution sites.

The ATLAS protocol engine (PE) receives the DNS requests, which it packages and
forwards to the .net memory-mapped database on the lookup engine (LUE) for
actual name/address resolution. The results are returned to the PE host, where
they are unbundled and transmitted to the host that originated the query.

Switches: Server switches are dedicated for DNS traffic. Load is segmented: half
the PEs are attached to one switch, while the remaining PEs are connected to the
other server switch. The LUEs are similarly connected. This was a deliberate
decision to favor simplicity over a cross-connected cabling approach.

Load Balancers: The two load balancers are set up in an active-standby
configuration, where the active load balancer distributes load via a round-robin
mechanism to the underlying PEs. Health checks are performed from the load
balancer to the underlying PEs.

Two sets of PEs are deployed at each site, each set receiving content through
its own switch and feeding bundled queries to a single LUE.

At least two LUEs are configured at each site. These LUEs maintain a database of
name servers and glue records. Sendfile updates are received and applied to that
in-memory database around the clock. These boxes currently also provide BIND as
a backup authentication mechanism to ATLAS.

Support Systems. Customer service for .net registrars is available via telephone
and email 24x7x365 with local language support, as required. The first line of
support is highly trained to quickly resolve a range of technical, financial,
and procedural questions and to quickly escalate problems that cannot be
immediately resolved. Section 5(b)xix, details VeriSign's customer and technical
support capabilities.


Conclusion

VeriSign is committed to continue providing a stable and robust system that has
had consistent availability since the inception of the SRS. This is confirmed by
VeriSign's past performance delivering SRS availability over each of the past 7
years. At the same time, the VeriSign DNS resolution system has achieved an
availability rate of 100 percent for the .net zone. No other registry operator
matches this reliability.



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

VeriSign's ability to prevent unplanned system outages is a result of our robust
planning processes and disciplined execution of proven practices.

VeriSign Advantages:
+ A highly available architecture with multiple layers of redundancy
+ Extensive proactive monitoring that minimizes the likelihood, frequency, and
duration of unplanned outages
+ Systems that withstand distributed denial of service (DDoS) attacks, viruses,
worms, and other nefarious activity.

This section describes the following areas:
* Procedures for Problem Detection. Extensive monitoring systems managed from
our Network Operations Center (NOC) identify issues before they become problems.
* Redundancy of All Systems. VeriSign has full redundancy built into each aspect
of our service delivery.
* Backup Power Supply. Each data center has redundant power systems for service
continuity in the event of electrical failure.
* Facility Security. Security for all VeriSign facilities is monitored from our
Security Operation Center.
* Technical Security. VeriSign's security practices protect against physical and
logistical intrusions.
* Availability of Backup Software, Operating System, and Hardware. Each
component of VeriSign's backup solution is architected in the same
high-redundant manner as our provisioning and resolution systems.
* System Monitoring. Our NOC continuously monitors the .net gTLD through a
central event management console.
* Technical Maintenance Staff. VeriSign provides onsite and on-call 24x7x365
technical support.
* Server Locations. VeriSign operates 18 technical facilities around the world
that are strategically selected, based on Internet demand.


Procedures for Problem Detection

The NOC is the central point for rapid detection and resolution of any registry
problem [Figure 5(b)xvi-1]. A distributed monitoring system, based on the
standard Simple Network Management Protocol (SNMP) polls system devices at
1-minute intervals. Upon detection of an error condition or threshold violation,
a prioritized service alert is sent to a single event management queue. Each
event is acknowledged by the NOC staff, and the incident is logged and tracked.
Escalation procedures are used to troubleshoot and resolve problems. Issues that
the NOC cannot resolve are escalated to a skilled operations team for
second-level support.

Problem detection is accomplished using our worldwide monitoring infrastructure.
Servers are individually and collectively monitored down to the Internet
Protocol (IP), port, transaction, and packet level. Monitoring systems run on a
distributed architecture, and details are fed back to a centralized data store
that keeps a history of every transaction. Monitoring output determines if
mission-critical services are operating properly and provides an indication of
service availability specific to the server. Each router, switch, load balancer,
quality of service (QoS) device, and firewall is measured at the packet level
for load level, failover, and SYN floods. Should the need arise, packet sniffers
are used at critical network points to analyze specific events that can cause
degradation of service.

So critical are VeriSign's DNS sites to the global stability of the Internet,
and so extensive is our monitoring, that the National Communications Center
(NCC) and the FBI's National Infrastructure Protection Center (NIPC), and others
have requested and received a direct link to the screens used by the NOC to
monitor the status and performance of these critical resources.


Redundancy of All Systems

VeriSign recognizes the significant role redundancy plays in preventing outages.
This section describes the redundancy built into various components of the .net
system.

Registration System

The .net registration system is protected by a highly redundant server and
facility infrastructure. Registrars benefit from the use of multiple Internet
Service Provider (ISP) connections that use redundant routers and switches
configured for automated failover. Registrar access is protected by QoS devices
that prevent abusive behavior from affecting all registrars. Each transaction
terminates at a load-balanced gateway server. The load balancers provide the
ability to remove a server for maintenance or after a failure without system
impact. The gateway servers communicate through redundant firewalls to clustered
application servers.

A failure in any application server will be recognized by the gateway, which
will take the affected server out of rotation. The .net registration data is
served by a pair of Oracle database machines that are configured using IBM's
High Availability Cluster Management Protocol (HACMP) software. Failures
affecting a database server or device will trigger failover protection to
prevent or minimize system outage. These servers are connected to an EMC
Symmetrix storage system, equipped with mirrored storage for data protection and
internal component redundancy to minimize the likelihood of a system failure.
The EMC storage system replicates the .net database in real-time to an alternate
primary data center for protection against site failure [Figure 5(b)xvi-2]. The
system is designed to support failover and service resumption within 30 minutes
from the time the severity of the problem is recognized.

Resolution System

System outage prevention for the resolution system is enhanced by the use of 14
global sites. Each site is designed and built with complete independence and
redundancy. Each location has multiple ISP gigabit Ethernet feeds that connect
to a redundant network and redundant load balancers that distribute load across
the DNS servers and route around servers should a component fail.

A critical element of preventing DNS outages is over-provisioning. A DDoS attack
can be an extreme challenge. Under most circumstances, the system must absorb
the attack though massive capacity until the event can be analyzed and a counter
measure can be devised. The ability to absorb such an attack lessens the
potential impact. Our global DNS solution can process more than 400 billion DNS
queries a day, with fully redundant, geographically dispersed sites.

Network Redundancy

All VeriSign facilities have diverse Internet connectivity with extensive public
and private peering and a fully redundant routing and switching infrastructure.
Both the primary and alternate primary data centers offer multiple, high-speed
connections to the Internet provisioned through diverse network providers that
enter the building via multiple physical entry points. Inside the facilities,
the fiber travels by disparate routes and terminates at routers in physically
separate cabinets. The resolution sites are each similarly architected and have
a minimum of two diverse gigabit Ethernet connections.

Redundant Facilities

The ability to shift operations between servers or facilities is a critical
element of system outage prevention. We maintain redundant equipment at both our
primary and alternate primary data centers [Figure 5(b)xvi-2]. Not only is each
facility able to assume full operations, but also each facility can also assume
partial operations because the application servers at one site can service the
registry database at the other. This partial operations model provides a
recovery option that is faster than full site failover and enhances our ability
to deliver reliable and stable service to registrars and Internet users. Table
5(b)xvi-1 shows general types of failures that could be expected and the
recovery procedures.


Backup Power Supply

Each VeriSign data center is protected with dual power feeds from the local
power provider. Should local power fail, the data center is further protected by
a series of power-protection devices. Each rack of servers is connected to two
separate power distribution units (PDUs) to monitor and distribute electrical
load. Databases, storage devices, application servers, and network devices are
connected to two separate PDUs that provide protection in case of a single PDU
failure. The primary protection devices are large uninterruptible power supplies
(UPSs) that can sustain the load of the entire data center for up to 30 minutes.
Should a power event last more than 10 seconds, redundant power generators are
automatically started, with each generator capable of handling the load for the
entire facility.


Facility Security

Physical security includes 24x7x365 onsite security guards, card readers, and
biometric controls. VeriSign strictly enforces the use of biometric controls to
access our data centers. All biometric access, as well as card access, is
monitored and logged. We also insist on this discipline for all facilities
hosting our global DNS constellation. In addition, we insist that:

* Buildings are isolated from easements, rights of way, and adjoining tenants.
* A security guard is positioned at the entrance to the building or grounds to
prevent unauthorized access.
* No exterior signs that indicate the type of business are visible from any
public way.
* Backup generators are located within a secured space.
* Data center access is controlled using a mantrap, card readers, and biometric
controls.
* Cameras are located at all entrance points and in sufficient quantity to
monitor all critical infrastructures.


Technical Security

VeriSign's security policies have been developed within the following general
outline:

* Do everything humanly possible. This includes staying abreast of the latest
exploits and technology, as well as implementing all known state-of-the-practice
safeguards.
* Develop contingency plans for those events that are outside your control.
* Monitor frequently.
* Conduct security tests on all devices before placing them into the production
environment.

Dedicated IT Security Staff

Our dedicated IT security staff performs a number of functions in support of our
security posture, including: development and enforcement of application and
network security standards; implementation and management of network security
devices (e.g., firewalls, Access Control Lists (ACL), etc.); working with
government and industry entities responsible for critical infrastructure, such
as the NCC and the NIPC; and participation in government and industry
cooperative forums.

Strategic Vendors and Suppliers

One of the most important elements of any critical operation is the selection
of, and relationship with, vendors and suppliers. As required, vendor staff is
onsite during business hours, alongside Information Technology (IT) staff during
major deployments, and, if necessary, on-call 24x7x365. Additionally, because of
our long-standing relationships and the critical nature of the services we host,
these vendors frequently advise of potential bugs or exploits before public
announcements are made. As a result, we are generally able to devise and deploy
a security-related solution before widespread attempts to use that exploit
actually occur. We strictly follow a policy that requires that each deployed
computing device must pass an intense security check before connecting to the
network. By following these practices, we have often detected and informed
vendors of vulnerabilities that their testing did not discover.

Hardened Network

The .net registration service is connected to the Internet via two border
routers that use ACLs to control access from the Internet and block all but
authorized users. The registry gateway layer is configured with internal and
external interfaces, each assigned to a different subnet. External interfaces
receive queries and registration requests from the Internet, whereas the
internal interfaces communicate with the application and database servers.
Acting as a proxy, the gateway layer will accept and pass information through
the firewall to the application server, thereby eliminating direct access to the
backend servers. This approach provides superior security from hackers or other
Internet-based threats and is consistent with industry best practices for this
type of service.

Firewalls

Firewalls are used to secure the internal network. The firewall is configured
with rules to allow only specific types of data traffic between the gateway
layer on the external network, and the application layer and database servers on
the internal network. Additional rules allow internal management systems to
access the servers via a separate interface, for monitoring purposes and to
refresh files. Security scanning software is used to constantly monitor for
potential vulnerabilities; an outside firm has been contracted to run "friendly"
scans against the network at least twice a year. Results of the scan are
reported to our technical staff, and noted exceptions are promptly corrected.

Secure Virtual Private Network

VeriSign uses encrypted IPSEC virtual private network (VPN) connections to
manage and monitor the global DNS constellation. The VPNs are configured to only
permit connections from authorized machines and users. They are also configured
in a high-availability mode to provide secure connectivity with failover protection.


Availability of Backup Software, Operating System, and Hardware

The architecture of our backup system, including details on software, operating
system and hardware, is covered fully in Section 5(b)x, Backup. Its availability
is 100 percent.


System Monitoring

Distributed Monitoring System

VeriSign's enterprise monitoring toolset uses many web-based utilities tied
together by a portal. All monitoring alerts are fed to a central event
management console used by the NOC to oversee the status of our worldwide
assets. The major component of this monitoring work set is Nagios, an
open-source, web-based tool that uses a secure and reliable distributed
architecture.

Nagios alerts provide information for the NOC to quickly diagnose critical
issues. Historical data is evaluated to provide further insight and ascertain
root cause. Error code handling is configured with each new application.
Product-specific error codes and configurations are included with each code
release. Batch processes provide comprehensive logging and error handling to
quickly diagnose any failures that occur.

Custom and Application-Specific Monitoring

VeriSign uses the advanced capabilities of the TeamQuest performance and
capacity management tool to provide custom monitoring of per transaction detail
for the .net registration system. TeamQuest's output is fed to Nagios for
real-time alerting and is simultaneously stored for subsequent analysis and
historical trending. This information is used to create performance and capacity
trend lines that are vital to our ongoing efforts to prevent outages and system
degradation by predicting when proactive intervention is necessary. As new
software packages are developed, we create custom methods to monitor detailed,
process-level activity to further identify even internal application status. In
addition to feeding our real-time monitoring tool, Nagios, these custom monitors
provide information used to optimize software code and tune system performance
parameters.

DNS Monitoring

In addition to the monitoring detailed above, Verisign has invested
significantly in DNS application monitoring to ensure 100 percent availability
of the .net resolution service. These in-house tools were developed to provide
real-time visibility into the status of our global DNS resolution assets and
consist of four major components.

DNS Site-Level Monitoring. This infrastructure provides a real-time view of DNS
traffic for each resolution site, including the overall health of the site,
network traffic statistics, potential anomalies, and zone version information.
Figure 5(b)xvi-3 shows a sample view of this data for a site.

Heads-Up Display (HUD). The HUD was created to provide a global "dashboard" view
of the overall status and health of our resolution service. Site-level
statistics are aggregated and presented in a detail-rich interface that shows
traffic load, along with a color-coded status for each site. Figure 5(b)xvi-4
shows the HUD. Of special note on the HUD display is the graph on the lower
right, showing the amount of traffic received for the current day versus the
same day from the previous week. This graph [Figure 5(b)xvi5] provides a
continual reference point for operators, allowing them to assess traffic peaks
and valleys in context.

ATLAS Component-Level Monitoring. Every component of ATLAS is instrumented to
report its status and traffic statistics. This information is fed into the
real-time monitoring system and produces alerts when problems occur. Figure
5(b)xvi-6 shows ATLAS components at one resolution site. The green color
indicates all components are healthy. Zone version information is also shown,
allowing operators to quickly assess health and, if necessary, troubleshoot
problems.

Central Storage and Reporting. A central monitoring database serves as a
repository for all historical summary statistics relayed by the various
monitoring applications at each DNS site. This database currently houses daily
statistics dating to the year 2000. Data is stored with an extremely fine
granularity (at the IP, TCP/UDP, and DNS levels) and is collected every 4
seconds at each site. The database and related tools allow for on-the-fly report
and graph generation of any combination of statistics for any specified time
period. Our technical staff uses these tools to compare new trends against
historical data. These records also feed our detailed uptime and traffic growth
analysis and reporting. In addition, our technical staff uses this data to
contact and assist administrators of misconfigured name servers. Figure
5(b)xvi-7 shows anomalous DNS traffic received at three sites in July 22, 2003.
A single DNS misconfiguration was responsible for this spike in traffic. Our
engineers contacted the organization responsible, and the graph clearly shows
the moment when the problem was fixed.


Technical Maintenance Staff

We employ a highly skilled maintenance staff experienced in the operation of the
.net registry service. As shown in Table 5(b)xvi-2, our staff provides onsite
and on-call 24x7x365 technical support. Our staff retention rate rates are
extremely high, which is important for stable, problem-free operations.


Server Locations

VeriSign operates two data centers (in Dulles and Ashburn, Virginia) for the
.net registration system. Either site can be active for registration, and either
can provide full registration services in the event of a site failure. Section
5(b)vi, Geographic Network Coverage, describes our comprehensive process for
selecting resolution sites, which is comprised of 14 active and three
warm-standby sites in the locations shown in Figure 5(b)xvi-10.


Conclusion

VeriSign's ability to prevent unplanned system outages is a direct result of our
robust planning processes and disciplined execution of proven system reliability
practices. Our staff has the technical experience in running large registry
services that are unparalleled by our competitors. Our well-designed, highly
scalable system architecture and continuous system monitoring also help prevent
or minimize unplanned outages. Our robust DNS solution is operated using our
award-winning ATLAS technology and provides real-time updates, 100 percent
uptime, and the capacity to withstand even the largest DDoS attacks. VeriSign's
proven, reliable registry system provides stable operations for a critical
component of Internet 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.

Registrants, registrars, and Internet users depend on features available in .net
today, and in some cases have relied on them for years. The stability and
continuity of services in the .net registry depend on the availability of these
features. These features are in production and in active pilot programs.

VeriSign Advantage:
+ Robust and diverse feature functionality in .net that benefits registrars,
registrants, and end users.

In addition to the standard registry features and functionality, VeriSign is
committed to continued support for the following:
* Internationalized Domain Names (IDN). VeriSign currently has over 90,000 IDNs
representing 350 languages in the .net registry. We have been a pioneer in the
support for IDNs and will continue to improve upon our services as they relate
to IDNs.
* Internet Protocol Version 6 (IPv6). VeriSign currently supports the
registration of IPv6 DNS resource records and the resolution of DNS over IPv6
networks.
* DNSSEC. VeriSign has been a participant and leader in the development of the
DNSSEC protocol. Having deployed several DNSSEC pilots, VeriSign is committed to
a rollout of DNSSEC in .net once the final standard is ready.
* Redemption Grace Period (RGP). VeriSign was the first registry to fully
support the RGP policy, and we will continue to fully support RGP in .net.
* Internet Registry Information Service (IRIS). In our continuing endeavor to
provide stability to the Internet infrastructure, VeriSign has been a leader in
the standardization of the IRIS protocol, and we are the first registry to
deploy an IRIS pilot.
* ConsoliDate. In responding to requests from registrars and registrants,
VeriSign has implemented a program for domain renewal, allowing a registrant to
synchronize the renewal dates of a large number of domains. The program, called
ConsoliDate, alleviates an administrative burden for customers with large
portfolios of domain names.

These features are described below with additional information available on
VeriSign's Naming and Directory Services website. When any available feature or
service fails, or a decision is made to change the implementation or terminate
the service, every customer who depends on the service is affected. If an IDN
implementation did not support each of the scripts currently supported, then all
registrations that depend on that script would fail, and any services that
depend on that domain name would be affected.


Feature 1: IDN

The Internet is used by more than 500 million people around the world. As the
Internet grows, more and more users will speak languages other than English.
IDNs provide a convenient mechanism for users to access websites and other
Internet resources in their preferred language. IDNs are an important factor in
the transformation of the Internet into a truly global and multilingual tool.

Use of IDNs allows Internet users to:
* Navigate to Internet content and address email in their preferred language and
script
* Preserve local culture and support their preferred language

The value of IDNs to registrants enables them to:
* Reach target audience more effectively by communicating in their preferred
language
* Protect, strengthen, and extend existing brand and trademarks; identify secure
brand equity in local markets
* Eliminate any confusion on brand communication
* Improve the customer's navigation experience
* Create global utility that adheres to international standards and leverages DNS

IDNs enable registrars to:
* Provide complementary extension to existing product offering and line of business
* Leverage existing infrastructure investment
* Increase revenue opportunity
* Expand addressable markets; reach new segments
* Provide opportunity to extend new products into reseller network.

VeriSign has supported IDNs in the .net registry since November 2000 when the
IDN testbed was opened to test proposed standards for the deployment of IDN
technology and to provide operational experience with those proposed standards.
As of 31 October 2004, the .net registry contained nearly 90,000
standards-compliant IDN registrations representing most of the 350+ available
languages. VeriSign is the only gTLD to support all available code points and
languages for IDNs.

Several applications are IDN-enabled, but Microsoft's Internet Explorer (IE)
browser continues to lack IDN support. Therefore, VeriSign developed the free
i-Nav plug-in for IE to serve as a bridging technology for a majority of the
Internet's end users. The i-Nav plug-in is a browser tool that enables
standards-based IDN web navigation for all languages and all standard-compliant
TLD IDN implementations. The objective was to create a critical mass of
IDN-enabled desktops and motivate application developers to include IDNs as a
feature in their product lines.

While the plug-in has enjoyed significant adoption worldwide, VeriSign
recognized that end user assistance was only one small step. VeriSign made the
core IDN technology from i-Nav freely available by releasing an IDN software
developer's kit (SDK) in April 2003. This SDK is now the basis of many
IDN-enabled applications in use today.

VeriSign has continued to demonstrate comprehensive leadership in support of IDN
adoption. At the end of the second quarter in 2003, VeriSign recognized the need
for a multi-faceted industry organization to propagate the usage of IDNs and
increase standards adoption in the applications used by Internet end users. This
led to the creation of the IDN Software Developer Consortium (SDC).

In November 2003, VeriSign sponsored an IDN summit for several domain name
registries, registrars, and application developers to discuss how to advance the
opportunity and usage of IDN products across the globe. Table 5(b)xvii-1 shows a
list of application developers, registries, and registrars who have participated
in the SDC. Subsequent meetings of the SDC have been held to drive the adoption
and further proliferation of IDN technologies. The success of this consortium
has been shown through the growing number of IDN applications and announcements
by others concerning the inclusion of IDN capabilities.

Details about VeriSign's implementation are provided at
http://www.verisign.com/products-services/naming-and-directory-services/
naming-services/internationalized-domain-names/index.html


Feature 2: IPv6

IPv6 features a 128-bit addressing scheme, as opposed to the 32-bit addressing
scheme of IPv4, supporting a much larger number of addresses. It also features
other improvements over IPv4 with the expanded addressing capabilities stated in
RFC 2460.

VeriSign has been advancing IPv6 functionality over the past several years and
fully supports IPv6 for the .net registry. VeriSign currently supports IPv6 name
server provisioning, DNS resolution, and transport. All three features must be
considered by the .net registry operator.

(a) Provisioning Support
In May 2002, VeriSign began accepting registration of AAAA records in the .net
(as well as .com and .org) registry. IPv6 addresses allowed must be from a block
allocated to a Regional Internet Registry (RIR). As Internet Assigned Numbers
Authority (IANA) and the RIRs post updates to the allowable IPv6 blocks, the
.net registry system is updated.

(b) Resolution Support
VeriSign has also supported DNS resolution of IPv6 since May 2002. DNS queries
return AAAA records, if present, along with A records in the additional section
of replies.

(c) IPv6 Transport
VeriSign introduced support for IPv6 transport after ICANN's acceptance of the
Root Server System Advisory Committee (RSSAC) recommendation to "proceed with
adding AAAA glue (name server) records to the delegations of those TLDs that
request it."

VeriSign had conducted extensive internal testing, had participated in IPv6
pilot with the root server testbed network, and provisioned IPv6 network
connectivity from multiple providers before submitting a root zone change
request to the IANA.

VeriSign added support for accessing the .com and .net zones using IPv6
transport on 19 October 2004. On that day, AAAA records for a.gtld-servers .net
and b.gtld-servers .net were added to the root and gtld-servers .net zones.
Community reaction has been positive, resulting in more there 500 queries per
second at each site over IPv6 transport.


Feature 3: DNSSEC

The original DNS specification does not include support for security from data
integrity or data authentication. DNSSEC uses digital signatures based on public
key cryptography to add these features.

(a) DNSSEC Pilots
No other registry operator has been involved in DNSSEC research as extensively
as, or for as long as, VeriSign. VeriSign engineers and the Applied Research
Department have played an active role in DNSSEC development almost from its
beginning, contributing to DNSSEC's design over the past several years, and have
edited the current DNSSEC specifications document set. To demonstrate the
application of DNSSEC, VeriSign has developed several pilots.

(i) DNSSEC Lookaside Validation (DLV)
This mechanism for creating a cryptographic chain of trust to a zone that
bypasses the normal DNS delegation hierarchy was developed by the Internet
Systems Consortium (ISC). It is primarily described as a transition mechanism to
help DNSSEC adoption for zones whose parent zones do not support DNSSEC.
Essentially, the DLV proposal uses the concept of a trusted "lookaside" zone as
a method for finding keying information for a signed zone without a secure
delegation from its parent.

VeriSign's DLV pilot implements an example DLV registry. It allows external
users and developers to experiment with the DLV model without setting up their
own lookaside zone. It allows anyone with a publicly available signed zone to
register his zone with the pilot. This pilot is the first known publicly
available DLV registry and is provided at http://dlv.verisignlabs.com.

(ii) .net DNSSEC Pilot
This pilot provides a DNSSEC signed version of the .net TLD zone, using the
latest version of the standards published by the IETF. This pilot provides both
Verisign and external users and developers with operational experience with the
latest DNSSEC specification.

The pilot allows anyone with a valid .net domain name to register a secure
delegation. By participating in the pilot, users can get experience with DNSSEC
using their own zones, and can get experience with secure name resolution within
.net.

The pilot also demonstrates VeriSign's experience with signing, managing, and
serving a DNSSEC-signed version of the net zone. The pilot uses incremental zone
signing and automatic, scheduled key rollovers, all designed to minimize the
overall size of the zone. The pilot uses modern cryptographic hardware security
modules to both increase signing speeds and to protect the security of the
private keys while allowing their constant, online use. This pilot is in
operation and is provided at http://dnssec-net.verisignlabs .net.

(b) Successful Implementation of DNSSEC in .net
A registry operator can offer to implement DNSSEC; however, successful
implementation will require coordination of and cooperation from many
constituencies, as well as a deep understanding of this complicated protocol. An
implementation plan should address the coordination and role of the registry
operator to facilitate a successful deployment, and the operator should be able
to point to a record of working in the DNSSEC research community.

VeriSign has conducted market research on multiple occasions to determine the
level of concern and interest with implementation of DNSSEC, and has led several
forums to encourage community involvement, including our most recent effort to
establish a DNSSEC Applications and Service Providers Consortium.

Implementing DNSSEC will require signing the .net zone, which by our estimates
could increase the size of the zone by a factor of four. Additionally, the
amount of data returned in the DNS response is increased, so the impact on
bandwidth and server capacity must be considered.

VeriSign is committed to implement DNSSEC in .net once the protocol is published
as an RFC or a Proposed Standard. Only VeriSign has the experience and resources
to successfully implement DNSSEC in .net.


Feature 4: Redemption Grace Period

In response to a growing trend of complaints about unintentional domain-name
deletions, in 2002, ICANN proposed an RGP for deleted names. RGP expanded the
5-day delete pending period to create a new "safety net" following any deletion
of a domain name. The grace period would allow the domain-name registrant,
registrar, or registry operator time to detect and correct any mistaken deletions.

VeriSign was the first registry to implement RGP in a solution that is fully
compliant with ICANN policy. In the current .net registry, RGP is the time
period where any "delete" of a domain name outside the add grace period will
result in a 30-day Deleted Name Redemption Grace Period. This grace period will
allow the domain name registrant, registrar, and/or registry time to detect and
correct any mistaken deletions. Figure 5(b)xvii-2 describes the RGP provisioning
process and domain deletion lifecycle.

VeriSign has authored an extension to the Extensible Provisioning Protocol (EPP)
to support RGP and other registry grace periods. This extension was published as
Proposed Standard RFC 3915 in September 2004. Support for RGP will be included
as VeriSign migrates from RRP to EPP in 2005.


Feature 5: IRIS

The Internet Registry Information Service (IRIS) is a protocol developed by the
IETF's Cross-Registry Internet Service Protocol (CRISP) Working Group. It is
intended to be a replacement of the aging Nicname/Whois protocol currently
defined in RFC 3912.

VeriSign has been a leader in the development of the IRIS standard. In August
2004, VeriSign announced the availability of an IRIS pilot service for the .com
and .net registries. This pilot is offered to help foster the adoption of the
IRIS protocol and move the domain industry forward in ways compatible with the
needs of private citizens, law enforcement, and intellectual property holders.
Users can interact with the service either directly using an IRIS client or can
query it using our web interface.

VeriSign has authored multiple client and server software packages and
libraries, which are freely available and licensed under common open source
terms. We operate a website dedicated to the promotion of IRIS to solve the
meta-data problems surrounding domain names.


Feature 6: ConsoliDate

The .net registry supports synchronizing expiration dates of domain names
through a function called ConsoliDate. This feature was implemented at the
request of registrars specifically to support registrants who have multiple
domain names, which often have different expiration dates so they are not all up
for renewal at the same time.

This service has been available in .net since May 2002 and allows registrars'
customers to adjust the expiration dates of their .net domain names,
consolidating them under a calendar day (or days) of their own choosing. The
service addressed a frequent request for the capability to allow registrars to
help their customers manage renewals for sizable domain name portfolios.

ConsoliDate is implemented with the RRP SYNC command. This capability was
implemented without requiring any changes by registrars who did not choose to
implement it. Only minimal modifications were required for those registrars who
did choose to support it.

The benefits of ConsoliDate to the registrar community include:

* Increased customer satisfaction rates (via better account management, etc.)
* Increased renewal rates (reduction in lapsed/deleted domains)
* Decreased average cost of renewals (including software and hardware operating
infrastructure, mailing costs, data management, service costs, manhours, etc.) 
* New revenues (depending on implementation model)
* Protection against downward price pressure.

Should a registry operator choose not to implement this service, customers who
have already used the service will be unable to synchronize expiration dates of
any future registrations. The impact to registrars will vary, based on the
extent of changes required to their systems to accommodate removal of a service
from their portfolio.


Conclusion

VeriSign offers robust and diverse feature functionality in .net that benefits
registrars, registrants, and end users as follows:
* Support of IDNs. VeriSign has supported development of IDN standards since
November 2000. As of 31 October 2004, the .net registry contained nearly 90,000
IDN registrations representing more than 350 languages. As a bridge technology
for web browsers that are not IDN enabled, VeriSign has developed the i-Nav(tm)
plug-in as a web browser companion to enable IDN web navigation.

* IPv6. VeriSign fully supports IPv6 for the .net registry, including
registration of IPv6 name servers, resolution of AAAA records, and access to
.net name servers over native IPv6 transport.

* DNSSEC. VeriSign's experience in DNSSEC is unparalleled by any other registry.
We have been involved in DNSSEC development almost since its beginning and have
implemented several pilot programs to gain real-world operational experience.
Only VeriSign has the resources and experience to support a successful
implementation of DNSSEC in .net.

* RGP. VeriSign was the first registry to implement RGP in a solution that is
fully compliant with ICANN policy.

* IRIS. VeriSign has been a leader in the development of the IRIS standard
within the IETF's CRISP Working Group. In August 2004, VeriSign announced the
availability of an IRIS pilot service for the .com and .net registries. VeriSign
has authored multiple client and server software packages and libraries, which
are freely available and licensed under common open source terms. VeriSign
operates a website dedicated to the promotion of IRIS to solve the meta-data
problems surrounding domain names.

* ConsoliDate. Through ConsoliDate, VeriSign supports synchronizing expiration
dates of domain names. This service was implemented in response to registrar
requests to help them improve service to their customers.

It is our commitment to security and stability, coordination with industry, and
a passion to innovate that created this feature functionality.



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

VeriSign has a comprehensive system recovery solution.

VeriSign Advantage:
+ Comprehensive recovery procedures and reliable technology infrastructure
provide the ability to rapidly recover .net registration and resolution systems
from any critical event.

This section defines the following considerations for restoring registry systems
to operation:
* Procedures for restoring the system to operation in the event of a system
outage, both expected and unexpected. VeriSign has created a framework and
processes for fast and successful restoration.
* Identification of redundant/diverse systems for providing service in the event
of an outage. VeriSign has built a registry infrastructure that includes
redundancy at all levels.
* Process for recovery from various types of failures. VeriSign has detailed the
processes necessary to address failure scenarios that can occur within the system.
* Training of the technical staff that will perform these tasks. All VeriSign
technical operations staff undergoes training in system restoration procedures.
* Availability and backup of software and operating systems needed to restore
the system to operation. VeriSign maintains a change control system with
production versions of all software and operating systems used.
* Availability of the hardware needed to restore and run the system. We maintain
redundant server and network devices at each registration and resolution site.
* Backup electrical power systems. Each data center incorporates a backup
electrical power system that allows for service continuation in the event of an
electrical failure or planned shutdown of any component.
* Projected time for system restoration. We have ranked the major functions of
the registry business and identified the recovery windows for each that we have
committed to meeting.
* Procedures for testing the process of restoring the system to operation in the
event of an outage. For all components, procedures are rehearsed regularly to
ensure restoration in a timely fashion.
* Documentation kept on system outages. Any outages and incidents are captured,
and each month, we submit information on availability to ICANN.
* Potential system problems that could result in outages. We identify various
potential scenarios that could impact the availability of the registry system.


VeriSign understands that if any of the .net systems fail, impact to the
Internet community and to global commerce could be widespread. Together with the
procedures and training of our experienced staff, we provide the ability to
rapidly recover the registration and resolution systems from events that could
disrupt registry services. We have invested millions of dollars in our systems
and continually strive to provide the best registry infrastructure in the world.

To ensure business continuity, we have investigated the pros and cons of various
alternatives for both restoration methods and recovery site options. Our
solution uses a combination of many alternatives [Tables 5(b)xviii-1 and -2] to
ensure business continuity:
* Synchronous/Mirrored Replication: We deploy enterprise storage systems with
mirrored backup protection at both the primary and alternate primary data
centers. In case of site failure, the full registration data is readily
available, with zero data loss, at the alternate primary site.
* Internal Hot-Site Data Center with Full Disaster Recovery: We provide two
separate data facilities for the registration system. Either site can be active
for registration and have the capability to provide full registration services
in the event of a site failure at the other site [Figure 5(b)xviii-1].

In 2005, we will implement an improved solution for managing the registry
system. This implementation will introduce a tertiary hot-site with asynchronous
data replication and log shipping [Figure 5(b)xviii-2]. This new implementation
will accomplish the following:
* Continued synchronous replication of the registry database to the alternate
primary site. The alternate primary site is schedule to be relocated to a Tier 4
facility between 75 and 300 miles from the primary site and will maintain the
synchronous, mirrored replication of data, ensuring no data loss.
* VeriSign will install a tertiary site that is functionally equivalent to the
primary registry system and will use asynchronous data replication. To address
scenarios where multiple failures at multiple sites could result in data
corruption or loss, log shipping (copying of Oracle redo logs) ensures that the
data sets are complete before restoration of synchronous or asynchronous
replication to the alternate primary or tertiary sites, respectively.


Procedures for Restoring the System in the Event of Expected and Unexpected Outages

Expected Outages

For proper deployment and maintenance of registration and resolution
applications, operations personnel follow detailed Deployment Plans, Operations
Installation Guides, and Operations Tasks Guides. These guides are certified
through our QA process and are delivered with each code release from
Engineering. Our technical staff also maintains a searchable knowledge base that
provides essential information useful in recovery and maintenance duties.

Unexpected Outages

VeriSign has developed detailed Escalation Procedures for every aspect of the
Registry System that dictate the proper steps to follow during event management.
All steps are based on the Operations Installation Guides, and Operations Tasks
Guides certified through QA process and delivered with each code drop from
Engineering. Our library of Escalation Procedures resides in an online
searchable knowledge base on internal web-based systems. In the event of an
outage to our online searchable knowledge base, paper copies of all procedures
are stored in the NOC. These copies are indexed for rapid access to necessary
information in the event of an emergency.

SRS

Through detailed analysis of various disaster scenarios, we have designed the
system for the following situations:

* Full Failover: If the primary site data center were destroyed or rendered
unserviceable, then a full failover would be warranted. Figure 5(b)xviii-3
provides a depiction of full failover. Table 5(b)xviii-3 describes the steps
that would be taken for service restoration. Once full failover is complete, the
registrars will be notified of this condition and be provided any additional
instructions, if necessary. A full failover can be conducted in less than 30
minutes.

* Partial Failover: A partial failover is when one or more components fail over
to the alternate primary site, but a portion of the primary site remains
operational. We have identified three different partial failover scenarios. Any
of the following scenarios can be conducted in less than 30 minutes.
 - Primary Oracle HA Cluster Failure: In this scenario, only the primary Oracle
HA cluster fails, while all remaining components remain active. Steps identified
in Table 5(b)xviii-3 are taken for service restoration [Figure (b)xviii-4].
 - Primary SRS Application Server Failure: If the SRS Application Servers or SRS
Gateway Servers at the primary site fail, steps identified in Table 5(b)xviii-3
are taken for service restoration [Figure (b)xviii-5]. Operations of all other
components are unaffected in this scenario.
 - Primary Registrar Tool or Customer Service Tool Server Failure. In this
scenario, only the Registrar Tool web interfaces and/or the CSR Tool servers are
affected. Steps identified in Table 5(b)xviii-3 are taken for service
restoration [Figure (b)xviii-6]. Operations of all other components are
unaffected in this scenario.


* Tertiary Site Failover: VeriSign will implement a revised solution in 2005
introducing a tertiary hot site that will allow for restoration of the registry
system within 1 hour of event recognition. Since synchronous data replication is
not technically possible across long distances, asynchronous replication will be
used. This tertiary site provides a means of rapid recovery should a large-scale
disaster impact the primary and alternate primary locations [Figure 5(b)xviii-7].

Network Services

VeriSign's network infrastructure is redundant within each facility and across
facilities. The alternate primary site mirrors the primary site in all
aspects-equipment, topology, configuration, capacity, connectivity, etc. It
takes a minimum of 2 network-component failures to disable the network
infrastructure [Figure 5(b)xviii-8] at a facility. It would take a minimum of
four network component failures (e.g., failure of all four Internet border
routers) to disable the primary and the alternate primary facilities.

The network at the primary site [Figure 5(b)xviii-9] is designed to be modular
and easily supports upgrade, maintenance, and component additions that scale
performance, capacity, or functionality.

Under normal operations (primary site in service), each site uses separate,
non-overlapping addresses. ISP connections are preconfigured to allow the
address advertisements to move from the primary site to the alternate primary
site. Propagation of routing changes throughout the Internet takes less than 15
minutes.

The network infrastructure is designed to isolate single-point failures with no
interruption of services or degradation in performance. In most cases, isolation
of failures is automatic and occurs within a few seconds of the event. Certain
component failures (such as firewall failure) can require manual intervention to
complete the failover. Where currently manual failover mechanisms exist, we are
working with the hardware and software vendors to develop products that support
automated failover.

Resolution Systems

VeriSign's DNS, both in architecture and protocol, is inherently tolerant of
failures. Each of our name server locations is advertised from its own Class C
address space. This allows our network technicians to make a Border Gateway
Protocol (BGP) announcement and quickly "move" a remote location to one of the
three available standby DNS sites. This capability is used extensively for
maintenance activities and allows us to provide access to the service even
though it has been "logically" moved to a new location. This capability is also
extremely useful in ensuring continued operation should a third-party vendor be
unable to provide service (as was the case with a major European ISP
approximately 3 years ago).


Redundant/Diverse Systems for Providing Service in the Event of an Outage

VeriSign has built an infrastructure that includes redundancy at all levels:
networking, databases, storage, and applications, as well as redundant facility
elements. Additionally, most service outages are mitigated through automated
methods, such as failover to redundant systems or through load balancing. Larger
events can require direct failover to an alternate primary network, system,
database, and/or environment.

* SRS: Not only are systems at our primary and alternate primary site able to
assume full operations due to built-in redundancy, but also each facility can
also assume partial operations. This partial operations model provides a
recovery option that is faster than full site failover, and therefore,
contributes to our ability to deliver reliable and stable service.

* Resolution: VeriSign has built a constellation of sites for the resolution of
.net. The constellation consists of 14 worldwide sites [Table 5(b)xviii-4] that
manage the query volume of both .net and .com. Each site is located at a major
telecommunications peering point in which various large ISPs have established
hubs for management of their portion of the Internet backbone. Each site of the
constellation has a minimum of 1 gigabit of burstable bandwidth from a minimum
of two high-speed connections to the Internet, each provisioned through a unique
ISP. Additionally, we have deployed multiple high-speed servers to support
capacity and availability demands that, in conjunction with our suite of
recovery software, offer automatic failover, load balancing, and threshold
monitoring of critical servers.


Process for Recovery from Various Types of Failures

VeriSign has spent extensive time and effort conducting failure mode analyses on
every registry component. Figure 5(b)xviii-5 shows general types of failures
that could be expected for the registry and the procedures used to recover from
them. Sophisticated hardware and software automatically handle the majority of
these failures. This is only a subset of all types of failures that have been
identified through our failure mode analyses. Our Business Continuity Plan
details the processes necessary to address failure scenarios that can occur
within the registry system. 

Training of the Technical Staff That Will Perform These Tasks

All technical operations staff undergoes training in system restoration
procedures. This training takes the form of system outage scenarios, automated
and manual responses, documentation on hardware outages and restorations, and
documentation of indications of potential problems requiring maintenance
actions. Additionally, personnel receive training on all vendor software and
operating systems used in the registration and resolution system.


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

Installations of application software and operating systems are based on
standard builds developed by our Infrastructure Engineering (IE) and Product
Development teams. Vendor software, built and installed in our production
environment, is performed in compliance with internally developed procedures and
standards. The production version of all vendor software and operating systems
used are kept on change-controlled servers. Operating systems are also
standardized and tuned by our IE team and are available on change controlled
build servers as well. These build servers are routinely audited and maintained
to ensure that the most current certified build is available as well as builds
for all legacy systems in production.

All application software developed by VeriSign is checked into our Configuration
Management System. This software is installed and configured in accordance with
the Installation and Operations Tasks Guides certified by QA. For further
preservation, the registry database software and configurations are backed up to
tape each day.


Availability of the Hardware Needed to Restore and Run the System

VeriSign maintains redundant server and network devices at each registration and
resolution site. Many of these servers are load balanced, so that a failure of
one will result in the remaining servers assuming the load. We maintain a ready
supply of spare servers for our network, application, and protocol devices. We
have put rapid-response maintenance contracts in place with all the hardware
vendors of the larger servers, such as the databases and storage systems,
ensuring response within up to 4 hours. We also maintain direct technical
relationships with our major vendors to address any concerns that might be
discovered by our engineers.


Backup Electrical Power Systems

Each data center incorporates a backup electrical power system that allows for
service continuation in the event of an electrical failure or planned shutdown
of any component. Since most high-end IT equipment today is outfitted with
dual-electrical connections and dual-power supplies, each component of the
electrical infrastructure, from the street to the CPU, is, and will continue to
be, fully redundant. Redundancy also supports scheduled maintenance. The
electrical infrastructure is designed to continue to provide service in the
event of a failure or planned shutdown of any component. Details of the
electrical power systems at VeriSign facilities are provided in Section 5(b)i,
Facilities and Systems.


Projected Time for Restoration System

Table 5(b)xviii-5 provides a description of the priorities for restoring major
registry functions and VeriSign's commitment to recovery timeframes.


Procedures for Testing the Process of Restoring the System to Operation in the
Event of an Outage

For all components of the registry system, procedures for restoring system
operations are rehearsed regularly to ensure restoration in a timely fashion. We
periodically test failure scenarios and the procedures for restoration. We
maintain an operations staging environment that provides the opportunity to
practice database and system recovery, without impacting production operations.
We also take the opportunity, during production maintenance periods, to test
high-availability database failovers. Finally, fire drills are conducted at the
alternate primary site on a periodic basis - and not always during normal
business hours. These drills are timed and response times are tracked.


Documentation Kept on System Outages

System outages for the registry are determined by information contained in
network logs, application logs, monitoring event logs, and the shift logs of NOC
staff. Any outages and incidents are captured by the NOC in an incident
reporting system. Each business day, the VeriSign NOC and Operations staff
review system outages and other incidents that could affect system performance.
Each month, we submit information on availability to ICANN, which is publicly
available at http://www.icann.org.


Potential System Problems That Could Result in System Outages

Some primary events that can occur to services are:

* A DDoS attack could easily affect both the primary and alternate primary site.
Steps in recovery vary from identifying the source of the attack to notifying
appropriate authorities.

* Security Breach: Recovery from security breaches is straightforward, but is
often consuming, and potentially disruptive to the services hosted on the
affected systems. Certain security breaches can disable a service for the
duration of the recovery and cleanup activities. Proper steps can result in
restoration of security and system service.

* Data Corruption: In the event of data corruption at both the primary and
alternate primary sites, data will be restored either from online disk backups
or onsite tape backups, or offsite tape backups.


Conclusion

VeriSign ensures its recovery procedures for rapid recovery in critical events
through:
* Established, robust recovery procedures: Promotes quick problem resolution and
root cause analysis to continually improve processes and operations.
* Extensive infrastructure investment providing redundant hardware and software:
Minimizes risk of servicewide failure and isolates impact of any component or
device failure so that overall system availability and operation are not
affected by cascading failures.
* Geographically dispersed resolution sites and NOC: Isolates impact of local
service interruption caused by catastrophic events in an area to maintain
service continuity.



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

Delivering world class technical support is the result of experienced and
trained staff and a commitment to respecting a customer. The point of contact
for support says everything about a company - it can even be considered by the
customer to be the heart of the business. Securing the right technical/customer
support organization to service .net registrars is critical. Amid elevated
stakes for domain names registrants, registrars must be able to rely on
registries. VeriSign provides our customers with technical and other support
services that provide stable and scalable systems, streamlined processes,
highly-trained and knowledgeable service staff, resulting in the speedy
resolution of a registrar's service issues.

VeriSign advantage:
+ VeriSign's commitment and investment in world-class facilities and services
have been essential to delivering reliable support services to registrars,
Internet users, and registrants.

This section describes VeriSign's commitment to providing high quality technical
and other support capabilities to all constituents, including:
* Technical help systems, personnel accessibility, web-based, telephone, and
other support services. VeriSign provides world-class online help services using
the worldwide web, email, and by telephone. We provide outreach services to
registrar and registrants to educate them about products and services before
they launch to better serve their needs.
* Time availability of support and language-availability of support. VeriSign's
support staff is reachable by telephone and email every day, all the time. Many
members of our support team are multi-lingual. We provide real-time translation
services using the AT&T Language Line for languages not spoken by our staff.
* Ability to support new and emerging technologies. Our support team regularly
surveys customers to ensure that our methods and practices meet their needs as
they build new and innovative systems. We perform ongoing reviews to ensure that
our own systems use the most effective, up-to-date solutions. We train our
support staff in the use of new tools and technologies. VeriSign's ATLAS
platform provides protocol-agnostic features that allow us to deploy new systems
using existing technology, reducing the need for support training on new systems.


Technical Help Systems

VeriSign provides comprehensive, leading-edge technical help systems. Our
customers benefit from the following systems:

Knowledgebase. Registrars, Internet users, and registrants are able to search a
database of solutions online at their convenience. This knowledgebase is
maintained to provide accurate, thorough support for .net registrars.

Customer Relationship Management (CRM) System. Advanced, commercial grade CRM
software tracks all customer contacts and registrar incidents. The CRM solution
provides registrars with the following capabilities:

* Access support through multiple access channels (i.e., telephone, email,
website, knowledgebase, online information, and publications)
* Access an online database of solutions to various issues
* Submit service requests online at their convenience via the VeriSign website
* Monitor and track online, real-time progress on their service request as well
as review historical service requests
* Provide real-time feedback on the service and timeliness of response to their
service request

The CRM solution provides support and technical support teams with the ability
to conduct the following functions:

* Organize customer contact information
* Organize company information
* Organize/maintain customer contracts
* Capture registrar problem data
* Respond quickly to customer inquiries
* Categorize requests by access method (email/telephone)
* Create case types (e.g., billing problem, technical problem, etc.)
* Dispatch customer requests to other departments for tier 2, 3, and 4 support
* Assign a level of priority to each customer request
* Provide real-time status/update on service requests
* Create a database of solutions to various issues
* Generate detail and summary operational reports

When a service request is submitted (whether by registrar online or by VeriSign
support professionals), a service request number is automatically assigned and
provided to the registrar, which enables them to monitor and track resolution
progress and timeliness online. For issues requiring technical expertise and/or
product management specific assistance, which are beyond what the Customer
Service Center (CSC) can provide, service requests are dispatched to Tier 2, 3,
or 4 support teams who use the same CRM system. This includes: our NOC, systems
administrators, database administrators, networking support, software engineers,
QA engineers, and product/business management teams. Once the registrar's
problem is resolved, the service request is closed. The registrar then has the
opportunity to provide feedback via an online survey regarding the service and
timeliness of response.

Daily operational reports are generated showing the status and duration of all
open issues, with the support team who is currently working the service
requests. The system provides a permanent audit trail of actions and statuses
that can be accessed in real-time by registry business, technical, and customer
service staff. The overall service metrics described in Table 5(b)xix-1 are
monitored to ensure customers receive world-class service. Effective Q2 2005,
CSC will have the ability to measure first contact resolution.

Registrar Client. VeriSign provides registrars with a web-based management tool
that allows registrars to be self-sufficient for many domain name or name server
issue. The features of this tool include:

* Domain name maintenance: modify, delete, renew, transfer
* Name server maintenance: create, modify, delete
* Registrar account maintenance: add/delete contacts, check account balance.


Personnel Accessibility
The VeriSign in-house 24x7x365 CSC can instantly escalate technical issues to
the appropriate resource if an issue cannot be immediately resolved.

VeriSign strives for a continuous improvement in this process and has
implemented a series of feedback mechanisms to assist in identifying areas for
improvement. Feedback is sought from registrars on an ongoing basis, as well as
through a more formal annual survey. The survey measures overall registrar
satisfaction and is administered online. VeriSign customer service has
maintained at least an 8 rating for overall satisfaction on a scale of 10 (with
8 being defined as world-class service) since the survey started in 2000. In
addition, VeriSign is currently the only registry that conducts annual
third-party audits of internal controls and customer service methods to certify
that registrars gain equal access to VeriSign regardless of size or volume.


Web-based Support

VeriSign offers access to a website that provides important information and
tools for registrars, which is accessible through a user identification (ID) and
password assigned by the CSC as part of the certification process. Through this
secured access, registrars have tools that provide access to the registry
database, enabling registrars to perform account updates, domain name, and name
server maintenance. As requested by the registrars, the customer support team is
able to access the registrar's account and update the same functions, as
directed. VeriSign finance staff is also able to add or transfer funds within
the registrar accounts through these same tools. Processes are in place to audit
and log all modifications.

The following list covers the types of material available to the registrars on
the VeriSign website:

* How to Become a Registrar. Step-by-step process informing potential registrars
of all requirements, including online forms and agreements that can be easily
downloaded for quick execution.
* Registrar Reference Manual. A one-source reference manual that covers various
registry-registrar protocol usages and miscellaneous registry functions related
to second-level .net domain names.
* Registrar Tool User Guide. Provides registrars specific information about
transactions with the registry, including domain name administration, name
server administration, registrar administration, and reports.
* Software Developer Kits (SDKs). Registrars have online access to SDKs in C and
JAVA that assist them with technical integration and certification to the .net
registry. SDKs contain the source code required to perform RRP and EPP commands.
Customer service is available 24x7x365 to assist registrars who have difficulty
downloading SDKs. The SDKs available online include: EPP software development
kits, IDN software development kits, EPP example instance and schema files, and
RRP software development kits.
* Registrar Reference Manual. A nontechnical guide to using EPP and
understanding the business rules applicable to domain and name server registrations
* OT&E Acceptance Criteria.
* Contains the tests cases required to be certified as a registrar
* OT&E environment allows registrars to test their system before taking the
formal exam.
* Registrar Listing and Contact Information. Lists all registrars and their
contact information to facilitate ease of communication
* Performance Measurements. Online charts that display registry operational metrics
* Registrar Mailing List. This list is an opt-in service that provides a forum
for registrars and VeriSign to discuss issues related to registry/registrar
operations
* Registrars Email List Archives. A repository of all emails sent to the
registrars mailing list.
* Frequently Asked Questions (FAQs). Lists the most popular questions and
answers received across a wide range of topics, including ramp-up process, OT&E
processes, production environment, domain status, transfers, Whois, billing,
general support inquiries, etc.
* Calendar of Scheduled Maintenances. Lists upcoming maintenance services to be
performed over the next 60 days.
* News Bulletins and Archives of all Registrar Communications/Advisories:
 - These announcements focus on customer feedback, bugs, changes in policy, etc.
 - History of all communications with registrars.
 - Links to Registrar Tool: Direct link to the web-based Registrar Tool
(described below).


Telephone Support

Registrars have the ability to contact VeriSign customer/technical support by
telephone any 24x7x365. VeriSign uses standard telephone technology, including
automatic call distribution, voice mail, and paging. Phone calls are routed to
the most appropriate support professional for immediate assistance. Phone
service is measured and key metrics are tracked to ensure world-class service.
This year, registrars continued to rank customer service with high marks in
phone support. On a scale of 10 with 8 identified as "world-class" service, our
support team received the following rankings for telephone support:

Time to reach customer service rep:	8.41
Courtesy and professionalism of customer service rep:	8.67


Other Support

Other support available to registrars includes the following:

Email Support. Registrars have the ability to contact VeriSign
customer/technical support by email 24x7x365. Customers can either send an email
directly to our support email address or can opt to use the web-based service
requests system. Either way, all customer emails are immediately received by the
customer/technical support teams. As with phone calls, emails are routed to the
most appropriate support professional for immediate assistance. As in previous
customer surveys, registrars continue to provide customer service with high
marks for email support. On a scale of 10 with 8 being identified as
"world-class" service, our support team received the following rankings for
email support:

Timely response to request:	8.6
Quality of query resolution:	8.0


Industry Events/Conferences. VeriSign actively participates in many other
industry events, such as ICANN meetings, DNSSEC consortium meetings, IBC
Euroforum's ISP conferences, IDN workshops, and the Registry constituency meetings.

Seminar/Webinar Presentations. VeriSign hosts events that bring together
industry leaders and influencers, both technical and business, in an open forum
to discuss the future of the Internet for a specific regions and the world.
Events occur annually in the U.S., Europe, Asia, and South America.
Additionally, VeriSign periodically hosts Webinars to registrars to facilitate
communication about upcoming launches of ICANN consensus policies (i.e.,
transfer dispute resolution policy), share results of market research, and
announce special marketing programs available to all registrars. Multiple
Webinar sessions are offered to accommodate our customer's geographic location
and time zones.

Marketing Tools for Registrars. VeriSign has developed marketing tools to help
registrars and resellers improve renewals and increase domain name sales. Use of
these tools is entirely optional. All tools and information can be made
available by registrars to resellers. Tools include:

* .net Logos for Registrar Website. A .net logo that easily notifies consumers
that .net domain names are available for registration on registrar websites.
* Online Banner Ads. Online information available to registrars that includes:
"Suggestions for Banner Placements," "Directions for Downloading Banners," and
"Internationalized Domain Name Banners," which are available in English,
Japanese, Korean, Simplified Chinese, and Traditional Chinese.
* Domain Name Renewal Tools:
 - Best Practices Guide for Domain Name Renewals. A guide that provides
recommendations for registrars toward building a comprehensive and effective
renewal program, or increasing the effectiveness of current renewal programs. It
includes tips for renewal programs and recommended schedule for addressing renewals.
 - Sample Renewal Messages. VeriSign has prepared a set of email templates (HTML
and TXT) for registrar's use in renewal campaigns. In addition, we offer
prepared IDN-specific messaging that highlights the value proposition for IDNs
as related to renewals. These templates are available in English, Simplified
Chinese, and Korean.
 - Marketing Reports on Expiring Names. VeriSign generates reports for
registrars that provide a list of domain names due to expire within 30, 60, and
90 days.
* Retail Demo Tools. VeriSign has developed these tools and resources to help
registrars integrate new products and services with existing order flows.
* TLD Zone Files. VeriSign maintain files that contain data describing a portion
of the domain name space for specific TLDs.
* Newsletters. VeriSign publishes a monthly industry newsletter available to all
registrars on an opt-in free subscription basis. Its primary audience is
ICANN-accredited registrars and selected domain name industry professionals.

Time Availability of Support

VeriSign staffs the CSC 24x7x365 to handle the variety of registrar issues that
can surface in support of day-to-day operations, thereby enabling support to
registrars in their own time zones. These issues normally focus on connectivity
problems, registration problems, reporting problems, domain name or name server
maintenance, and billing issues. Onsite coverage allows the support team to
escalate issues immediately to either business or technical teams on behalf of
the registrars. Onsite support also assists with internal company escalations.
If any issues require communication with the registrars, the CSC can communicate
the problem to the registrars and handle questions or concerns from the customer
base. Refer to Figure 5(b)xix-1 for VeriSign's support and escalation process.


Language Availability of Support

The CSC is capable of providing assistance in English, Spanish, German, and
Farsi. In addition to using multilingual support staff, VeriSign users a
real-time translation service, AT&T Language Line, to assist with telephone and
document translation needs. AT&T Language Line is a 24x7x365 operation that
offers instant access to interpreters versed in more than 150 languages, which
represent 98 percent of all language needs. If a registrar is having a problem,
the CSC can instantly initiate a conference call to an interpreter and collect
information regarding the registrar's problem. The features and benefits of this
service are described in Table 5(b)xix-2.

Occasionally, foreign language emails are received at the CSC. If the language
is not covered by the multilingual CSC support staff, an online translation tool
is used to interpret the email. Telephone calls remain the primary use for AT&T
Language Line.


Geographic and Time Coverage of Services Offered

VeriSign supports a global network of registrars with diverse technical and
linguistic capabilities. In an effort to provide the best possible support to
all registrars, VeriSign has implemented a variety of tools and policies to
support registrars wherever they might be located. We have recently opened
additional offices in Asia to supplement current support available from offices
in Europe, North America, and South America.


Ability to Support New and Emerging Technologies

VeriSign will continue to encourage customers and the Internet community to
build solutions, using new and emerging technologies. Customer/technical support
teams recently upgraded support tools to a leading-edge customer relationship
management solution. We will continue to leverage this application and its
future enhancements to continue to provide world-class service to our customers.
We will continue to survey our customers regarding their support needs and
deploy appropriate technologies and solutions that deliver desired solutions.


Recently, VeriSign was selected as a Top 100 Innovator by Red Herring. This
prestigious award recognized our development of the ATLAS, a sophisticated
software platform designed to scale the Internet's core infrastructure, the DNS,
and support the convergence of voice and data networks. ATLAS is a protocol
agnostic convergence platform designed to connect any network, whether data or
voice-based. It has been built with future growth in mind in that it isn't just
a bigger "box," but has intelligence built into it to allow for the system to
scale to more than 400 billion queries per day and 24,000 updates per second.
Additionally, ATLAS is incredibly reliable, with 100 percent data integrity and
service availability, since the service was launched in 2002. Because ATLAS is a
technology neutral convergence platform that can connect to any network, it is
able to support new protocols, facilitating the implementation of new services.


Conclusion

VeriSign is committed to continue offering a high quality technical and customer
service support. Our well-regarded system is proven effective and efficient. We
are prepared to continue providing this support throughout the next term of a
.net Agreement and for all newly emerging technologies.


   

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.

VeriSign has never experienced a complete registry operational failure. In the
highly unlikely of a complete operational failure, VeriSign has a business
continuity and fail-safe backup plan that ensures continuity of operations.

VeriSign Advantages
+ 100 percent uptime DNS resolution performance for more than 7 years
+ Demonstrated ability to withstand significant DDoS attacks and pernicious viruses
+ A multi-threaded approach to risk management with proactive and reactive
measures to address threats
+ The financial ability to sustain and invest in registry operations in all
market conditions.

We design our systems to include massive over-provisioning in advance of
operational threats. The name resolution systems are deployed in multiple
continents and countries with multiple network service providers and completely
redundant, parallel operation of each facility. Our name update systems are
deployed in active alternative primary and tertiary facilities with automated
failover in case of failure at our primary facilities. We additionally work with
a backup operator to provide services in the unlikely event that all our systems
in all our locations are rendered inoperable. Finally, we have made arrangements
with a partner to transition .net in the extraordinarily unlikely event that all
of our systems and those of our backup operator are disabled.

Shared Registration System Failover Provisions
VeriSign has constructed its .net registry to address various disaster scenarios
that can impact service, and associated three different levels of severity with
each of the disaster scenarios: full site failover, partial site failover, and
tertiary site failover. Several figures describing our procedures are provided
in Section 5(b)xviii, System Recovery Procedures.

Full Site Failover: There are many types of failures that would result in a full
failover from the primary site to the alternate primary site. Examples include a
fiber cut between registrars or a severe natural disaster (flood, tornado, and
earthquake) destroying or rendering unserviceable the primary site data center.
Figure 5(b)xviii-3 provides a depiction of full failover for VeriSign's Shared
Registration System (SRS) implementation.

VeriSign has constructed a fully functional disaster recovery site at our
alternate primary data center. In accordance with our Business Continuity Plan,
the following steps would be taken in the event that a full failover is required:

1) Synchronous replication between the primary site and the alternate primary
site would be suspended.
2) Configuration of the Oracle high availability (HA) cluster at the alternate
primary site as primary.
3) Startup of the alternate primary site processes.
4) A DNS change of the primary virtual Internet Protocol (IP) (VIP) addresses
for Registrar connectivity to point to the alternate primary site.

Once full failover is complete, registrars will be notified of this situation
and will be provided additional instructions, as necessary. A full failover from
the primary site to the alternate primary site can be conducted in less than 30
minutes.

Partial Site Failover: Certain types of failures can occur that will be
considered a disaster, but will not require a full failover to the alternate
primary site. An example of this type of disaster would be some sort of primary
site Oracle HA cluster failure. The servers themselves could be physically
destroyed, or the power supply to the cluster could be interrupted indefinitely.
Whatever the reason for the failure, a partial failover to the alternate primary
site will be required.

A partial failover is when one or more components failover to the alternate
primary site, but a portion of the primary sight remains operational. Three
different partial failover processes are described in this section: Primary
Oracle HA Cluster Failure, Primary SRS Application Server Failure, and Primary
CSR and/or Registrar Tool Server Failure.

Primary Oracle HA Cluster Failure: In this scenario, only the primary Oracle HA
cluster fails, while all the remaining components remain active. A partial
failover for this type of failure is almost identical in process to the full
failover process identified previously in Figure 5(b)xviii-4. In this situation,
the following steps would be taken:

1) Synchronous replication between the primary site and the alternate primary
site would be suspended.
2) Configuration of the Oracle HA cluster at the alternate primary site as primary.
3) Pointing of application server components at the primary site to the Oracle
HA cluster at the alternate primary site.
4) Pointing of CSR and registrar tool components at the primary site to the
Oracle HA cluster at the alternate primary site.

In this situation, a DNS change would not be required. A partial failover of
this type, when the primary Oracle HA cluster fails, can be conducted in less
than 30 minutes.

Primary SRS Application Server Failure: If the SRS Application Servers or SRS
Gateway Servers at the primary fail, then a much more isolated failover will
take place, as depicted in Figure 5(b)xviii-5. In this scenario, the SRS service
is effectively down because the primary cluster of SRS Application Servers
provides the only SRS interface. In this situation, the following steps would be
taken:

1) Pointing of application server components at the alternate primary site to
the Oracle HA Cluster at the primary site
2) Startup of the alternate primary site
3) Changing DNS for registrar connectivity to point to the alternate primary VIP.

A partial failover of this type can be conducted in less than 30 minutes. In
this type of failover, all other components continue to run unaffected. The CSR
and registrar tools continue to access the primary database without interruption.

Primary CSR and/or Registrar Tool Server Failure: If a primary site CSR or
registrar tool failure occurs, then a much more isolated failover will take
place, much like the failover described above for the primary SRS Application
failure. In this scenario, only the registrar tool web interfaces and/or the CSR
tool servers are affected directly. To restore these tools, the alternate
primary CSR and/or registrar tool web interface servers will need to be
reconfigured to communicate directly with the primary site Oracle HA cluster, as
shown in Figure 5(b)xviii-6. In this type of failover, all other components
continue to run unaffected. A partial failover of this type can be conducted in
less than 30 minutes.

Tertiary Site Failover: VeriSign is activating a tertiary hot site to provide
service in the event that both the primary site and alternate primary site fail.
As depicted in Figure 5(b)xviii-7, the tertiary hot site will allow for
restoration of the .net registry system within 1 hour of event recognition. Many
of the steps required for a tertiary site failover are similar to that of a full
failover, except that synchronous data replication is not technically possible
across long distances. As such, asynchronous replication (approximately one
database write behind real-time) is required. While this approach increases the
likelihood of minor data loss, this tertiary site provides a means of rapid
recovery should a large-scale disaster impact the primary and alternate primary
locations. As with all the other failover scenarios, once completed, the
registrars will be notified of this situation and will be provided additional
instructions, as necessary.

Network Services Failover Provisions
The .net registry's network infrastructure is redundant within each facility and
across facilities. It takes a minimum of two network-component failures to
disable the network infrastructure (Figure 5(b)xviii-8) at a facility. It would
take a minimum of four network component failures (for example, failure of all
four Internet border routers) to disable the primary and alternate primary
facilities.

The network at the .net registry's primary site (Figure 5(b)xv-1) is designed to
be modular and easily supports upgrade, maintenance, and component additions
that scale performance, capacity, or functionality. Security domains are created
and enforced by access control and authentication mechanisms that separate
exposed services (for example, name and mail servers, Whois) from restricted
services (for example, registry-registrar protocol [RRP]) and protected services
(for example, the back-end database).

The alternate primary site mirrors the primary site in all aspects: equipment,
topology, configuration, capacity, connectivity, etc. The network at each site
is sized to accommodate all services at their expected use, while exceeding
performance goals. Capacity planning ensures upgrades are made (at both primary
and alternate primary sites) before having performance issues.

Under normal operations (primary site in service), each site uses separate,
non-overlapping addresses. If a service interruption occurs at the primary site,
those services that are provided at well known addresses (such as
a.root-servers.net and rs.internic.net) are resumed at the alternate primary
site using the same addresses. Internet service provider (ISP) connections are
preconfigured to allow the address advertisements to move from the primary site
to the alternate primary site. Propagation of routing changes throughout the
Internet takes less than 15 minutes.

The network infrastructure is designed to isolate single-point failures with no
interruption of services or degradation in performance. In most cases, isolation
of failures is automatic and occurs within a few seconds of the event. Certain
component failures (such as firewall failure) can require manual intervention to
complete the failover. Where currently manual failover mechanisms exist,
VeriSign is working with the hardware and software vendors to develop products
that support automated failover, resulting in shorter service disruptions and
higher overall availability.

Resolution Systems Failover Provisions
VeriSign's DNS implementation is inherently tolerant of failures both in
architecture and protocol. As described in Section 5(b)xvi, System Outage
Prevention, each of our gTLD locations are advertised from their own Class C
address space. This allows our network technicians to make a border gateway
protocol (BGP) announcement and quickly "move" a remote location (e.g., London)
to one of the three available standby sites. This capability is used extensively
for maintenance activities and allows us to provide access to the service even
though it has been "logically" moved to a new location. This capability is also
extremely useful in ensuring continued operation should a third-party vendor be
unable to provide service (as was the case with a major European ISP
approximately 3 years ago).

Additional resolution sites can be implemented with the use of anycast
technology to bring resolution services closer to important Internet locations.
For more information on anycast technology and the addition of resolution sites,
refer to Part 2, Section 5(b)i, Proposed Facilities and Systems.

Whois Failover Provisions
Fully redundant Whois daemon and dumper services are installed at both the
primary and alternate primary sites for the .net registry system. If the Whois
dumper box or database becomes unavailable at the primary site, the Whois dumper
service is failed over to the alternate primary site. The Whois dumper process
on the alternate primary site is configured to run in production mode. It then
generates the Whois database, validates it, and replicates it to the primary
Whois daemon servers on the primary site. If the Whois daemon system becomes
unavailable at the primary site, the Whois daemon service is failed over to the
alternate primary site. The Whois dumper process on the primary site will
continue to generate the Whois database, validate it, and replicate it to the
alternate primary Whois daemon servers on the alternate primary site.

Table 5(b)xviii-5 provides a breakdown of recovery rank of the major functions
of the .net registry business, and the recovery windows for each that VeriSign
has committed to meeting.

Procedures for Testing the Process of Restoring the System to Operation in the
Event of an Outage

VeriSign maintains detailed procedures for testing processes before restoration
in our Business Continuity Plan. These procedures are rehearsed regularly to
ensure restoration in a timely fashion. These rehearsals are instrumental in
reducing outage time and providing experiences that are beneficial for unplanned
outages.

VeriSign also takes the opportunity during production maintenance periods to
test high-availability database failovers. These procedures introduce scenarios
that cause the .net production database to fail over and help confirm that the
actual production databases and application servers can definitely recover in
minimal time. With the ability for each registration site to maintain full or
partial operations, we can test procedures for site failover during normal
maintenance periods, without the introduction of system outages.

Finally, fire drills are conducted at the alternate primary site on a periodic
basis, and not always during normal business hours. These drills are timed, and
response times are tracked. Only a select group of personnel is involved in the
determination of the time a drill is to be initiated. However, once the drill
begins, all individuals contacted through the escalation chain are notified that
a drill is in progress. Although this might appear to impact the overall
performance and urgency of the team to conduct the drill, it is essential to
ensure that no production services are impacted while the drill is underway.

In the highly unlikely event that all of VeriSign's registry systems become
completely unavailable, the registry will implement a third-party disaster
recovery plan with SunGard Availability Services. The plan includes steps to:

1) Release escrowed data to use in startup
2) Dispatch VeriSign staff to SunGard to assist in startup operations
3) Assist SunGard with the launch of temporary .net operations using their equipment
4) Manage temporary SRS and resolution through SunGard
5) Assist in management and transition back to VeriSign.
 	
SunGard Availability Services is the unparalleled leader in comprehensive
business recovery, providing dependable and cost-effective continuity solutions.
SunGard's recovery facilities total more than 3 million square feet of recovery
operations work space, and offer state-of-the-art recovery configurations,
testing facilities, network services, Internet hosting, high availability
vaulting options, and extensive work group recovery services.

VeriSign will allocate employees to assist in bringing the temporary system
online, managing it through the required timeframe, and transitioning the
systems back to VeriSign. If VeriSign and all its systems are unavailable, and
the backup provider is unavailable, VeriSign will work with ICANN to transition
registry services to the registry operator who ICANN deems is the most capable
of providing the service.

Documentation Kept on System Outages	
VeriSign uses information contained in network logs, application logs,
monitoring event logs, and the shift logs of VeriSign's 24x7x365 Network
Operations Center (NOC) staff to capture outage information. Outages and
incidents are noted by the NOC in an incident reporting system. Each business
day, the VeriSign NOC and Operations staff review system outages and other
incidents that could affect system performance. The daily meeting is used as a
forum for root cause resolution and methods of preventive action. The
information is used to improve processes and is fed back to engineering staff
for updates in hardware or software. VeriSign submits outage information to
ICANN each month, publicly available at http://www.icann.org.

Conclusion
VeriSign has taken extensive measures to ensure continuity of operations in the
event of operational failure of the registry. VeriSign's systems have provided 7
years of 100-percent uptime resolution performance. We have deployed massively
over-provisioned systems with primary, alternative primary, and tertiary service
sites. We have contingency plans in place to bring those sites online as needed.
 In the highly unlikely event of a failure of all our backup systems, we have
made arrangements with SunGard to provide third-party backup services.

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

VeriSign is a stable, publicly traded company resistant to changes in registry
market conditions that can cause financial nonviability. As such, VeriSign
provides ICANN with a great deal of transparency into our financial health. In
the highly unlikely event of VeriSign's business failure, we will ensure a
quick, smooth, and efficient transfer of registry functions to a successor
operator, minimizing disruption of the registry functions.

VeriSign Advantages
+ Corporate commitment to registry operations and financial ability to sustain
and invest in the registry during all market conditions
+ Business diversity that provides low risk of business failure
+ Full disclosure of public financials to give ICANN consistent insight into
VeriSign's financial health.

As .net is the top-level domain (TLD) of choice for the leading providers of
Internet services, such as Internet Service Providers (ISPs), the ability to
continue to fund investment and drive new capabilities should be a key
consideration. Service providers depend on the registry operator of .net to
continue to deliver service enhancements designed to keep pace with growing
market demand for new applications.


It is highly improbable that VeriSign's business will fail; VeriSign has $1.2
billion in revenue with over $600 million in cash reserves and is a financially
stable publicly traded company. The company has a broad business base and is
able to withstand any changes in domain name sales, unlike other registry
operators that lack income diversity. For example, during the market fall in
2001-2002 when domain name sales plummeted, VeriSign continued to invest in the
registry platform and introduced new product capabilities, for example, the
development of Advanced Transaction Lookup and Signaling (ATLAS) and the
introduction of internationalized domain names (IDNs), to ensure that the .net
registry was prepared for future growth. VeriSign's diverse business portfolio
provides this stability. The most significant step taken by VeriSign to prevent
registry business failure has been to build a company that is not solely
dependent on registry income to guarantee financial viability.

VeriSign continues to invest heavily in new capabilities designed to bring
improvements to users of the .net domain. Investments in infrastructure and
offices in key locations, such as Korea and China, mean that users in those
locations gain the benefit of faster resolution performance. A company solely
dependent on revenue from registry operations alone will find it challenging to
make the significant (capital and expense) investments required in scalable and
fully redundant infrastructure, a diverse geographic footprint, or the range of
new capabilities, such as Internet Protocol Version 6 (IPv6) and domain name
system security extensions (DNSSEC) that will require future investment.

Unlike VeriSign, many operators in the industry are struggling financially. Many
have had to scale back on operational staff and reduce investment to the bare
minimum to continue operations (refer to original proposals for demand and
monthly operating reports for examples of demand disparities). As a result,
these companies are unable to deliver feature or network functionality
enhancements promised to, and expected by, the market. Often, their
subcontractors are in a similarly difficult financial position. VeriSign does
not outsource any component of the .net registry operation, so there is no risk
of failure due to insolvency of any subcontractor. VeriSign multi-sources key
procurements, such as bandwidth and hardware, to ensure no dependency on any one
vendor or supplier.

As the domain name business is a key component of VeriSign's corporate strategy,
VeriSign is fully committed to growing this business and domain name industry as
a whole. VeriSign is committed to provide ICANN with the requisite information
on the company's financial health. There are two measures, proactive and
reactive, that VeriSign proposes to address business failure:
* Provide ICANN with financial updates on all publicly available information
* Provide a comprehensive transition plan to a temporary registry operator.

Because VeriSign is a U.S. publicly-traded company, we have quarterly reporting
requirements and generally accepted guidelines for providing adequate data to
assess financial fitness. All registry operators should be required to disclose
this level of data to ensure proper time is available to assess the potential
for a business failure. This type of data offers some comfort that companies are
accurately and appropriately accounting for company financials.

ICANN can be ensured of VeriSign's financial fitness as a U.S. publicly-traded
company, that we are appropriately accounting for our financials, and that they
have sufficient information to forecast liquidity and financial stability into
the future. To facilitate this process, VeriSign will provide ICANN with copies
of all public filings within 10 days of their published date. Additionally,
VeriSign will notify the ICANN Registry Liaison of open analyst calls so they
have the same level of insight as financial investors.

In the highly unlikely event of business failure, VeriSign will work with ICANN
to provide registry data and software needed to transition registry operations
to an operator designated by ICANN. The following items will be provided to
ICANN's designated successor operator:

* Snapshot complete data early in the transition schedule to allow the new
operator to populate a .net database of his own for development and test
purposes. Specific data field formats will be defined by VeriSign; exchange
format and delivery means will be defined by the new operator and confirmed by
VeriSign.
* Snapshot data of .net registrar contact information current as of the time of
the data dump.
* Complete documentation for all registrar support processes and procedures.
* Complete source code and documentation for all registry software systems.
* Complete design and architecture documentation for all registry hardware systems.
* Complete records of registrar customer service activity.
* Complete records of registrar financial support activity.
* Complete records of historic domain transaction activity.
* Second set of complete data dumps when the new operator is ready to begin
operations.
* Continued operation of DNS and Whois service up to, and during, the transition
until these functions can be provided by the new operator.

VeriSign will use the DNS zone transition mechanism developed for the .org
transition to receive data from the new operator during the period that they
require use of our gTLD constellation for DNS resolution.

In the highly unlikely event of VeriSign's business failure, this plan can be
quickly executed and will ensure a quick, smooth, and efficient transfer of
registry functions to a successor operator.

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

Promoting competition in the registration of domain names

As registry operator for the .net TLD, VeriSign has vigorously taken concrete
and significant steps to promote competition and will continue to do so if
awarded the follow-on contract. Over the last 7 years, VeriSign has promoted,
and will continue to promote, competition among registrars by offering a
compelling combination of quality, reliability, and overall value for the
services it offers. In addition, VeriSign has heavily invested in the .net TLD
infrastructure, innovative services, and staff. Similarly, these strengths have
ensured that the .net TLD remains a viable competitor among all TLDs.

The touchstone of competition is the range of choices available to consumers
when they purchase a product. In the domain name industry, choice includes the
ability of consumers (registrants) to select from a wide range of packages,
quality, and price when purchasing a domain name registration. With over 250
TLDs, including 7 gTLDs and 6 sTLDs, over 1,000 registrars and over 10,000
resellers, both registrars and consumers have a wide range of choices both
across TLDs and within specific TLDs. To continue expanding consumer choice, the
.net TLD operator must provide programs that increase registrars in new regions
throughout the world, and support existing registrars' marketing and technical
needs on an equivalent and reliable basis. In addition, the operator must
maintain a high quality of service (QoS) to ensure that .net remains an
attractive choice in an industry with over 60 million domain names and a growth
rate of 16 percent per year.

The .net registry operator must continue to operate .net at a high level of
reliability and security, to accommodate existing and growing demands, and to
service and support new and innovative applications that rely on the DNS. If the
current standards of reliability and security for .net are not maintained,
consumers and businesses will have a lower expectation of QoS, and therefore,
fewer choices to meet their performance and quality requirements for services
ranging from websites and email to new services such as VOIP and converged networks.
  
Over the last 5 years, VeriSign has actively supported the expansion of consumer
choice and promoted competition through: 1) recruiting 120+ new registrars in
regions such as China, South Korea, and Brazil; 2) maintaining 99.99 percent
availability, easy implementation, and equivalent access of SRS for all
registrars; 3) instituting marketing programs to support registrars' customer
acquisition and retention programs; 4) providing registrars with objective
market research to support their business needs; 5) implementing the ATLAS
infrastructure that supports multiple protocols and IPV6; and 6) maintaining 100
percent availability of resolution services. The impact of these programs and
ATLAS is evidenced by: .net growing at a rate of 22 percent, outpacing the
overall growth of 16 percent in domain name registrations; supporting over 58
percent of the world's name servers;, and having contracts with over 50 percent
more registrars than other ICANN sanctioned registries due to VeriSign's
recruitment efforts and reliability and stability.

A major component of VeriSign's efforts to promote competition is ensuring
consumers have expanded choice in purchasing .net names registrars through our
enrollment of new registrars in developing regions such as Latin America, and
maintaining the rapid on-boarding process for new registrars. VeriSign will
continue to implement recruitment programs similar to ones in China and South
Korea that, in 2004, resulted in four new registrars and an increase in .net
domain name registrations from 135,034 names per year to 152,551 per year in
those regions. The programs will include such activities as regional market
research, marketing programs, and consumer education programs [marketing tools,
programs and research information is available in Section 3(b)ii]. In addition,
to ensure consumers are able to easily purchase .net domain names from all
registrars, VeriSign commits to maintain and enhance the equivalent, easy, and
reliable access it currently provides for the SRS. This commitment includes an
enhanced SLA for SRS availability of 99.99 percent, implementing new ICANN
accredited registrars within 45 days, providing registrars with SRS toolkits and
24x7x365 customer services in 150 languages, and maintaining our current policy
of equivalent access. If the registration system does not meet these standards,
then fewer registrars will sell the domain names in the .net TLD, resulting in a
reduction in consumer choice.

Complementing VeriSign's programs to expand the registrar base is our focus on
maintaining a robust resolution system that will support 100 percent
availability and new uses of the DNS infrastructure, such as VOIP and IDNs. This
focus on reliability and application support ensures .net remains a competitive
choice among registrars, resellers and consumers as their needs expand from
email and websites to new applications and uses of the DNS. To sustain this
robust infrastructure VeriSign will implement programs to: expand the number of
TLD name servers, maintain its two new name servers in China and South Korea,
continue to support IPV6 and enhance resolution SLAs [Section 3(a)]. The
continued expansion of the .net TLD name server constellation that VeriSign
already has undertaken will: improve the users access to .net supported
applications in developing markets such as Africa and Latin America, enable the
TLD to support the increase in traffic that will result from new uses of DNS,
and sustain the performance even during DDoS attacks that spike resolution
queries in excess of 10x their normal levels [Section 5(b)ii].

VeriSign commits to maintain for the term of the new contract the above
programs, to continue to provide a high degree of reliability through enhanced
resolution and registration SLAs, and to continue to expand on the innovative
practices that have resulted in the competitive choice .net provides for domain
name registration.


Reliance on Multiple Suppliers

VeriSign has delivered the secure, stable registry services required for
critical Internet infrastructure since the creation of a dedicated .net registry
in 1996. During this time, VeriSign has expended significant energy in
developing both business and technical relationships with an array of suppliers
since our architecture philosophy is diversity at the network, facility, and
hardware and software layers. To minimize reliance on a specific supplier,
VeriSign designs diversity into our registry architecture through hardware,
software, and network variations and through the careful selection of facilities
hosted by multiple vendors.

Multi-sourcing any operation has advantages and disadvantages. Through years of
experience in operating the current .net registry service, VeriSign has found
the most effective means of minimizing dependency on a specific supplier
includes: network, software, and hardware diversity.

VeriSign's production-related assets for .net are globally diverse. No more than
two locations are hosted by the same supplier to ensure that unanticipated
vendor problems will not significantly impact the availability or quality of the
.net registry service. While the primary production data centers (largely for
provisioning) are located in VeriSign's managed weapons grade facilities (as
discussed earlier in this section), DNS-related equipment is hosted by multiple
vendors. This geographic diversity is necessary to ensure optimum performance of
the .net resolution service and to minimize the likelihood that a local problem
would have far-reaching impact. In these cases, special provisions exist to
ensure that no more than two locations are hosted by a specific vendor (i.e., no
more than two at InterNap, no more than two at SingTel, etc.). Each of these
locations meets all of VeriSign's criteria for facilities infrastructure (e.g.,
controlled access, adequate and redundant environmental hardware, etc.). Use of
this control process ensures that an unanticipated problem (e.g., the abrupt
termination of KPN/Quest services in 2002) will not have an impact on the
availability or quality of the .net registry service.

With its geographically diverse network, fully redundant systems, and multiple
data centers located globally including multiple providers and backup providers
[Section 5(b)i for further detail], VeriSign can seamlessly transition network
operations in the event of any failures. Operators without this type of breadth
of coverage or end-to-end control have difficulty quickly addressing any network
or system failures. Considering the limited size and less financial stability of
other smaller operators, it is difficult for other providers to truly maintain
multiple vendors and separate technologies. This becomes problematic, as they
are at the mercy of vendors who do not share their responsibilities and mission.  

In addition to having a diverse network supplied through multiple vendors,
VeriSign applies this architectural philosophy at the hardware (e.g., IBM, Dell,
SUN, Cisco, Juniper, Foundry, etc.), operating system (e.g., Linux, AIX, and
Solaris), and third-party software layers (e.g., Weblogic and JBoss). A
dedicated team of skilled professionals carefully chooses devices that best
satisfy our stringent criteria for performance, reliability, and diversity.
Candidate devices are tested in our engineering laboratory and must pass a
demanding qualification process under extreme load and varying environmental
conditions. Test results are documented, and only if the device passes can it be
subsequently used in a production environment. This selection process minimizes
our dependency on specific suppliers should they not be able to perform in a
timely manner (we also keep a cache of available equipment sized to accommodate
short-term problems with vendor delivery). Use of multiple suppliers also
dramatically reduces our vulnerability should a specific vendor have a flaw that
can not be quickly rectified (this is particularly important for public-facing
solutions).  VeriSign does not rely on any affiliations or direct or indirect
arrangements for any past or present operations of the .net registry. We do not
plan to use external affiliations for continued operations.

Unlike many smaller or less experienced companies, VeriSign has the capability,
supported by the extensive infrastructure [described in Sections 5(a) and (b)]
to perform all registry functions without the need to establish subcontract
arrangements with other companies.



Improved Implementation of GNSO Policies

VeriSign is in compliance with all GNSO policies. We have a proven process for
working with the GNSO, the IETF and other working groups to foster the
development of policies that benefit the Internet community and to ensure
VeriSign implements new policies on a timely basis [ Section 1]. VeriSign has a
proven method for deployment of policies and system improvements. It includes
providing active input in the shaping of policy; creating registrar feedback
systems for implementing specific requirements; end user testing the prototype;
deploying the policy program; writing and vetting technical requirements with
the technical and policy community; seeking ICANN approval on registry specific
rules and technical implementation path; holding seminars for registrars to
discuss the technical requirements; providing engineering and technical on-call
assistance with the deployment; and creating tools to assist registrars in the
deployment. To improve VeriSign's implementation of, and support for, GNSO
policies, VeriSign will continue to sponsor a .net Policy Advisory Group. 

Support for GNSO Policies

VeriSign takes seriously our responsibility to provide input in the shaping of
policies and the timely implementation of these policies. Through a combination
of registrar interaction and community stewardship, deployment options are
developed that attempt to reduce the impact to registrars as well as provide the
end user with the best possible experience. This has been true in our handling
of the transfer dispute policy.

Example: Transfer Dispute Policy: VeriSign played an integral role in the
creation of the ICANN -Registrar Transfer Policy [ Section 1]. Chuck Gomes, VP,
Policy, played a key role in all stages of the multi-year policy development
process, which resulted in the implementation of the policy on 12 November 2004.
Extensive efforts were made to vet the policy, the accompanying Dispute
Resolution Policy and VeriSign's Supplemental Rules with the Internet community,
gaining support from registries and registrars for handling of transfer issues.
 VeriSign created an internal task force to analyze and assess areas of key
concerns over transfers, providing key historical and current data on transfer
activity, transfer abuse and trends in registrations to ICANN. Upon receipt of
the policy, VeriSign's Transfer Task Force held a summit on the policy and
outlined key implementation questions. These issues were then vetted with ICANN
and the registrar community. The output of these discussions was the basis for
the implementation plan and supplemental rules that VeriSign implemented. One of
the outputs of the conversation with our registrars was that our registrars
wanted an easy online tool for inputting and tracking their disputes. Therefore,
VeriSign developed an easy to use web-based form for submitting transfer
disputes that registrars agreed was optimal for supporting their business.
Additionally, VeriSign built out a process and team that can scale with the
transfer dispute cases should the need arise. VeriSign used its Customer Service
Representative (CSR), Registrar Account and Customer Affairs (CA) teams to hold
web seminars on the business and technical implementation of the policy. These
sessions were held many times to accommodate registrar time zones. Individual
technical and business support sessions were held at the request of the
registrars. Before deployment, the account management and CA teams worked to
circulate the new required Registry-Registrar Transfer amendment, as approved by
ICANN. Verisign used its CSR and account teams to contact every accredited
registrar, follow up on the implementation of the policy, and encourage
signature of the transfer amendment. To date, VeriSign has signed amendments
from 180 members of the registrar community. VeriSign continues to support the
transfer policy by discussing the policy and procedures for using the dispute
process and tools at our industry forums in Europe, Asia, North America, and
Brazil. 

Once a policy is implemented, VeriSign sponsors consortiums and working groups
in which VeriSign brings together application developers, key Internet business
constituency members, registries, and registrars for the facilitation of the
developing tools and programs that support the policy. 

VeriSign is often a driver of policy discussion, as with DNSSEC, expiring names
handling and multilingual domain development. In driving these new policies,
VeriSign creates industry forums and recruits ICANN participation in driving
discussion of these issues, submission of white papers for ideas, and ultimate
consensus building.  An example of this is our role in the Deleted Names Policy
and in the development of IDNs/ Multilingual policy. (For additional examples on
DNSSEC and IRIS refer to www.verisignlabs.com).

Deleted Names Policy: VeriSign is working with the ICANN community on the
implementation of a solution for the handling of deleted names, an issue that is
very much a concern of registries and registrars alike. VeriSign began
contacting ICANN and the registrar community in October 2003 to discuss the
impact of increasing registrar accreditations for .com and .net and the impact
that was having to registry operations. In particular, there has been
significant impact on the operation of the batch pool that VeriSign created to
handle automated batch registration requests for recently deleted names.
VeriSign held registrar forums to solicit input on how to maintain equivalent
access and sound operation for the batch pool, given the changing environment of
registrar add storms in the batch pool and registrars selling their ICANN
accreditations to others for the purpose of add storming the batch pool.
VeriSign then created a summary of various solution ideas for handling expiring
names and presented them to ICANN and members of the GNSO Registrar
Constituency. VeriSign suggested that a forum be held in Cape Town at the ICANN
meeting to review the process of handling deleted names. A public forum was held
on 1 December 2004.

VeriSign is now working with Bruce Tonkin, one of the Registrar Constituency's
representatives to the GNSO Council, to facilitate the process of developing a
solution for an industry-wide com/net deleted names handling process, which
facilitates an open auction during the pending delete period.

In January 2005, VeriSign will begin surveying end users in the Internet
community to get input on various types of auction house solutions and price
sensitivity for deleted name auctions. VeriSign anticipates providing the
feedback received from end users, along with a revised deleted names proposed
auction model in February 2005. The proposed model will be further vetted with
registrars and other stakeholders to ensure that it adequately addresses the
needs of registrars, registrants, and other impacted parties.


Efforts to Improve Policy Implementation

In 2003, VeriSign formed a Public Advisory Group (PAG) for the purpose of
meeting with management of VeriSign Naming and Directory Services to: (1)
consider and provide advice to VeriSign's management related to, among other
things, the DNS; (2) generate ideas and feedback on the development and rollout
of new value added services; and (3) serve as a sounding board and vehicle
through which the company's management can solicit advice from the Internet
technology and business community. Since that time, the Advisory Group has
considered and provided advice and recommendations regarding the company's
policies, procedures, and operations with respect to the management of Internet
domain names, system management and other related issues. The Advisory Group
continues to provide advice, feedback and circulate ideas and information
related to VeriSign's products and services. Therefore, the PAG ensures that the
company is meeting the needs of the Internet community as a whole. For the .net
TLD, the Group will be used as an advisory body to VeriSign in all aspects of
ICANN/GNSO policy development with a particular focus on ensuring proper
implementation of policies. The group is composed of highly respected experts in
Internet technology and business, the goal being to include industry recognized
individuals with international experience. 


Conclusion

VeriSign has a strong track record promoting competition in the registration of
domain names. We have the largest registrar base of any operator, and are proven
to provide equivalent access to registrars and a high quality of service. We
introduce diversity into our registry administration by multi-sourcing hardware,
software, and dedicated bandwidth to ensure stable and secure service delivery.
Finally, we will support the Policy Advisory Group to assist in the smooth and
efficient implementation of applicable ICANN consensus policies.
   

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:

8-i Steps and sequencing of a transition

The single greatest opportunity to introduce risk into a well-managed .net
service is transitioning to another operator. Any transition of the .net
infrastructure will involve the high-risk migration of a top-level domain (TLD)
that supports over 30 percent or about $700 billion worth of e-commerce
transactions annually. In addition, , 2.8 trillion page views, 300 billion
e-mails, 58% of all Internet hosts and more than 5 million domain names are
dependent on the flawless operation of the .net infrastructure.

VeriSign Advantages:
+ Financial stability and commitment to operate domain name registries
+ Leadership in the advancement of core DNS technologies
+ Delivering over 7 years of uninterrupted name resolution
+ No transition risk to the .net ecosystem by selecting VeriSign.

The track record in transitioning large-scale critical infrastructure services
is not filled with success stories. Experience is not enough when determining a
registry operator for .net; success is the appropriate metric. Any disruption to
the core operations of the .net registry, however short, will result in
significant losses and possible long-term damage to the .net TLD. Such a
disruption would also affect the reputation of the global domain name system
(DNS) as the foundation of the Internet.

VeriSign has demonstrated superior technical and operational success in its
management of .net. This is clearly demonstrated throughout this proposal:
* Delivering over 7 years of 100 percent DNS name resolution
* Leadership in the advancement of core DNS technologies
* Financial stability and commitment to operate domain name registries
* Global support of our service and expectation of our continued management.

VeriSign's performance in running the .net TLD speaks for itself. VeriSign is
committing to the highest Service Level Agreements (SLAs) of any existing
registry operator. These benefits alone outweigh the overall risks of migration
to another registry operator given .net's importance and the magnitude of
transition.

The only way to ensure uninterrupted service is for there to be no transition.



8-ii: Duration and extent of outages

A transition of the .net TLD to a successor operator could result in both
system-wide and localized outages because:
* There is currently no other operator that has demonstrated the capability of
taking over .net.
* The timeframe does not support a successful risk adverse transition
* The performances of other current gTLD operators fall well below what the
Internet has come to expect from .net (see Section 5.(b)ii, Stability of
Resolution and Performance Capabilities of this application).

Outages could result from system-wide failures or localized failures due to
decreases in global DNS coverage, or even changes to the underlying network
infrastructure (see Section 5(b)vi, Geographic Network Coverage of this
application).

The .net registry is a multifaceted solution with many interfaces and
dependencies. Over many years millions of diverse stakeholders in the .net TLD
have developed dependencies for their daily core operations. The current .net
RFP process will not only involve the possibility of a high-risk transition of
the .net TLD zones, support data, and support systems, but also be a substantial
change to systems and processes at registrars, resellers, and ultimately, to
registrants.

A transition of only the core of the registry technical operations does not
constitute a full transition for the TLD. The infrastructure has been embedded
in the Internet over time; some implementations dependent on the .net
infrastructure may not automatically utilize the transitioned system. This was
made clear in the proof-of-concept round of new generic top-level domains
(gTLDs) where an unknown number of providers, legacy DNS resolvers, and other
systems used cached root zones and updates made to the root zone servers, which
were inaccessible to end users. The impact of other similar hard-coded
dependencies on the current .net infrastructure is largely unknown; these
dependencies could constitute a significant risk to the stability of the
Internet and could disrupt services to a large number of end users and
stakeholders. 

ICANN must ensure that all applicants possess the resources to quickly expand
staff, facilities, equipment, and communications as well as have disaster
recovery facilities and business continuity plans in place (and exercised) on
day one. Also, all applicants must address plans for community outreach to
eliminate transition risk to external systems:
* How is this done?
* How long will it take to reach everyone?
* How long will it take each person/organization affected to take appropriate
actions?
* What is the measure of success prior to proceeding with a transition?

The risks associated with the transition of a global real-time system with as
many dimensions as .net are substantial. Figure 8-ii-1 details the potential
risk associated with downtime. 

Minor flaws in any part of the chain from registry to registrar to reseller to
registrant could heavily impact all stakeholders, resulting in significant cost
or other injury.

VeriSign has more than 15 years of experience operating the world's largest
domain name system (DNS), public key infrastructure (PKI), and Internet payment
infrastructures, as well as the largest independent SS7 telephony network in
North America. Through years of proven performance and technical capabilities to
deliver reliable, stable critical infrastructure services, we have demonstrated
that VeriSign is the most qualified registry to continue running the .net registry.

VeriSign's long history of providing highly scalable and reliable infrastructure
solutions for critical network services has enabled us to build organizational
core expertise in registry systems. Over the past 13 years, VeriSign has
demonstrated the technical capabilities to successfully design, develop, and
operate critical Internet infrastructure. VeriSign has set many of the standards
now universally adopted by the industry. Our technical experts regularly provide
education and share best practices for maintaining stability and security of
operation. The successful operation of these critical registries is core to
VeriSign's corporate strategy. Our company has invested heavily to provide the
right people, infrastructure, and processes focused on delivering superior
performance and stability.

Many of .nets largest stakeholders agree that transitioning .net from VeriSign
is not a sound business or technical decision. They understand the risk to their
businesses, be it hardware, software, registrar sales or telecommunications. A
fully listing of endorsements for VeriSign's continued management of the .net
registry can be found in Appendix D of this proposal; a highlight of some of
those is found in Figure 8-ii-2.

Other systems that could be impacted are critical services currently performed
for the registrar community or for other stakeholders. The registry provides a
multitude of processes, in addition to the core registry functions. These
process are often overlooked, but to stakeholders these are often the most
critical. Examples of services other than SRS and DNS that could be affected are:
* Whois services could be interrupted leading to issues for IP, law enforcement,
network operations, and other legitimate uses of the Whois system
* Zone file access could be interrupted leading to loss of service to IP
monitoring providers, corporate internal zone-file caches, and others who have
legitimate uses for the zone files.
A registry operator must address that the impacts caused by infrastructure
changes may result in disruption of services due to caching name servers. A
registry operator must disclose analysis on potential failures of their
registration system as they attempt to support the number of registrars
currently accredited for the sale of .net (both from a business and technical
perspective). This analysis must also include how the registry operator will
handle the increase in SRS (registry) transactions that are experienced today.
Additionally, if the increase in SRS transactions are in excess of the load of
the registry operator's existing systems, then it must show adequate test cases
and scalability analyses to ensure they are capable of handling load and
capacity increases of 20-fold.

Often overlooked areas such as customer service and network operations must be
reviewed with the same level of concern to the performance of the SRS and
resolution systems. Insufficient staffing in these areas will leave registrars
frustrated as they receive busy signals or as they are placed on-hold for
extended durations. Additionally, the registry operator must show that its
network operations center staff (NOC) can provide adequate coverage to address
system failures while supporting answers to registrar customer calls.

In most cases, existing registries are required to stand up a new instance of
their system for each TLD they support. This means that these registries have
not resolved problems with the configuration of new environments until the
environment goes live. This is not a trivial task of updating a configuration
file for industry standard name server software, such as BIND.

Registration Services

Any loss of service in the registration system will significantly impact both
registrars and registrant stakeholders. The most vulnerable and critical time
for the .net registry is during, and immediately following, the transition. In
previous agreements, the registry operator's obligations under the SLA were
waived during the first 120 days after the Commencement-of-Service date. In
addition, registry operators have not reported their performance against the SLA
during this period. Because .net is critical to the Internet infrastructure and
to global e commerce, and this is the most critical time, the registry operator
should not receive a waiver.

VeriSign has invested significant amounts of resources to ensure continuous
operations of the registration systems in the event of failure. These systems
have already been in operation for an extended period, and have proven
themselves to be highly capable, resulting in unprecedented levels of availability.

A registry operator should support both full local fail-over in all parts of the
registration systems, as well as full geographic fail-over, should a
catastrophic event happen to one of its locations. Additionally, our fail-over
planning has multiple options, including a third-party disaster recovery plan.

System-wide Outages

The fact that the .net top-level domain is so critical to the stability of the
global Internet means that even very short outages will have significant impact
and could result in losses to stakeholders. Even a system that fulfills the
current SLA requirement for .net, as laid out in the current contract, will not
be satisfactory to stakeholders. For registrars, a loss of service will result
in loss of revenue and also loss of confidence in the service provided by the
channel to registrants.

Registrars will see an increase in customer service queries as a result of an
outage of the registration system. During a full service disruption to the
registration system, no domain names can be updated or deleted by the registrars
using the registry interface application program interface (API). Transfers of
domain names, and general maintenance of registry objects, will also be
prevented by a full service disruption.

One example of a consequential effect of an outage is that law enforcement
officials could be prevented from shutting down a phishing site (by having a
registrar delete the respective domain name) to avoid users being tricked into
revealing data such as their Internet bank login details.

Localized Outages

The registrar community has spent significant time and resources optimizing its
systems for the current operator. A new operator will not perfectly mirror the
current solution provided by VeriSign, however it needs to be understood that
this has consequential effects. Different geographic locations of
infrastructure, underlying network connectivity, and peering arrangements will
result in changes to network latency of the successor operator's systems.
Registrars that have spent significant amounts of time and resources to ensure
high levels of connectivity to the current solution might need to change their
solutions, resulting in significant costs to the channel.

Transitions require incredible resources for logistics management. This includes
provisioning new registrars and validating these registrars in test
environments. But the most important part is maintaining equivalent access.
Equivalent access should not be interpreted as ramping up the top 10 registrars
to run on a registry system and then making efforts to bring the remaining 290
registrars online as time permits. To maintain the propriety of "equivalent
access," the transitioning registry operator must guarantee that no registrar
will get access until all registrars who want access have been ramped up.

Resolution Services

Any change to the DNS resolution infrastructure could have significant
detrimental impact on the service provided to the global Internet community.
Such disruptions can be classed as either system-wide outages that result in a
total loss of resolution service, or as localized losses of service that could
affect either a distinct geographic area or a specific network provider.

Request for Comment (RFC) 2036, Observations on the use of Components of the
Class A Address Space within the Internet, was introduced by both
NeuStar/NeuLevel and Afilias. It is VeriSign's belief that strict adherence to
RFC 2036 for the implementation of the resolution services of the .net registry
system will not scale, and will also require proprietary software to interface
the SRS to the name server software. Through this implementation, it is
anticipated that solutions utilizing this implementation will break under
excessive load where near real-time updates are involved. 
Registry failures will impact the registrant constituencies the most. The
registrant constituencies are the individual companies in which downtime and
failures will equate to lost revenue, traffic, and customers. These companies
are on the front-line of customer service and will receive immediate queries in
the event of any outage and will assume a large portion of the negativity
associated with a service degradation.

The current resolution systems for .net have a very high level of spare capacity
and are also built with extensive global coverage and geographic diversity in
mind (see Section 5(b)vi, Geographic Network Coverage). The implementation
provided by Verisign has ensured the outstanding performance of the resolution
systems of the .net registry system.

As has been in the past, VeriSign continues to extend the footprint of the
resolution infrastructure. Currently, VeriSign has local installations on 3
continents and is represented in 7 countries. As times have changed and the
internet has evolved, there is an increased risk from malicious traffic, such as
distributed denial of service (DDoS) attacks and other incidents, such as worms
and errors in software packages. However, VeriSign understands that a secure and
stable infrastructure is important for the global availability of the Internet.
ICANN must ensure that any new registry operator has addressed the following:
* Scale
* Relationships with Governments, ISPs, and Fortune 1000 companies
* Skilled staff with security clearances

The extensive contingency plans put in place by VeriSign have been developed
over a long period of time as the threats to the global DNS infrastructure have
evolved (see Section 5(b)xviii, System Recovery Procedures). No other operator
has demonstrated the level of performance, redundancy, and contingency planning
for registration and resolution services of which VeriSign has achieved.

System-wide Outages 

A full resolution failure for .net will have global consequences for
stakeholders and the Internet community as a whole. The result will be major
service disruptions and significant economic impacts. Even very short
system-wide outages for .net will result in major losses due to the large amount
of traffic that depends on the .net TLD.
The fundamental nature of the .net TLD to the operations of the Internet makes
it very difficult to identify the full set of side effects from a possible
outage. As described previously, many other TLDs depend on .net name servers and
will also be impacted in the event of system-wide outages. Examples if these are
.AS, .INFO, .ORG, and .COM.

Localized Outages

The extensive geographic distribution of the .net infrastructure has resulted in
stakeholders with an expectation of, and a dependence on, the stability and
performance of the .net resolution services.
Any change to the geographic distribution, underlying network infrastructure, or
peering arrangements could affect DNS resolution performance in distinct local
areas.

This could result in the need for stakeholders to implement costly changes to
their systems to ensure continued resolution performance in the event that a
successor operator does not meet VeriSign's current standards.
Localized outages could be the result of deliberate attacks on the
infrastructure and systems. Ad-hoc solutions to address attacks as opposed to
viewing security and stability as a lifecycle could exacerbate the situation.
VeriSign, the current operator, has the necessary experience and processes in
place to deal with these issues, having addressed them across several very large
TLDs. No other operator has had exposure to these issues on a similar scale.



8-iii: Thin to thick registry transition

Many areas of cooperation of required to move from a thick to thin registry. A
few are described below. Most important to note is demonstrating an
understanding of the disadvantages of a thick registry model and that it is not
highly desired by the registrar community.


Cooperation of Registrars

As described in Section 5(b)iv, Registry-Registrar Model and Protocol, of this
application, a thick registry model is one in which the registry maintains
copies of all information associated with registered domains, including
registrant and contact information. VeriSign has discussed the implementation of
a thick registry model with registrars many times. The result is mixed. Many
registrars have expressed concern in disclosing details about their customer
base that is inherently available through a thick registry model. Additionally,
the increasing trend of registrars who offers private registrations exacerbates
this problem.


Synchronization of Data Fields

Along with the problem of getting the data, registrars do not want to be
burdened with a costly and time-consuming data migration or the recurring cost
of keeping dozens of additional data fields synchronized between their database
and the registry. A sample of Whois data from thick registries shows that
registry Whois data is frequently inconsistent with the data displayed by the
associated registrar. This sample data highlights the potential end user
confusion and challenges for registrars to keep even a modest amount of data
current across multiple systems.



8-iv: Contingency plans

Based on its experience with operating the .net registry and considering its
significance to the community, VeriSign has an extensive set of contingency
plans for events that could impact during the day-to-day running of .net (see
section 5(b)xviii, System Recovery Procedures, of this application). Any
potential successor operator will need to ensure that both the registration and
registrar systems function properly with .net. Also, the successful operator
must ensure that the resolution systems have fully developed and tested
contingency plans.

ICANN should not use transitions of the past as a measuring stick to evaluate
the plans of other registry operators. Given the dependency on .net, it is
imperative that ICANN ensure that any other registry operator clearly address
the considerable risk associated with any change to DNS infrastructure. Also, it
is essential that all registry operators address the transition problems that
may only have been visible to themselves and the registrars in past transitions.
VeriSign understands these risks and plans accordingly through its detailed
contingency and business continuity planning. 

For a significant registry like .net, both full local redundancy and geographic
redundancy will be needed to ensure the level of security and stability expected
and currently enjoyed by stakeholders.

ICANN must ensure that all applicants possess the resources to quickly expand
staff, facilities, equipment, and communications as well as have disaster
recovery facilities and business continuity plans in place (and exercised) on
day one. This includes escrow arrangements. Having a data escrow arrangement
that is fully executed and operationally tested before a transition should not
be optional. There is a high risk of a registry operator failing to fulfill its
contract requirements, should it fail to fully deploy all components of the
registry system, such as backup processes, disaster recovery, etc. Once the
database has been transitioned, should the registry operator fail or materially
breech his agreement, if there is no data escrow, the community would be faced
with a serious stability/continuity problem. The dataset provided by VeriSign
will become obsolete very quickly.



8-v: Effects on constituents

In the event the .net TLD was to be transitioned away from VeriSign, registrants
in .net would need to undertake a time-consuming and costly exercise in
evaluating the risks of the new operator and possibly migrate both their
infrastructure, and also their brands away from the .net TLD. Considering the
significance of both the volume and value of transactions performed, using the
services of the .net TLD, the cost to the community in performing this migration
will be significant. The information needed by the registrants to make a
thorough analysis relating to the need to migrate their operations away from
.net should already have been placed in the public domain.

As previously discussed, any new registry operator should challenge the allotted
time for the RFP process and the lack of information provided. A new registry
operator's plan should ensure stakeholders in .net receive adequate time and
opportunity to assess possible new technical, financial, and legal risks
associated with a possible transition of the .net TLD. As a consequence,
stakeholders may not have sufficient opportunity to migrate to another TLD in
the event that their risk analysis determines the cost of remaining with the
.net TLD to be too great.

The 3-month timeframe from the selection of the successor registry operator to
an actual transition falls far short of the time needed to perform an analysis
and implementation, QA, and deployment of any actions that stakeholders consider
needed to remove dependencies on .net from their systems nor will it provide an
opportunity for re-branding of their offerings.

The .net TLD registry currently has over 350 accredited registrars with over 250
fully operational. The number of registrars operating on the .net registry is
much larger than any of the other global TLDs, except .com.

In the event of a transition of .net away from VeriSign, the registrar community
will need to establish a new technical, financial, and legal relationship with a
successor registry operator. The process of migrating registrars and signing
contracts and ensuring that they are technically accredited will take
significant time. Simply building and populating a new account management
function for all the registrars currently operating on the .net registry is
highly unlikely in the timeframes suggested.

Registrars that have not been able to certify before a transition will not have
access to the SRS and will effectively be cut off from adding, deleting, or
modifying registrations in the .net registry. Additionally, the existing
customers of these registrars would not be able to manage existing registrations.

Any relaxation in the technical certification procedure will result in
significantly increased risk to registrants, registrars, and the registry.
Ensuring interoperability will help avoid errors in the interaction between
registrar and registry and will also ensure that registrars act in a technically
responsible manner.

Registrars are currently offered 90 days access to an OT&E environment to test
and evaluate their solutions after the registry has made any significant changes
to the registration systems or protocols. Any transition to a new registry
operator must be considered a significant change even if the protocol stays the
same.

Any registry operator must have their OT&E systems operational at the time of
the selection of the successor registry to be able to provide registrars with
adequate time to run their interoperability tests.

Accomplishing the migration of all the registrars currently operating on the
.net registry is unlikely in the timeframes laid out by the current RFP process.
Any delays to the migration could impact the equivalent access registrars have
to registry resources and could result in registrants not being able to access
and modify their registry objects, possibly leading to service outages.

Internet Users Seeking to Resolve .NET Domain Names

Historically, the .net and .com TLDs have been served by the same name server
constellations using the same name server domain names. Since .net and .com are
served by the same name server constellations using the same domain names, there
are a significant amount of stakeholders who cross-reference domain servers
between the .net and the .com registries. This will work in the current setup
where the name servers that service both .net and .com are the same, and the
glue records returned can be trusted. If the name servers for these two TLDs are
split, there may be stakeholders that will lose resolution for their domains
until they are able to update their name server records and their systems.


Circular Reference: A Case Study

Consider these two domains, with the following additional data that is necessary
for resolution to work:
-- COM Delegation -- 
example.com NS ns1.example.net
example.com NS ns2.example.net
ns1.example.net
ns2.example.net

- NET Delegation --
example.net NS ns1.example.com
example.net NS ns2.example.com
ns1.example.com
ns2.example.com
The circular configuration above is pathological and only works today because
.com and .net are hosted on the same servers. If they were hosted on separate
servers, a sufficiently paranoid iterative resolver (such as any modern Berkeley
Internet Name Domain [BIND] resolver) would be unable to resolve anything in
either example.com or example.net. This is a result of the additional records
(the "A" records) not being trusted.

The resolution steps will work like this:
client: www.example.com --> COM servers
COM servers: www.example.com = ask ns1.example.net with IP XXX.XXX.XXX.XXX
or ns2.example.net with IP YYY.YYY.YYY.YYY --> client
client: www.example.com --> XXX.XXX.XXX.XXX
XXX.XXX.XXX.XXX: www.example.com has IP 192.0.34.166 --> client
If COM and NET are split, however, we will get the following scenario (note the
missing additional Internet protocol [IP] addresses in this example):
client: www.example.com --> COM servers
COM servers: www.example.com = ask ns1.example.net or ns2.example.net
--> client
client: ns1.example.net --> NET servers
NET servers: ns1.example.net = ask ns1.example.com or ns2.example.com
--> client
client: ns1.example.com --> COM servers
COM servers: ns1.example.com = ask ns1.example.net or ns2.example.net
--> client
Now we have an infinite loop, so the domains example.com and example.net no
longer resolve.

The above is an example of a simple scenario, and more complicated examples of
domains that would stop working might look something like:
example.com NS ns.example.net
example.net NS ns.example2.com
example2.com NS ns.example2.net
example2.net NS ns.example.com
or
example.com NS ns.example.net
example.net NS ns.example.cc
example.cc NS ns.example.com
Even if the split of .com and .net servers were to supply the IP addresses shown
in cases like this, it would not help, because clients would throw the extra
information away. If they did not, then they would be vulnerable to DNS poisoning.

The full extent of this issue is very hard to quantify because there could be
domains that use .com name servers pointing to any other TLDs, and then, in the
end, point back to .com.

In addition, any domain that stops working as a result, could, in turn, be an
intermediate name in a resolution chain, creating a domino effect. It could also
create new single points of failure.

Performance of Registration System

As previously stated, the registrar community has spent significant time and
resources optimizing its systems for the current operator. A new operator will
not perfectly mirror the current solution provided by VeriSign, however this may
have consequential effects. Different geographic locations of infrastructure,
underlying network connectivity, and peering arrangements will result in changes
to network latency of the successor operator's systems.

Registrars that have spent significant amounts of time and resources to ensure
high levels of throughput to the current solution might require modifications to
their implementations in the event .net is transitioned to another registry
operator. This could result in significant costs to the channel.

Performance of Resolution System

VeriSign has extensive experience with BIND name servers and their behavior
under load. Our experience has shown us that when a name server's resolution
responses reaches peak, the BIND name server's performance begins to degrades as
the load continues to increase. For example, if a BIND name server has already
reached its peak capacity it will begin to drop queries. Once a DNS query is
dropped, the client will retry causing 1 query to now become 2. As these queries
are dropped, a cascading effect will occur causing more queries to be dropped
from more clients. Performance degradation on the BIND name server will
accelerate driving the box's performance to be compromised. It has been our
experience that allowing more than 1 percent of dropped queries would cause this
phenomenon to occur.



8-vi: Cooperation required from VeriSign

VeriSign received no contact from potential applicants regarding transition
planning. Therefore, any plans submitted by applicants have not properly
addressed the coordination requested from VeriSign. VeriSign will fulfill its
current contractual obligations for .net with respect to transition.

In the event of re-delegation, to ensure security and stability, any successor
operator would need a fully operational environment to adequately test
operations 60 days prior to the effective transition date. This would require
registrar accreditation of all 380+ registrars, all facilities, DNS sites, SRS
and requisite bandwidth to support current performance levels and functionality
(please see Section 3(a) for details). Additionally, a successor operator would
be required to establish a presence in China and Korea, implement .net mirror
constellations, and assume all operational costs for existing DNS mirror sites
in Seoul and Beijing.



8-vii: Relevant Experience

VeriSign managed .org through January of 2003, at which time the registration
services were transitioned to Public Interest Registry (PIR). PIR is the sponsor
of the .org TLD; Afilias, Ltd. manages the technical aspects of the registry.
The transition was a multi-staged process, with first registration and then
resolution services. VeriSign managed resolution services through August of 2003
until that service was transitioned to UltraDNS, the subcontractor to Afilias. 

Empirical data on the .org transition shows that .org ran at high service levels
for resolution and registration and was actively monitored while being managed
by VeriSign. Today, the same can not be said for the administration of .org
post-transition.

Experience has shown the numerous risks with the transition of a TLD. The .org
transition from VeriSign to Afilias was riddled with problems and resulted in
decreased competition in domain name services and severely degraded experience.
These problems include:
* Chronic shared registration system (SRS) outages 
* Limited transition time for extensible provisioning protocol (EPP) migration
* Launched with fewer registrars than incumbent supported.

Individually, these types of failures should not be accepted for .net; combined,
they represent a near catastrophic service degradation of core Internet
infrastructure. Additionally, because our network coverage is far broader, every
applicant would be required to make an extensive network expansion that includes
designing, provisioning, facilities agreements, communications deals, and staff
expansions. 

The technical performance of .org after migrating from VeriSign has
substantially degraded. Some specific examples include:
* Unplanned outages of the registration system increased from less than 2
min/month to more than 2 hours/month
 - Issue: Registrars depend on availability and reliability of the registry
* Increase in .org SRS response times: to add domains increased 100+ times
 -  Issue: Registrars expect com-like performance - their business is impacted
by degraded performance 
* .org DNS is less robust with limited global infrastructure
 - Issue: Limited scalability and global presence has the potential to impact
all Internet users when websites are not reachable, emails cannot be delivered,
the entire TLD is down due to inability to scale to peak demand, DDoS attack, -
* .org Whois: response times increased 10x
 -  Issue: Slower response time with 1/10 the query volume of com/net raises
scalability concern
* Loss of functionality
 - Issue: No support for IDN registrations that existed prior to migration

The impact to .net is likely to be magnified due to increased scale of
registered name base, transaction volumes and DNS queries as, at the time,
Afilias was operating .info with only 1M domains and through .org added 2.5M
domains. The .org performance dropped by nearly 3x compared to .info and 100x
compared to .com & .net. 

Additionally, VeriSign operated .org with no SLA violations; PIR/Afilias have
violated multiple SLA metrics in every month since the transition, though they
have not been reported. A recent discussion highlighted these problems
(www.free2innovate.net) and inconsistencies in the performance and reporting of
Afilias.

NeuLevel's parent NeuStar has two transition-related experiences: 
1) Migration of a non-real-time registration system, the .us country code
(ccTLD). This transition was merely zone file operations and resolution; there
was no real-time registration system. Although NeuStar had a functioning
registry platform at the time of transition, it did not launch the real-time
registration system for over 6 months after the zone file transfer. This
small-scale transition had its flaws, with existing registrants unable to make
modifications to their domains.
2) The launch of Wireless Number Portability (WNP) in November 2003 was the
extension of a service NeuStar offered for over 6 years. Yet, the launch had
several problems, which prohibited telecommunications carriers and wireless
subscribers to fully operate. [note: Richard J. Dalton Jr., "Cell phone users
find change is slow; Switching carriers but not number isn't so quick," The
Kansas City Star, December 28, 2003 and Tricia Duryee, "AT&T Wireless lists
issues causing switching problems," The Seattle Times, December 11, 2003.]
Though the company claimed adequate capacity planning, they were proven wrong
even though the volume of requests was not near the industry anticipated demand.
 
These are but two examples of how experience alone does not guarantee success.
The remainder of this section addresses each of the subsections outlined in the
RFP. Because of our unique knowledge of the services, full understanding of
network security and stability and experience with two TLDs transitioned off our
platforms, VeriSign has tremendous insight into the operational aspects of a
transition. Further, several .net stakeholders support our continued management.

These registry operators lack innovation (Part 2, Section 3(b)), have not made
comparable investments in their infrastructure (Part 2, Section 4), and do not
have sufficient geographic diversity (Part 2, Section 5(b)i) to properly
maintain the existing stability and security of .net.

Further confounding and concerning is these companies' consistent failure to
meet contractual performance commitments. By example, the Afilias registry
recently appeared to change its service level commitments, lowering the
requirements for availability (www.icann.org/tlds/monthly-reports/, Monthly
Operators Report, compare June and July 2004). A second example is the
commitments to provide new services and products: the .biz, .info, and .org
registry agreements and appendices specify numerous services that are not
currently available.

Many ccTLD registry systems have not been designed to support the number of
registrars that provision .net. Even the largest (by number of domains) ccTLD
operator, DENIC, has deployed systems that frequently go offline as illustrated
in Figure 8-vii-1.



8-viii: Criteria of a successful transition

1. The service levels achieved today are maintained (see Section 3(a) for
minimum requirements) and those proposed by VeriSign are exceeded.

2. There is no interruption in any facet of the existing .net service (see
Section 3(b) for requirements).

3. The service is operated from no less than 14 resolution sites plus a
sufficient number of hot standby sites to ensure all SLAS (see #1 above), 2 data
centers, and one tertiary site (see Section 5(b)vi and 5(b)I for specifics on
geographic coverage and redundancy).

4. The .net TLD is fully monitored with a technology comparable to VeriSign's
Heads-Up Display and the successor operator supports all existing government
access relationships.

5. The registry operator has a fully-tested real-time registration database with
5 million domain names and can support over 4 billion DNS queries per day
(approximately 46 thousand queries per second) under normal conditions and
500,000 per second under adverse conditions.

6. All constellations for anycasted mirror sites are available Day 1, including
sites equivalent to those existing in Korea today, and China in February.

7. Dual support for RRP and EPP for a minimum of 12 months and a transition
schedule mutually agreed upon by registrars.

8. Name Servers should transition in 30 days.

9. All registrars will be fully operational on July 1 at current connection
levels for SRS and batch pools and be provided automated billing and reporting
and 24x7x365 customer support in 150 languages.

10. Support IDNs, including all language tables and offer a resolution solution.

11. Full support of ICANNs Transfer Policy.


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.

8-2: RRP to EPP

VeriSign wrote the Extensible Provisioning Protocol (EPP). We currently support
both Registry Registrar Protocol (RRP) and EPP, while implementing a smooth,
low-cost migration from RRP to EPP. VeriSign designed and implemented the Shared
Registration System (SRS) in 1998 and 1999 for the specific purpose of allowing
fair competition at the registrar level. From the time that registrar
competition was introduced in mid-1999, access to the SRS has been provided
through the Registry Registrar Protocol (RRP) based on RFC 2832. In 2003
VeriSign initiated discussions with its registrar customers to obtain their
input into a plan for migration to the Extensible Provisioning Protocol (EPP).
That plan is now in place and being implemented. Specific details of the plan
for supporting EPP 1.0 are provided in below including:
1. Dual Support of RRP and EPP
2. Schedule for Dual RRP and EPP Operations 
3. Status Mapping between RRP and EPP 
4. Status Rules

VeriSign Advantages
+ Employs leading experts in protocol development
+ Experience operating both RRP and EPP
+ Low-cost, smooth transition that offers registrars onsite account management,
schedule flexibility, webex training seminars, an extended RRP duration, and
mapping tools for migration ease.

It is important to recognize that the size and critical nature of the .net
registration base creates some special challenges for both the registry and
registrars in migrating to EPP. VeriSign has been particularly concerned about
the impact on registrars and therefore has solicited their input to make sure
that the migration plan is designed in both an effective and flexible manner
that accommodates varying registrar needs while ensuring security and stability
at both the registry and registrar levels. Providing extended dual support for
both protocols is a key aspect of the migration plan; it allows registrars
sufficient time to fit the migration effort into their development schedules and
to do so in a reliable way.		


Support of RRP and EPP

VeriSign's use of RRP for the .net registry will continue through an extended
dual operation period to minimize undue hardship imposed by a hard cutover.
Transitioning the .net registry from RRP to EPP is a complex task due to the
inherent differences between the two protocols. Operating the SRS with support
for both protocols simultaneously is not a trivial task, and requiring all
registrars to meet a cutover will place a burden on them and creates additional
challenges should one or more registrars not be capable of making the change at
the designated time. VeriSign began communicating with registrars to develop
this transition plan even before the EPP standards were finalized to solicit
feedback and lessons learned from previous registry migrations. 

Additionally, the ccTLD registries operated by VeriSign (.tv, .cc and .bz) have
traditionally been available through an RRP SRS that is nearly identical to the
.net registry. In the migration of those ccTLDs to EPP, VeriSign chose to use
the same dual operation transition process before implementing it in .net,
thereby allowing registrars to complete a similar transition in a full
production system before committing to a transition to a critical gTLD such as
.net. This dual system is currently in place, thus enabling registrars to gain
experience and prove the success of the dual protocol operation.

Solution

The features of this dual protocol operational period include:
* Compatibility with all RRP functionality currently available in .net is
maintained.
* Equivalent Access is preserved
* Registrar Console capabilities are enhanced through expanded web tool
functionality
* Reports for registrars are unchanged
* Whois format is modified to return EPP statuses
* Batch Pool automated processes using RRP remain unchanged
* Transfers of domain names between RRP and EPP registrars are enabled
* Enhanced features such as Redemption Grace Period (RGP), IDN, ConsoliDate, and
IPv6 are available through both protocols.


Schedule for Dual RRP and EPP Operations

VeriSign began offering an EPP 1.0 OT&E environment in September 2004 to allow
registrars an extended period of time to develop and test their systems and to
provide feedback on the technical implementation. Additionally, the dual
operation of RRP and EPP is being proven through our offering of simultaneous
RRP and EPP support for .bz, .cc, and .tv.

The implementation of EPP into the .net registry, scheduled for the second
quarter of 2005, will open an extended period for registrars to transition on a
schedule that is amenable to their development schedules. The existing RRP
implementation will continue to be operational and supported even after the
introduction of EPP. This period of RRP-EPP parallel operations will mitigate
operational risk to registrars and minimize impact to their business operations
and development schedules.

The migration from RRP will begin with the introduction of the EPP
implementation into the .net registry in the second quarter of 2005. The
existing RRP implementation will continue to be operational and supported even
after the introduction of EPP. This period of RRP-EPP parallel operations,
enabled by the VeriSign Registrar Console described earlier and depicted in
Figure 8-2-1, will mitigate operational and technical risk to registrars.

We will also support and encourage the adoption of EPP through a number of
additional tools used in the transition to EPP in other domains. These are
explicitly designed to promote low-cost, low-risk migration.
* VeriSign will provide a development and Beta test environment where registrars
can test new software systems prior to live operation.
* We will offer a JAVA-based software development kit (SDK) to facilitate the
modification of registrar systems that will integrate with the EPP platform.
* We have developed an EPP tool called REST that generates EPP extensible markup
language (XML) and that can be used in conjunction with the SDK to increase
registrar familiarity with the EPP protocol and formats.
* We will conduct web seminars, provide transition documentation to the
registrar community, and offer technical resources that will support registrar
transition.
* While the timing of the transition to EPP will be at the discretion of
registrars, the RRP implementation will be completely replaced by EPP at a time
determined jointly by VeriSign, ICANN, and the registrar community. Our
objective is to provide registrars sufficient time to transition at a time that
best fits their development schedule without constraint of hard cut-overs. Our
plan is to complete the transition no earlier than 2Q 2006.


Thick vs. Thin Registry

VeriSign evaluated the issue of migrating the .net registry from thin to thick
(variances in data are displayed in Figure 8-2-3) and came to the following
conclusions:
* Based on lessons learned from the .org migration from RRP to EPP including
feedback from registrars, if a migration to a thick registry is considered, it
should be performed as a totally separate migration from the protocol migration
to avoid over-complication of the EPP migration.
* Based on registrar feedback, the majority of registrars prefer a thin registry
model. A primary reason for this is that they perceive there to be a loss of
control of their customer data as is illustrated in the following table. A
secondary reason is that migrating customer data adds costs to registrars for
which many of them do not recognize any value plus they have the ongoing cost
and responsibility of ensuring that registry data is synchronized with registrar
data.
* Considering the work currently underway in the ICANN Generic Names Supporting
Organization's Whois task forces and the work nearing completion in the Internet
Engineering Task Force CRISP working group on the IRIS protocol, a primary value
of the thick registry model may be diminished. A key advantage of thick data at
the registry level is to facilitate a centralized Whois service instead of
having to search the Whois of many different registrars. The IRIS protocol
provides a way of implementing a centralized domain name lookup service through
a distributed architecture that would not require thick registry data.

Therefore, VeriSign proposes that the .net registry remain a thin registry at
least until such time that the work of the Whois task forces is completed and
the IRIS protocol becomes a recognized standard. At that time, if the Internet
community through ICANN processes develops a consensus policy that supports a
thick registry, VeriSign would cooperate to make that happen. 

Status Mapping

Table 8-2-1 defines the EPP statuses that will be set in the database for each
RRP status.

Table 8-2-2 defines the RRP statuses that will be displayed via RRP based on the
EPP statuses that are set in the database.

1) If a domain is on clientHold and one or more of the Client Prohibited
statuses (clientUpdateProhibited,clientTransferProhibited and/or
clientDeleteProhibited), then the REGISTRAR-HOLD and REGISTRAR-LOCK statuses
will be displayed. If the domain is on one or more of the Client Prohibited
statuses and not on a hold status, then REGISTRAR-LOCK will be displayed.
2) If a domain is on serverHold and one or more of the Server Prohibited
statuses (serverUpdateProhibited, serverTransferProhibited and/or
serverDeleteProhibited), then only the REGISTRY-HOLD and REGISTRY-LOCK statuses
will be displayed. If the domain is on one or more of the Server Prohibited
statuses and not on a hold status, then REGISTRY-LOCK will be displayed. Table
8-2-3 summarizes these commands.

Status Rules

1) The system will store and display the EPP statuses instead of RRP statuses.
The NCC plug-in, Whois, and the registrar reports will display the EPP statuses
for all users of all accounts. Registrars who are still using RRP will see the
RRP statuses via RRP, but they will see the EPP statuses in the NCC plug-in,
Whois, and registrar reports. 
2) When a transfer happens between two registrars, all existing statuses for the
domain will be removed and "ok" status will be set.
3) Status reason codes will NOT be used in EPP.
4) When any status code is explicitly set, the "ok" status will be removed. The
derived statuses (e.g., linked) can co-exist with the "ok" status.

VeriSign took the following steps to develop its EPP 1.0 migration plan:
- Analysis of registry technical requirements including detailed review of RFC
specifications
- Analysis of registrar technical requirements with particular focus on
operational impact
- Solicitation of registrar feedback with regard to migration time constraints,
business needs and technical development requirements
- Consideration of issues encountered in the .org RRP to EPP migration
- Integration of all of the above into a plan that maximizes the chances of a
smooth migration with minimal impact on registrars and registrants and minimizes
any chance of encountering security or stability issues.
The plan:
- Provides for dual support of RRP and EPP for an extended period of time and
thereby avoids the pitfalls associated with a hard cutover to EPP by in excess
of 250 registrars
 - Thoroughly addresses issues related to differences in statuses in the two
protocols by clearly defining status mapping between RRP and EPP and by
explicitly listing status rules
- Includes a migration schedule that allows for a reliable migration by all
registrars while at the same time providing registrar flexibility to best fit
their migration efforts into their business plans
- Calls for registry provided tools to facilitate registrar migration tasks
- Balances ICANN compliance requirements with cooperation between registry and
registrars
- Maximizes the chances of a seamless migration for registrants.

This plan provides a smooth, low-cost transition to registrars over a prolonged
migration period.


Conclusion

VeriSign currently supports RRP and EPP and is implementing a smooth, low cost
migration from RRP to EPP while continuing to support both protocols. VeriSign
has been and continues to be the leader in the industry for equivalent access.
VeriSign provides a demonstrated method to ensure a smooth and low cost
migration from RRP to EPP including the demonstrated ability to operate both RRP
and EPP during this migration period for at least one year. Other operators have
not demonstrated the ability to execute on a smooth, low cost migration. For
example, in the .org migration to PIR/Afilias, there were multiple problems
registrars encountered in the migration from RRP to EPP.


   

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