ICANN New gTLD Application

2 BENEFIT TO REGISTRANTS, INTERNET USERS, AND OTHERS
As of this writing, more than 800,000 internationalized second-level domain names are registered in .com,
including more than 40,000 in Arabic. The ARABIC_TRANSLITERATION_OF_.COM gTLD, along with
the other proposed IDN transliterations of .com, provide an immediate benefit to registrants of those
names by giving them the opportunity to register IDN second-level domain names as “IDN.IDN” domain
names. That is, registrants can use their preferred script in both the second-level domain name and the
gTLD name. Doing so improves these domain names’ functionality and accessibility to speakers of non-
Latin-based languages.

We anticipate that the availability of the ARABIC_TRANSLITERATION_OF_.COM will greatly increase
the appeal and value of internationalized addresses in North Africa and the Middle East. Expanding the
accessibility and functionality of these domain names to users worldwide is the primary benefit of all
internationalized transliterations of .com.

Finally, we anticipate that ARABIC_TRANSLITERATION_OF_.COM will increase choice and competition
in North Africa, the Middle East, and elsewhere by giving local users the option of registering their domain
name with an established, trusted gTLD in their own language. Potential registrants in North Africa and
the Middle East currently have limited choices if they want to register an IDN.IDN domain name in a gTLD
that is recognized across Arabic-speaking regions. The ARABIC_TRANSLITERATION_OF_.COM gTLD
creates an attractive new option for these users.

More specifically, the ARABIC_TRANSLITERATION_OF_.COM gTLD benefits the following groups:

Registrants: As discussed above, current .com registrants with second-level .com IDNs in Arabic can
greatly expand the functionality and reach of their existing registered addresses by the availability of
IDN.IDN domain names entirely in Arabic script. In addition, new registrants, whether in North Africa, the
Middle East, or elsewhere, who seek entirely Arabic addresses, have the option of registering their
IDN.IDN domain names in a globally recognized domain.

Internet Users: The ARABIC_TRANSLITERATION_OF_.COM gTLD significantly increases the ubiquity
and functionality of .com for users around the world, particularly those in North Africa and the Middle
East. For the first time, Arabic speakers could access a transliteration of .com addresses entirely in their
native script. Verisign is committed to ensuring that the domain name experience remains consistent to all
users, in every major script, everywhere in the world. This commitment supports the vision of “One World.
One Internet.” that infuses ICANN’s global efforts.

2.1 Business Goals

Our goal is for ARABIC_TRANSLITERATION_OF_.COM to operate as a best-in-class IDN registry.
Although the ARABIC_TRANSLITERATION_OF_.COM gTLD is distinct from the .com gTLD in the DNS,
we plan to provide a similar high quality of service that users of .com have come to expect.

The first step in this process is to ensure that, like .com, ARABIC_TRANSLITERATION_OF_.COM
operates at the highest level of availability, stability, and security. The
ARABIC_TRANSLITERATION_OF_.COM gTLD is rooted in the same world-class infrastructure that
supports .com and .net at the highest level of operational excellence. Users and registrants have
extremely high expectations of .com, and we leverage the full capability of our infrastructure and
operational expertise to ensure that ARABIC_TRANSLITERATION_OF_.COM meets these expectations
from the moment of its launch.

The initial target audience for ARABIC_TRANSLITERATION_OF_.COM is the registrants of the more
than 40,000 Arabic IDN second-level addresses in .com. These registrants will have the opportunity to
register their IDN.com addresses as IDN. ARABIC_TRANSLITERATION_OF_.COM addresses.

The secondary target market for ARABIC_TRANSLITERATION_OF_.COM is the current registrants of
ASCII domain name addresses who may be doing business in North Africa, the Middle East, or other
regions with a high number of Arabic speakers. The ARABIC_TRANSLITERATION_OF_.COM gTLD
provides these registrants a ready-made solution to localize their online identity while still maintaining the
continuity of their .com addresses.

Finally, we are committed to working with registrars to perform outreach in North Africa, the Middle East,
and elsewhere to reach potential new registrants who are interested in establishing a new IDN
ARABIC_TRANSLITERATION_OF_.COM domain name.

2.2. Competition, Differentiation, and Innovation Goals

Arabic speakers currently have limited options for registering IDN.IDN domain names. The
ARABIC_TRANSLITERATION_OF_.COM gTLD introduces competition and choice for registrants in
North Africa and the Middle East by providing them with an option that—while new—also carries the trust,
reliability, and accessibility of an established global brand.

What differentiates ARABIC_TRANSLITERATION_OF_.COM from other potential market entrants for
Arabic IDN gTLDs is that it represents a localized representation of a domain that many users already
know and trust, .com. In addition, ARABIC_TRANSLITERATION_OF_.COM is the best available phonetic
representation of “.com” in Arabic. The IDN’s brand is the brand of a globally recognized domain,
operated by a globally recognized provider.

2.3 User Experience Goals

Verisign’s goal for ARABIC_TRANSLITERATION_OF_.COM is to deliver a user experience as similar to
the current experience of .com as possible. Verisign operates the
ARABIC_TRANSLITERATION_OF_.COM gTLD at the same high level of security, stability, and
availability as .com, allowing registrars to enjoy the same high service levels that Verisign provides for all
of the domains we operate.

We helped organize and are deeply involved in the IDN Software Developers Consortium (IDNSDC),
which is committed to improving the functionality and accessibility of IDNs to users. We continue to
engage significantly in the IDNSDC to complement the IDN initiatives being driven by ICANN and to help
drive adoption of IDN capabilities in standard client software.

2.4 Registration Policies

The registration policies for ARABIC_TRANSLITERATION_OF_.COM follow closely the existing IDN
registration policies for .com. The Verisign Shared Registration System (SRS) allows the creation of IDNs
that contain Unicode supported non-ASCII scripts. We have developed a policy for IDN registrations
specifying permissible and prohibited code points. The policy is implemented in the following five rules.
IDNs that adhere to these five rules are considered valid registrations.

2.4.1. Internet Engineering Task Force (IETF) Standards

The IDNA2008 specification defines rules and algorithms that permit⁄prohibit Unicode points in IDN
registrations. We comply with all of the RFC documents that comprise the IDNA2008 standard.

2.4.2. Restrictions on Specific Languages

All IDN registrations require a three-letter Language Tag. ARA, for instance, is for the Arabic language. If
the Language Tag associated with the registration is in our Language Tag Table, we have a List of
Included Characters for that language. The requested IDN must be entirely contained within this List of
Included Characters. If even one code point from the IDN is not a valid character for this language, the
registration is rejected.

2.4.3. Restriction on Commingling of Scripts

If the Language Tag specified in the IDN registration is not in the approved list of Language Tags located
on our website, and so does not have a List of Included Characters, then we apply an alternate restriction
to prevent commingling of different scripts in a single domain.

The Unicode Standard defines a set of Unicode Scripts
(http:⁄⁄www.unicode.org⁄Public⁄6.0.0⁄ucd⁄Scripts.txt) by assigning each code point exactly one Unicode
script value. As a rule, Verisign rejects the commingling of code points from different Unicode scripts.
That is, if an IDN contains code points from two or more Unicode scripts, then that IDN registration is
rejected. For example, a character from the Latin script cannot be used in the same IDN with any Cyrillic
character. All code points within an IDN must come from the same Unicode script. This is done to prevent
confusable code points from appearing in the same IDN.

Again, this rule only applies to languages for which there is not a strictly defined List of Included
Characters. For example, the FRE Language Tag, indicating the French language, does not have a strict
List of Included Characters, and so the commingling rule applies. All code points in a French domain must
come from a single script.

2.4.4. The Verisign SRS also adheres to ICANN’s Guidelines for the Implementation of Internationalized
Domain Names. Section 5 of the document outlines characters that are allowed by the IETF standard, but
should be prohibited for IDN registration.

2.4.5. Special Characters

There are two (Unicode characters whose latest definitions are not backward compatible with previous
versions of the IDNA Standard. The Latin Sharp S and Greek Final Sigma were previously mapped to
alternate characters. Clients and registries that comply with the older standard would, for instance, map a
Latin Sharp S into two lowercase Latin letter S characters. This mapping is irreversible. The latest version
of the IDNA standard does not apply this mapping. So, whereas the Latin Sharp S was previously
prohibited (mapped into other characters), the latest standard allows registries to accept this character at
their own discretion.

Because these changes are not backward compatible, Verisign has elected to continue to disallow these
two characters until a clear and fair approach to their r
egistration has been reached and communicated.
Additional information about our registration policies and approach to rights protection is available in our
response to Question 29, Rights Protection Mechanisms.

2.5 Measures to Protect Privacy and Confidentiality

We limit information collection from registrants to ICANN mandated data points required in the registration
of a domain name, and use this data solely for the purpose of publishing to the publicly available Whois
service. Whois Terms of Use are available on our website.

2.6 Outreach and Communications
Registrar Outreach
Many of our registrars have marketed and supported IDNs at the second-level of the .com TLD for more
than ten years. Well-established registrars have provided IDN communications and customer service in
markets where IDNs provide the highest level of benefit. We have sought advice from registrars and
actively communicated the planned approach for launching IDNs at the top-level in regular meetings with
the registrar channel. We continue to work closely with registrars not only to prepare for the Sunrise,
Trademark Claims service, and general launch periods, but also to reach existing and prospective
registrants who are interested in realizing the benefits of IDNs.

Registrant and End-User Outreach
We augment our existing IDN web content with launch planning information and additional online
resources for the IDN.IDN transliterations of .com. This web content includes details on the benefits of
IDNs, and our approach to protect intellectual property and enhance end-user ubiquity. The full launch
plan addresses Sunrise and Trademark Claims services, general launch through the registrar channel,
and localized content for the initial launch markets.
The IDN Software Developerʹs Consortium (IDNSDC)

To complement the IDN initiatives being driven by ICANN, we have organized a consortium to facilitate
adoption of IDN capabilities in standard client software. The IDNSDC works with domain name industry
stakeholders and application developers to bring greater awareness to existing client-side application
challenges so that registrars in communication with their domain name registrants may fully understand
usability issues.

1 CUSTOMARY REGISTRY SERVICES

Verisign provides a comprehensive system and physical security solution that is designed to
ensure a TLD is protected from unauthorized disclosure, alteration, insertion, or destruction of
registry data. Our system addresses all areas of security including information and policies,
security procedures, the systems development lifecycle, physical security, system hacks, break-
ins, data tampering, and other disruptions to operations. Our operational environments not only
meet the security criteria specified in our customer contractual agreements, thereby preventing
unauthorized access to or disclosure of information or resources on the Internet by systems
operating in accordance with applicable standards, but also are subject to multiple independent
assessments as detailed in the response to Question 30, Security Policy. Our physical and
system security methodology follows a mature, ongoing lifecycle that was developed and
implemented many years before the development of the industry standards with which we
currently comply. Please see the response to Question 30, Security Policy, for details of the
security features of our registry services.

Verisign’s registry services comply with relevant standards and best current practice RFCs
published by the Internet Engineering Task Force (IETF), including all successor standards,
modifications, or additions relating to the DNS and name server operations including without
limitation RFCs 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 3901, 4343, and 4472.
Moreover, our Shared Registration System (SRS) supports the following IETF Extensible
Provisioning Protocol (EPP) specifications, where the Extensible Markup Language (XML)
templates and XML schemas are defined in RFC 3915, 5730, 5731, 5732, 5733, and 5734. By
strictly adhering to these RFCs, we help ensure our registry services do not create a condition
that adversely affects the throughput, response time, consistency, or coherence of responses to
Internet servers or end systems. Besides our leadership in authoring RFCs for EPP, Domain
Name System Security Extensions (DNSSEC), and other DNS services, we have created and
contributed to several now well-established IETF standards and are a regular and long-standing
participant in key Internet standards forums.

Figure 23-1 (see Attachment VRSN_.comAra_Q23 Figures for all figures in this response)
summarizes the technical and business components of those registry services, customarily
offered by a registry operator (i.e., Verisign), that support this application. These services are
currently operational and support both large and small Verisign-managed registries. We provide
customary registry services in the same manner as we provide these services for our existing
gTLD.

Through these established registry services, we have proven our ability to operate a reliable and
low-risk registry that supports millions of transactions per day. We are unaware of any potential
security or stability concern related to any of these services.

Registry services defined by this application are not intended to be offered in a manner unique
to the new generic top-level domain (gTLD) nor are any proposed services unique to this
application’s registry.

As further evidence of Verisign’s compliance with ICANN mandated security and stability
requirements, we allocate the applicable RFCs to each of the five customary registry services
(items A – E above). For each registry service, we also provide evidence in Figure 23-2 of our
RFC compliance and include relevant ICANN prior-service approval actions.

1.1 Critical Operations of the Registry

I. Receipt of Data from Registrars Concerning Registration of Domain Names and
Name Servers

See Item A in Figure 23-1 and Figure 23-2.

ii. Provision to Registrars Status Information Relating to the Zone Servers

Verisign registry services provisions to registrars status information relating to zone servers for
the TLD. The services also allow a domain name to be updated with client Hold, server Hold
status, which removes the domain name server details from zone files. This ensures that DNS
queries of the domain name are not resolved temporarily. When these hold statuses are
removed, the name server details are written back to zone files and DNS queries are again
resolved. Figure 23-3 describes the domain name status information and zone insertion
indicator provided to registrars. The zone insertion indicator determines whether the name
server details of the domain name exist in the zone file for a given domain name status. Verisign
also has the capability to withdraw domain names from the zone file in near-real time by
changing the domain name statuses upon request by customers, courts, or legal authorities as
required.

iii. Dissemination of TLD Zone Files

See Item B in Figure 23-1 and Figure 23-2.

iv. Operation of the Registry Zone Servers

As a company, Verisign operates zone servers and serves DNS resolution from 76
geographically distributed resolution sites located in North America, South America, Africa,
Europe, Asia, and Australia. Currently, 17 DNS locations are designated primary sites, offering
greater capacity than smaller sites comprising the remainder of the Verisign constellation. We
also use Any cast techniques and regional Internet resolution sites to expand coverage,
accommodate emergency or surge capacity, and support system availability during
maintenance procedures. We operate the gTLD from a minimum of eight of our primary sites
(two on the East Coast of the United States, two on the West Coast of the United States, two in
Europe, and two in Asia) and expand resolution sites based on traffic volume and patterns.
Further details of the geographic diversity of our zone servers are provided in the response to
Question 34, Geographic Diversity. Moreover, additional details of our zone servers are
provided in the response to Question 32, Architecture and the response to Question 35, DNS
Service.

v. Dissemination of Contact and Other Information Concerning Domain Name
Server Registrations

See Item C in Figure 23-1 and Figure 23-2.

2 OTHER PRODUCTS OR SERVICES THE REGISTRY OPERATOR IS REQUIRED TO PROVIDE
BECAUSE OF THE ESTABLISHMENT OF A CONSENSUS POLICY

Verisign is a proven supporter of ICANN’s consensus-driven, bottom-up policy development
process whereby community members identify a problem, initiate policy discussions, and
generate a solution that produces effective and sustained results. Verisign currently provides all
of the products or services (collectively referred to as services) that the registry operator is
required to provide because of the establishment of a Consensus Policy. For the
ARABIC_TRANSLITERATION_OF_.COM gTLD, we implement these services using the same
proven processes and procedures currently in-place for all registries under our management.
Furthermore, we execute these services on computing platforms comparable to those of other
registries under our management. Our extensive experience with consensus policy required
services and our proven processes to implement these services greatly minimize any potential
risk to Internet security or stability. Details of these services are provided in the following
subsections. It shall be noted that consensus policy services required of registrars (e.g., Whois
Reminder, Expired Domain) are not included in this response. This exclusion is in accordance
with the direction provided in the question’s Notes column to address registry operator services.

2.1 Inter-Registrar Transfer Policy (IRTP)

Technical Component
In compliance with the IRTP consensus policy, we have designed our registration systems
to systematically restrict the transfer of domain names within 60 days of the
initial create date. In addition, we have implemented EPP and “AuthInfo” code functionality,
which is used to further authenticate transfer requests. The registration system has been
designed to enable compliance with the five-day Transfer grace period and includes the
following functionality:

* Allows the losing registrar to proactively ‘ACK’ or acknowledge a transfer prior to the
expiration of the five-day Transfer grace period
* Allows the losing registrar to proactively ‘NACK’ or not acknowledge a transfer prior
to the expiration of the five-day Transfer grace period
* Allows the system to automatically ACK the transfer request once the five-day
Transfer grace period has passed if the losing registrar has not proactively ACK’d or
NACK’d the transfer request.

Business Component
All requests to transfer a domain name to a new registrar are handled according to the
procedures detailed in the IRTP. Dispute proceedings arising from a registrarʹs alleged failure to
abide by this policy may be initiated by any ICANN-accredited registrar under the Transfer
Dispute Resolution Policy. Our compliance office serves as the first-level dispute resolution
provider pursuant to the associated Transfer Dispute Resolution Policy. As needed Verisign is
available to offer policy guidance as issues arise.

Security and Stability Concerns
We are unaware of any impact, caused by the service, on throughput, response time,
consistency, or coherence of the responses to Internet servers or end-user systems. By
implementing the IRTP in accordance with ICANN policy, security is enhanced as all transfer
commands are authenticated using the AuthInfo code prior to processing.

ICANN Prior Approval
We have been in compliance with the IRTP since November 2004.

Unique to the TLD
This service is not provided in a manner unique to the
ARABIC_TRANSLITERATION_OF_.COM gTLD.

2.2 Add Grace Period (AGP) Limits Policy

Technical Component
Our registry system monitors registrars’ Add grace period deletion activity and provides
reporting that permits us to assess registration fees upon registrars that have exceeded the
AGP thresholds stipulated in the AGP Limits Policy. Further, we accept and evaluate all
exemption requests received from registrars and determine whether the exemption request
meets the exemption criteria. We maintain all AGP Limits Policy exemption request activity so
that this material may be included within our Monthly Registry Operator Report to ICANN.

Registrars that exceed the limits established by the policy may submit exemption requests to us
for consideration. Our compliance office reviews these exemption requests in accordance with
the AGP Limits Policy and renders a decision. Upon request, we submit associated reporting on
exemption request activity to support reporting in accordance with established ICANN
requirements.

Business Component
The Add grace period (AGP) is restricted for any gTLD operator that has implemented an AGP.
Specifically, for each operator:

* During any given month, an operator may not offer any refund to an ICANN-
accredited registrar for any domain names deleted during the AGP that exceed (i) 10%
of that registrarʹs net new registrations (calculated as the total number of net adds of
one-year through ten-year registrations as defined in the monthly reporting
requirement of Operator Agreements) in that month, or (ii) fifty (50) domain names,
whichever is greater, unless an exemption has been granted by an operator.
* Upon the documented demonstration of extraordinary circumstances, a registrar may
seek from an operator an exemption from such restrictions in a specific month. The
registrar must confirm in writing to the operator how, at the time the names were
deleted, these extraordinary circumstances were not known, reasonably could not
have been known, and were outside the registrarʹs control. Acceptance of any
exemption will be at the sole and reasonable discretion of the operator; however
ʺextraordinary circumstancesʺ that reoccur regularly for the same registrar will not be
deemed extraordinary.

In addition to all other reporting requirements to ICANN, we identify each registrar that has
sought an exemption, along with a brief description of the type of extraordinary circumstance
and the action, approval, or denial that the operator took.

Security and Stability Concerns
We are unaware of any impact, caused by the policy, on throughput, response time,
consistency, or coherence of the responses to Internet servers or end-user systems.

ICANN Prior Approval
We have had experience with this policy since its implementation in April 2009.

Unique to the TLD
This service is not provided in a manner unique to the
ARABIC_TRANSLITERATION_OF_.COM gTLD.

2.3 Registry Services Evaluation Policy (RSEP)

Technical Component
We adhere to all RSEP submission requirements. We have followed the process many times
and are fully aware of the submission procedures, the type of documentation required, and the
evaluation process that ICANN adheres to.

Business Component
In accordance with ICANN procedures detailed on the ICANN RSEP website
(http:⁄⁄www.icann.org⁄en⁄registries⁄rsep⁄), all gTLD registry operators are required to follow this
policy when submitting a request for new registry services.

Security and Stability Concerns
As part of the RSEP submission process, we identify any potential security and stability
concerns in accordance with RSEP stability and security requirements. We never launch
services without satisfactory completion of the RSEP process and resulting approval.

ICANN Prior Approval
Not applicable.

Unique to the TLD
gTLD RSEP procedures are not implemented in a manner unique to the
ARABIC_TRANSLITERATION_OF_.COM gTLD.

3 PRODUCTS OR SERVICES ONLY A REGISTRY OPERATOR IS CAPABLE OF PROVIDING BY REASON
OF ITS DESIGNATION AS THE REGISTRY OPERATOR

We have developed a Registry-Registrar Two-Factor Authentication Service that complements
traditional registration and resolution registry services. In accordance with direction provided in
Question 23, Verisign details below the technical and business components of the service,
identifies any potential threat to registry security or stability, and lists previous interactions with
ICANN to approve the operation of the service. The Two-Factor Authentication Service is
currently operational, supporting multiple registries under ICANN’s purview.

We are unaware of any competition issue that may require the registry service(s) listed in this
response to be referred to the appropriate governmental competition authority or authorities with
applicable jurisdiction. ICANN previously approved the service(s), at which time it was
determined that either the service(s) raised no competitive concerns or any applicable concerns
related to competition were satisfactorily addressed.

3.1 Two-Factor Authentication Service

Technical Component
The Registry-Registrar Two-Factor Authentication Service is designed to improve domain name
security and assist registrars in protecting the accounts they manage. As part of the service,
dynamic one-time passwords (OTPs) augment the user names and passwords currently used to
process update, transfer, and⁄or deletion requests. These one-time passwords enable
transaction processing to be based on requests that are validated both by “what users know”
(i.e., their user name and password) and “what users have” (i.e., a two-factor authentication
credential with a one-time-password).

Registrars can use the OTP when communicating directly with Verisign’s Customer Service
department as well as when using the registrar portal to make manual updates, transfers, and⁄or
deletion transactions. The Two-Factor Authentication Service is an optional service offered to
registrars that execute the Registry-Registrar Two-Factor Authentication Service Agreement.

Business Component
There is no charge for the Registry-Registrar Two-Factor Authentication Service. It is enabled
only for registrars that wish to take advantage of the added security provided by the service.

Security and Stability Concerns
We are unaware of any impact, caused by the service, on throughput, response time,
consistency, or coherence of the responses to Internet servers or end-user systems. The
service is intended to enhance domain name security, resulting in increased confidence and
trust by registrants.

ICANN Prior Approval
ICANN approved the same Two-Factor Authentication Service for Verisign’s use on .com and
.net on 10 July 2009 (RSEP Proposal 2009004) and for .name on 16 February 2011 (RSEP
Proposal 2011001).

Unique to the TLD
This service is not provided in a manner unique to the
ARABIC_TRANSLITERATION_OF_.COM gTLD.

1 ROBUST PLAN FOR OPERATING A RELIABLE SRS

1.1 High-Level Shared Registration System (SRS) System Description

Verisign provides and operates a robust and reliable SRS that enables multiple registrars to
provide domain name registration services in the top-level domain (TLD). Our proven reliable
SRS serves approximately 915 registrars, and as a company, we have averaged more than 140
million registration transactions per day. The SRS provides a scalable, fault-tolerant platform for
the delivery of gTLDs through the use of a central customer database, a web interface, a
standard provisioning protocol (i.e., Extensible Provisioning Protocol, EPP), and a transport
protocol (i.e., Secure Sockets Layer, SSL).

The SRS components include:

* Web Interface: Allows customers to access the authoritative database for accounts,
contacts, users, authorization groups, product catalog, product subscriptions, and customer
notification messages.

* EPP Interface: Provides an interface to the SRS that enables registrars to use EPP to
register and manage domains, hosts, and contacts.

* Authentication Provider: A Verisign-developed application, specific to the SRS, that
authenticates a user based on a login name, password, and the SSL certificate common
name and client IP address.

The SRS is designed to be scalable and fault tolerant by incorporating clustering in multiple tiers
of the platform. New nodes can be added to a cluster within a single tier to scale a specific tier,
and if one node fails within a single tier, the services will still be available. The SRS allows
registrars to manage the ARABIC_TRANSLITERATION_OF_.COM gTLD domain names in a single architecture.

To flexibly accommodate the scale of our transaction volumes, as well as new technologies, we
employ the following design practices:

* Scale for Growth: Scale to handle current volumes and projected growth.

* Scale for Peaks: Scale to twice base capacity to withstand “registration add attacks” from a
compromised registrar system.

* Limit Database CPU Utilization: Limit utilization to no more than 50 percent during peak
loads.

* Limit Database Memory Utilization: Each user’s login process that connects to the
database allocates a small segment of memory to perform connection overhead, sorting,
and data caching. Our standards mandate that no more than 40 percent of the total
available physical memory on the database server will be allocated for these functions.

Our SRS is built upon a three-tier architecture as illustrated in Figure 24-1 (see Attachment
VRSN_.comAra_Q24 Figures for all figures in this response) and detailed here:

* Gateway Layer: The first tier, the gateway servers, uses EPP to communicate with
registrars. These gateway servers then interact with application servers, which comprise the
second tier.

* Application Layer: The application servers contain business logic for managing and
maintaining the registry business. The business logic is particular to each TLD’s business
rules and requirements. The flexible internal design of the application servers allows
Verisign to easily leverage existing business rules to apply to the ARABIC_TRANSLITERATION_OF_.COM
gTLD. The application servers store Verisign’s data in the registry database, which
comprises the third and final tier. This simple, industry-standard design has been highly
effective with other customers for whom we provide backend registry services.

* Database Layer: The database is the heart of this architecture. It stores all the essential
information provisioned from registrars through the gateway servers. Separate servers query
the database, extract updated zone and Whois information, validate that information, and
distribute it around the clock to our worldwide domain name resolution sites.

Scalability and Performance

We implement our scalable SRS on a supportable infrastructure that achieves the availability
requirements in Specification 10. We employ the design patterns of simplicity and parallelism in
both our software and systems, based on our experience that these factors contribute most
significantly to scalability and reliable performance. Going counter to feature-rich development
patterns, we intentionally minimize the number of lines of code between the end user and the
data delivered. The result is a network of restorable components that provide rapid, accurate
updates. Figure 24-2 depicts EPP traffic flows and local redundancy in our SRS provisioning
architecture. As detailed in the figure, local redundancy is maintained for each layer as well as
each piece of equipment. This built-in redundancy enhances operational performance while
enabling the future system scaling necessary to meet additional demand created by this or
future registry applications.

Besides improving scalability and reliability, local SRS redundancy enables us to take down
individual system components for maintenance and upgrades, with little to no performance
impact. With our redundant design, we can perform routine maintenance while the remainder of
the system remains online and unaffected. For the ARABIC_TRANSLITERATION_OF_.COM gTLD registry, this
flexibility minimizes unplanned downtime and provides a more consistent end-user experience.

1.2 Representative Network Diagrams

Figure 24-3 provides a summary network diagram of Verisign’s SRS. This configuration at both
the primary and alternate-primary Verisign data centers provides a highly reliable backup
capability. Data is continuously replicated between both sites to ensure failover to the alternate-
primary site can be implemented expeditiously to support both planned and unplanned outages.

1.3 Number of Servers

We continually review our server deployments for all aspects of our registry service. We
evaluate usage based on peak performance objectives as well as current transaction volumes,
which drive the quantity of servers in our implementations. Our scaling is based on the following
factors:

* Server configuration is based on CPU, memory, disk IO, total disk, and network throughput
projections.

* Server quantity is determined through statistical modeling to fulfill overall performance
objectives as defined by both the service availability and the server configuration.

* To ensure continuity of operations for the ARABIC_TRANSLITERATION_OF_.COM gTLD, we use a minimum of
100 dedicated servers per SRS site. These servers are virtualized to meet demand.

1.4 Description of Interconnectivity with Other Registry Systems

Figure 24-4 provides a technical overview of Verisign’s SRS, showing how the SRS component
fits into this larger system and interconnects with other system components.

1.5 Frequency of Synchronization Between Servers

We use synchronous replication to keep our SRS continuously in sync between the two data
centers. This synchronization is performed in near-real time, thereby supporting rapid failover
should a failure occur or a planned maintenance outage be required.

1.6 Synchronization Scheme

Verisign uses synchronous replication to keep the SRS continuously in sync between the two
data centers. Because the alternate-primary site is continuously up, and built using an identical
design to the primary data center, it is classified as a “hot standby.”

2 SCALABILITY AND PERFORMANCE ARE CONSISTENT WITH THE OVERALL BUSINESS APPROACH
AND PLANNED SIZE OF THE REGISTRY

As an experienced backend registry provider, we have developed and use proprietary system
scaling models to guide the growth of our TLD supporting infrastructure. These models direct
our infrastructure scaling to include, but not be limited to, server capacity, data storage volume,
and network throughput that are aligned to projected demand and usage patterns. We
periodically update these models to account for the adoption of more capable and cost-effective
technologies.

Verisign’s scaling models are proven predictors of needed capacity and related cost. As such,
they provide the means to link the projected infrastructure needs of the ARABIC_TRANSLITERATION_OF_.COM
gTLD with necessary implementation and sustainment cost. Using the projected usage volume
for the most likely scenario (defined in Question 46, Template 1 – Financial Projections: Most
Likely) as an input to our scaling models, we derived the necessary infrastructure required to
implement and sustain this gTLD. Cost related to this infrastructure is provided as “Total Critical
Registry Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46 financial
projections response.

3 TECHNICAL PLAN THAT IS ADEQUATELY RESOURCED IN THE PLANNED COSTS DETAILED
IN THE FINANCIAL SECTION

As an experienced backend registry provider, we have developed a set of proprietary resourcing
models to project the number and type of personnel resources necessary to operate a TLD. We
routinely adjust these staffing models to account for new tools and process innovations. These
models enable us to continually right-size our staff to accommodate projected demand and
meet service level agreements as well as Internet security and stability requirements. Using the
projected usage volume for the most likely scenario (defined in Question 46, Template 1 –
Financial Projections: Most Likely) as an input to our staffing models, we derived the necessary
personnel levels required for this gTLD’s initial implementation and ongoing maintenance.
This personnel-related cost is included in “Total Critical Registry Function Cash Outflows”
(Template 1, Line IIb.G) within the Question 46 financial projections response.

Verisign employs more than 1,040 individuals of which more than 775 comprise our technical
work force. (Current statistics are publicly available in our quarterly filings.) Drawing from this
pool of on-hand and fully committed technical resources, we have maintained DNS
operational accuracy and stability 100 percent of the time for more than 13 years for .com,
proving our ability to align personnel resource growth to the scale increases of our TLD service
offerings.

We project we will use the following personnel roles, which are described in Section 5 of the
response to Question 31, Technical Overview of Proposed Registry, to support SRS
performance:

* Application Engineers: 19
* Database Administrators: 8
* Database Engineers: 3
* Network Administrators: 11
* Network Architects: 4
* Project Managers: 25
* Quality Assurance Engineers: 11
* SRS System Administrators: 13
* Storage Administrators: 4
* Systems Architects: 9

To implement and manage the ARABIC_TRANSLITERATION_OF_.COM gTLD as described in this application, we
scale, as needed, the size of each technical area now supporting our portfolio of TLDs.
Consistent with our resource modeling, we periodically review the level of work to be performed
and adjust staff levels for each technical area.

When usage projections indicate a need for additional staff, our internal staffing group uses an
in-place staffing process to identify qualified candidates. These candidates are then interviewed
by the lead of the relevant technical area. By scaling one common team across all our TLDs
instead of creating a new entity to manage only this proposed gTLD, we realize significant
economies of scale and ensure our TLD best practices are followed consistently. This
consistent application of best practices helps ensure the security and stability of both the
Internet and this proposed gTLD, as we hold all contributing staff members accountable to the
same procedures that guide our execution of the Internet’s largest TLDs (i.e., .com and .net).
Moreover, by augmenting existing teams, we afford new employees the opportunity to be
mentored by existing senior staff. This mentoring minimizes start-up learning curves and helps
ensure that new staff members properly execute their duties.

4 EVIDENCE OF COMPLIANCE WITH SPECIFICATION 6 AND 10 TO THE REGISTRY AGREEMENT

Section 1.2 (EPP) of Specification 6, Registry Interoperability and Continuity
Specifications

Verisign provides these services using our SRS, which complies fully with Specification 6,
Section 1.2 of the Registry Agreement. In using our SRS to provide backend registry services,
we implement and comply with relevant existing RFCs (i.e., 5730, 5731, 5732, 5733, 5734, and
5910) and intend to comply with RFCs that may be published in the future by the Internet
Engineering Task Force (IETF), including successor standards, modifications, or additions
thereto relating to the provisioning and management of domain names that use EPP. In
addition, our SRS includes a Registry Grace Period (RGP) and thus complies with RFC 3915
and its successors. Details of the Verisign SRS’ compliance with RFC SRS⁄EPP are provided in
the response to Question 25, Extensible Provisioning Protocol. We do not use functionality
outside the base EPP RFCs, although proprietary EPP extensions are documented in Internet-
Draft format following the guidelines described in RFC 3735 within the response to Question 25.
Moreover, prior to deployment, Verisign will provide to ICANN updated documentation of all the
EPP objects and extensions supported in accordance with Specification 6, Section 1.2.

Specification 10, EPP Registry Performance Specifications

Verisign’s SRS meets all EPP Registry Performance Specifications detailed in Specification 10,
Section 2. Evidence of this performance can be verified by a review of the .com and .net
Registry Operator’s Monthly Reports, which we file with ICANN. These reports detail our
operational status of the .com and .net registries, which use an SRS design and approach
comparable to the one proposed for the ARABIC_TRANSLITERATION_OF_.COM gTLD. These reports provide
evidence of our ability to meet registry operation service level agreements (SLAs) comparable
to those detailed in Specification 10. The reports are accessible at the following URL:
http:⁄⁄www.icann.org⁄en⁄tlds⁄monthly-reports⁄.

In accordance with EPP Registry Performance Specifications detailed in Specification 10, our
SRS meets the following performance attributes:

* EPP service availability: Fewer than or equal to 864 minutes of downtime (approximately
98%)

* EPP session-command round trip time (RTT): Fewer than or equal to 4000 milliseconds
(ms), for at least 90 percent of the commands

* EPP query-command RTT: Fewer than or equal to 2000 ms, for at least 90 percent of the
commands

* EPP transform-command RTT: Fewer than or equal to 4000 ms, for at least 90 percent of
the commands

1	COMPLETE KNOWLEDGE AND UNDERSTANDING OF THIS ASPECT OF REGISTRY 
TECHNICAL REQUIREMENTS

We have used Extensible Provisioning Protocol (EPP) since our inception and possess 
complete knowledge and understanding of EPP registry systems. Our first EPP 
implementation—for a thick registry for the .name generic top-level domain (gTLD)—was in 
2002. Since then we have continued our RFC-compliant use of EPP in multiple TLDs, as 
detailed in Figure 25-1 (see Attachment VRSN_.comAra_Q25 Figures for all 
figures in this response). 

Our understanding of EPP and our ability to implement code that complies with the applicable 
RFCs is unparalleled. Mr. Scott Hollenbeck, Verisign’s director of software development, 
authored the Extensible Provisioning Protocol and continues to be fully engaged in its 
refinement and enhancement (U.S. Patent Number 7299299 – Shared registration system for 
registering domain names). We have also developed numerous new object mappings and 
object extensions following the guidelines in RFC 3735 (Guidelines for Extending the Extensible 
Provisioning Protocol). Mr. James Gould, a principal engineer at Verisign, led and co-authored 
the most recent EPP Domain Name System Security Extensions (DNSSEC) RFC effort (RFC 
5910).

All Verisign registry systems use EPP. Upon approval of this application, we will use EPP to 
provide registry services for this gTLD. The .com, .net, and .name registries, for which we are 
the registry operator, use an SRS design and approach comparable to the one proposed for this 
gTLD. Approximately 915 registrars use our EPP service, and the registry system performs 
more than 140 million EPP transactions daily without performance issues or restrictive 
maintenance windows. The processing time service level agreement (SLA) requirements for the 
Verisign-operated .net gTLD are the strictest of the current Verisign-managed gTLDs. All 
processing times for Verisign-operated gTLDs can be found in ICANN’s Registry Operator’s 
Monthly Reports at http:⁄⁄www.icann.org⁄en⁄tlds⁄monthly-reports⁄. 

We have also been active on the Internet Engineering Task Force (IETF) Provisioning Registry 
Protocol (provreg) working group and mailing list since work started on the EPP protocol in 
2000. This working group provided a forum for members of the Internet community to comment 
on Mr. Scott Hollenbeck’s initial EPP drafts, which Mr. Hollenbeck refined based on input and 
discussions with representatives from registries, registrars, and other interested parties. The 
working group has since concluded, but the mailing list is still active to enable discussion of 
different aspects of EPP.


1.1	EPP Interface with Registrars

Verisign fully supports the features defined in the EPP specifications and provides a set of 
software development kits (SDK) and tools to help registrars build secure and stable interfaces. 
Our SDKs give registrars the option of either fully writing their own EPP client software to 
integrate with the Shared Registration System (SRS), or using the Verisign-provided SDKs to 
aid them in the integration effort. Registrars can download the Verisign EPP SDKs and tools 
from the registrar website (http:⁄⁄www.Verisign.com⁄domain-name-services⁄current-
registrars⁄epp-sdk⁄index.html). 

The EPP SDKs provide a host of features including connection pooling, Secure Sockets Layer 
(SSL), and a test server (stub server) to run EPP tests against. One tool—the EPP tool—
provides a web interface for creating EPP Extensible Markup Language (XML) commands and 
sending them to a configurable set of target servers. This helps registrars in creating the 
template XML and testing a variety of test cases against the EPP servers. An Operational Test 
and Evaluation (OT&E) environment, which runs the same software as the production system 
so approved registrars can integrate and test their software before moving into a live production 
environment, is also available. 




2	TECHNICAL PLAN SCOPE⁄SCALE CONSISTENT WITH THE OVERALL BUSINESS APPROACH 
AND PLANNED SIZE OF THE REGISTRY

As an experienced backend registry provider, we have developed and use proprietary system 
scaling models to guide the growth of our TLD supporting infrastructure. These models direct 
our infrastructure scaling to include, but not be limited to, server capacity, data storage volume, 
and network throughput that are aligned to projected demand and usage patterns. We 
periodically update these models to account for the adoption of more capable and cost-effective 
technologies. 

Our scaling models are proven predictors of needed capacity and related cost. As such, they 
provide the means to link the projected infrastructure needs of the ARABIC_TRANSLITERATION_OF_.COM gTLD 
with necessary implementation and sustainment cost. Using the projected usage volume for the 
most likely scenario (defined in Question 46, Template 1 – Financial Projections: Most Likely) as 
an input to our scaling models, we derived the necessary infrastructure required to implement 
and sustain this gTLD. Cost related to this infrastructure is provided as “Total Critical Registry 
Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46 financial projections 
response.



3	TECHNICAL PLAN THAT IS ADEQUATELY RESOURCED IN THE PLANNED COSTS DETAILED 
IN THE FINANCIAL SECTION

As an experienced backend registry provider, we have developed a set of proprietary resourcing 
models to project the number and type of personnel resources necessary to operate a TLD. We 
routinely adjust these staffing models to account for new tools and process innovations. These 
models enable us to continually right-size our staff to accommodate projected demand and 
meet service level agreements as well as Internet security and stability requirements. Using the 
projected usage volume for the most likely scenario (defined in Question 46, Template 1 – 
Financial Projections: Most Likely) as an input to our staffing models, we derived the necessary 
personnel levels required for this gTLD’s initial implementation and ongoing maintenance. 
Cost related to this infrastructure is provided as “Total Critical Registry Function Cash Outflows” 
(Template 1, Line IIb.G) within the Question 46 financial projections response. 

We employ more than 1,040 individuals of which more than 775 comprise our technical work 
force. (Current statistics are publicly available in our quarterly filings.) Drawing from this pool of 
on-hand and fully committed technical resources, we have maintained DNS operational 
accuracy and stability 100 percent of the time for more than 13 years for .com, proving our 
ability to align personnel resource growth to the scale increases of our TLD service offerings. 

We project we will use the following personnel roles, which are described in Section 5 of the 
response to Question 31, Technical Overview of Proposed Registry, to support the provisioning 
of EPP services:

*	Application Engineers: 19 
*	Database Engineers: 3 
*	Quality Assurance Engineers: 11 


To implement and manage the ARABIC_TRANSLITERATION_OF_.COM gTLD as described in this application, we 
scale, as needed, the size of each technical area now supporting our portfolio of TLDs. 
Consistent with our resource modeling, we periodically review the level of work to be performed 
and adjust staff levels for each technical area. 

When usage projections indicate a need for additional staff, our internal staffing group uses an 
in-place staffing process to identify qualified candidates. These candidates are then interviewed 
by the lead of the relevant technical area. By scaling one common team across all our TLDs 
instead of creating a new entity to manage only this proposed gTLD, we realize significant 
economies of scale and ensure our TLD best practices are followed consistently. This 
consistent application of best practices helps ensure the security and stability of both the 
Internet and this proposed TLD, as we hold all contributing staff members accountable to the 
same procedures that guide our execution of the Internet’s largest TLDs (i.e., .com and .net). 
Moreover, by augmenting existing teams, we afford new employees the opportunity to be 
mentored by existing senior staff. This mentoring minimizes start-up learning curves and helps 
ensure that new staff members properly execute their duties.



4	ABILITY TO COMPLY WITH RELEVANT RFCS 

We incorporate design reviews, code reviews, and peer reviews into our software development 
lifecycle (SDLC) to ensure compliance with the relevant RFCs. Our dedicated QA team creates 
extensive test plans and issues internal certifications when it has confirmed the accuracy of the 
code in relation to the RFC requirements. Our QA organization is independent from the 
development team within engineering. This separation helps Verisign ensure adopted 
processes and procedures are followed, further ensuring that all software releases fully consider 
the security and stability of the TLD. 

For the ARABIC_TRANSLITERATION_OF_.COM gTLD, the Shared Registration System (SRS) complies with the 
following IETF EPP specifications, where the XML templates and XML schemas are defined in 
the following specifications:

*	EPP RGP 3915 (http:⁄⁄www.apps.ietf.org⁄rfc⁄rfc3915.html): EPP Redemption Grace Period 
(RGP) Mapping specification for support of RGP statuses and support of Restore Request 
and Restore Report (authored by Verisign’s Scott Hollenbeck)

*	EPP 5730 (http:⁄⁄tools.ietf.org⁄html⁄rfc5730): Base EPP specification (authored by Verisign’s 
Scott Hollenbeck)

*	EPP Domain 5731 (http:⁄⁄tools.ietf.org⁄html⁄rfc5731): EPP Domain Name Mapping 
specification (authored by Verisign’s Scott Hollenbeck)

*	EPP Host 5732 (http:⁄⁄tools.ietf.org⁄html⁄rfc5732): EPP Host Mapping specification (authored 
by Verisign’s Scott Hollenbeck)

*	EPP Contact 5733 (http:⁄⁄tools.ietf.org⁄html⁄rfc5733): EPP Contact Mapping specification 
(authored by Verisign’s Scott Hollenbeck)

*	EPP TCP 5734 (http:⁄⁄tools.ietf.org⁄html⁄rfc5734): EPP Transport over Transmission Control 
Protocol (TCP) specification (authored by Verisign’s Scott Hollenbeck)

*	EPP DNSSEC 5910 (http:⁄⁄tools.ietf.org⁄html⁄rfc5910): EPP Domain Name System Security 
Extensions (DNSSEC) Mapping specification (authored by Verisign’s James Gould and 
Scott Hollenbeck)


5	PROPRIETARY EPP EXTENSIONS

We use our SRS to provide registry services. The SRS supports the following EPP 
specifications, which we developed following the guidelines in RFC 3735, where the XML 
templates and XML schemas are defined in the specifications:

*	IDN Language Tag (http:⁄⁄www.verisigninc.com⁄assets⁄idn-language-tag.pdf): EPP 
internationalized domain names (IDN) language tag extension used for IDN domain 
name registrations

*	RGP Poll Mapping (http:⁄⁄www.verisigninc.com⁄assets⁄whois-info-extension.pdf): 
EPP mapping for an EPP poll message in support of Restore Request and Restore 
Report

*	Whois Info Extension (http:⁄⁄www.verisigninc.com⁄assets⁄whois-info-extension.pdf): EPP 
extension for returning additional information needed for transfers

*	EPP ConsoliDate Mapping (http:⁄⁄www.verisigninc.com⁄assets⁄consolidate-mapping.txt): 
EPP mapping to support a Domain Sync operation for synchronizing domain name 
expiration dates

*	NameStore Extension (http:⁄⁄www.verisigninc.com⁄assets⁄namestore-extension.pdf): EPP 
extension for routing with an EPP intelligent gateway to a pluggable set of backend products 
and services

*	Low Balance Mapping (http:⁄⁄www.verisigninc.com⁄assets⁄low-balance-mapping.pdf): EPP 
mapping to support low balance poll messages that proactively notify registrars of a low 
balance (available credit) condition


As part of the 2006 implementation report to bring the EPP RFC documents from Proposed 
Standard status to Draft Standard status, an implementation test matrix was completed. Two 
independently developed EPP client implementations based on the RFCs were tested against 
the Verisign EPP server for the domain, host, and contact transactions. No compliance-related 
issues were identified during this test, providing evidence that these extensions comply with 
RFC 3735 guidelines and further demonstrating Verisign’s ability to design, test, and deploy an 
RFC-compliant EPP implementation. A copy of the implementation test matrix that was 
completed in 2006 to bring the EPP RFC documents from Proposed Standard status to Draft 
Standard Status can be found here: http:⁄⁄www.ietf.org⁄iesg⁄implementation⁄report-rfc4930-
4934.txt


5.1	EPP Templates and Schemas

The EPP XML schemas are formal descriptions of the EPP XML templates. They are used to 
express the set of rules to which the EPP templates must conform in order to be considered 
valid by the schema. The EPP schemas define the building blocks of the EPP templates, 
describing the format of the data and the different EPP commands’ request and response 
formats. The current EPP implementations managed by Verisign use these EPP templates and 
schemas, as will the proposed TLD. For each proprietary XML template⁄schema, we provide a 
reference to the applicable template and include the schema.


XML templates⁄schema for idnLang-1.0 (IDN Language Tag)

*	Template: The templates for idnLang-1.0 can be found in Chapter 3, EPP Command 
Mapping of the relevant EPP documentation, http:⁄⁄www.verisigninc.com⁄assets⁄idn-
language-tag.pdf. 

*	Schema: This schema describes the extension mapping for the IDN language tag. The 
mapping extends the EPP domain name mapping to provide additional features required for 
the provisioning of IDN domain name registrations.

〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ?〉

〈schema targetNamespace=ʺhttp:⁄⁄www.Verisign.com⁄epp⁄idnLang-1.0ʺ
  xmlns:idnLang=ʺhttp:⁄⁄www.Verisign.com⁄epp⁄idnLang-1.0ʺ
  xmlns=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
  elementFormDefault=ʺqualifiedʺ〉

〈annotation〉
  〈documentation〉
    Extensible Provisioning Protocol v1.0 domain name
    extension schema for IDN Lang Tag.
  〈⁄documentation〉
〈⁄annotation〉

〈!--
Child elements found in EPP commands.
--〉
  〈element name=ʺtagʺ type=ʺlanguageʺ⁄〉

  〈!--
  End of schema.
  --〉
〈⁄schema〉

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


XML templates⁄schema for rgp-poll-1.0 (RGP Poll Mapping)

*	Template: The templates for rgp-poll-1.0 can be found in Chapter 3, EPP Command 
Mapping of the relevant EPP documentation, http:⁄⁄www.verisigninc.com⁄assets⁄rgp-poll-
mapping.pdf.
*	Schema: This schema describes the extension mapping for poll notifications. The mapping 
extends the EPP base mapping to provide additional features for registry grace period 
(RGP) poll notifications.


〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ?〉

〈schema targetNamespace=ʺhttp:⁄⁄www.Verisign.com⁄epp⁄rgp-poll-1.0ʺ
  xmlns:rgp-poll=ʺhttp:⁄⁄www.Verisign.com⁄epp⁄rgp-poll-1.0ʺ
  xmlns:eppcom=ʺurn:ietf:params:xml:ns:eppcom-1.0ʺ
  xmlns:rgp=ʺurn:ietf:params:xml:ns:rgp-1.0ʺ
  xmlns=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
  elementFormDefault=ʺqualifiedʺ〉

〈!--
Import common element types.
--〉
〈import namespace=ʺurn:ietf:params:xml:ns:eppcom-1.0ʺ
  schemaLocation=ʺeppcom-1.0.xsdʺ⁄〉
〈import namespace=ʺurn:ietf:params:xml:ns:rgp-1.0ʺ
  schemaLocation=ʺrgp-1.0.xsdʺ⁄〉

〈annotation〉
  〈documentation〉
    Extensible Provisioning Protocol v1.0
    Verisign poll notification specification for registry grace period
    poll notifications.
  〈⁄documentation〉
〈⁄annotation〉

〈!--
Child elements found in EPP commands.
--〉
〈element name=ʺpollDataʺ type=ʺrgp-poll:pollDataTypeʺ⁄〉

〈!--
Child elements of the 〈notifyData〉 element for the
redemption grace period.
--〉
〈complexType name=ʺpollDataTypeʺ〉
  〈sequence〉
    〈element name=ʺnameʺ type=ʺeppcom:labelTypeʺ⁄〉
    〈element name=ʺrgpStatusʺ type=ʺrgp:statusTypeʺ⁄〉
    〈element name=ʺreqDateʺ type=ʺdateTimeʺ⁄〉
    〈element name=ʺreportDueDateʺ type=ʺdateTimeʺ⁄〉
  〈⁄sequence〉
〈⁄complexType〉
〈
!--
End of schema.
--〉
〈⁄schema〉

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

XML templates⁄schema for whoisInf-1.0 (Whois Info Extension)

*	Template: The templates for whoisInf-1.0 can be found in Chapter 3, EPP Command 
Mapping of the relevant EPP documentation, http:⁄⁄www.verisigninc.com⁄assets⁄whois-info-
extension.pdf.
*	Schema: This schema describes the extension mapping for the Whois Info extension. The 
mapping extends the EPP domain name mapping to provide additional features for returning 
additional information needed for transfers.


〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ?〉

〈schema targetNamespace=ʺhttp:⁄⁄www.Verisign.com⁄epp⁄whoisInf-1.0ʺ
  xmlns:whoisInf=ʺhttp:⁄⁄www.Verisign.com⁄epp⁄whoisInf-1.0ʺ
  xmlns:eppcom=ʺurn:ietf:params:xml:ns:eppcom-1.0ʺ
  xmlns=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
  elementFormDefault=ʺqualifiedʺ〉

〈import namespace=ʺurn:ietf:params:xml:ns:eppcom-1.0ʺ
  schemaLocation=ʺeppcom-1.0.xsdʺ⁄〉

〈annotation〉
  〈documentation〉
    Extensible Provisioning Protocol v1.0
    extension schema for Whois Info
  〈⁄documentation〉
〈⁄annotation〉

〈!--
Possible Whois Info extension root elements.
--〉
〈element name=ʺwhoisInfʺ type=ʺwhoisInf:whoisInfTypeʺ⁄〉
〈element name=ʺwhoisInfDataʺ type=ʺwhoisInf:whoisInfDataTypeʺ⁄〉

〈!--
Child elements for the 〈whoisInf〉 extension which
is used as an extension to an info command.
--〉
〈complexType name=ʺwhoisInfTypeʺ〉
  〈sequence〉
    〈element name=ʺflagʺ type=ʺbooleanʺ⁄〉
  〈⁄sequence〉
〈⁄complexType〉

〈!--
Child elements for the 〈whoisInfData〉 extension which
is used as an extension to the info response.
--〉
〈complexType name=ʺwhoisInfDataTypeʺ〉
  〈sequence〉
  〈element name=ʺregistrarʺ type=ʺstringʺ⁄〉
  〈element name=ʺwhoisServerʺ type=ʺeppcom:labelTypeʺ
    minOccurs=ʺ0ʺ⁄〉
  〈element name=ʺurlʺ type=ʺtokenʺ minOccurs=ʺ0ʺ⁄〉
  〈element name=ʺirisServerʺ type=ʺeppcom:labelTypeʺ
    minOccurs=ʺ0ʺ⁄〉
  〈⁄sequence〉
  〈⁄complexType〉

〈⁄schema〉

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

XML templates⁄schema for sync-1.0 (EPP ConsoliDate Mapping)

*	Template: The templates for sync-1.0 can be found in Chapter 3, EPP Command Mapping 
of the relevant EPP documentation, http:⁄⁄www.verisigninc.com⁄assets⁄consolidate-
mapping.txt.
*	Schema: This schema describes the extension mapping for the synchronization of domain 
name registration period expiration dates. This service is known as ʺConsoliDate.ʺ The 
mapping extends the EPP domain name mapping to provide features that allow a protocol 
client to end a domain name registration period on a specific month and day.


 〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ?〉

   〈schema targetNamespace=ʺhttp:⁄⁄www.Verisign.com⁄epp⁄sync-1.0ʺ
           xmlns:sync=ʺhttp:⁄⁄www.Verisign.com⁄epp⁄sync-1.0ʺ
           xmlns=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
           elementFormDefault=ʺqualifiedʺ〉

     〈annotation〉
       〈documentation〉
         Extensible Provisioning Protocol v1.0 domain name
         extension schema for expiration date synchronization.
       〈⁄documentation〉
     〈⁄annotation〉

   〈!--
   Child elements found in EPP commands.
   --〉
     〈element name=ʺupdateʺ type=ʺsync:updateTypeʺ⁄〉

   〈!--
   Child elements of the 〈update〉 command.
   --〉
     〈complexType name=ʺupdateTypeʺ〉
       〈sequence〉
         〈element name=ʺexpMonthDayʺ type=ʺgMonthDayʺ⁄〉
       〈⁄sequence〉
     〈⁄complexType〉

   〈!--
   End of schema.
   --〉
   〈⁄schema〉

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

XML templates⁄schema for namestoreExt-1.1 (NameStore Extension)

*	Template: The templates for namestoreExt-1.1 can be found in Chapter 3, EPP Command 
Mapping of the relevant EPP documentation, http:⁄⁄www.verisigninc.com⁄assets⁄namestore-
extension.pdf.
*	Schema: This schema describes the extension mapping for the routing with an EPP 
intelligent gateway to a pluggable set of backend products and services. The mapping 
extends the EPP domain name and host mapping to provide a sub-product identifier to 
identify the target sub-product that the EPP operation is intended for.


〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ?〉

〈schema targetNamespace=ʺhttp:⁄⁄www.Verisign-grs.com⁄epp⁄namestoreExt-1.1ʺ
  xmlns=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
  xmlns:namestoreExt=ʺhttp:⁄⁄www.Verisign-grs.com⁄epp⁄namestoreExt-1.1ʺ
  elementFormDefault=ʺqualifiedʺ〉

〈annotation〉
  〈documentation〉
    Extensible Provisioning Protocol v1.0 Namestore extension schema
    for destination registry routing.
  〈⁄documentation〉
〈⁄annotation〉

〈!-- General Data types. --〉
〈simpleType name=ʺsubProductTypeʺ〉
  〈restriction base=ʺtokenʺ〉
    〈minLength value=ʺ1ʺ⁄〉
    〈maxLength value=ʺ64ʺ⁄〉
  〈⁄restriction〉
〈⁄simpleType〉

〈complexType name=ʺextAnyTypeʺ〉
  〈sequence〉
    〈any namespace=ʺ##otherʺ maxOccurs=ʺunboundedʺ⁄〉
  〈⁄sequence〉
〈⁄complexType〉

〈!-- Child elements found in EPP commands and responses. --〉
〈element name=ʺnamestoreExtʺ type=ʺnamestoreExt:namestoreExtTypeʺ⁄〉

〈!-- Child elements of the 〈product〉 command. --〉
〈complexType name=ʺnamestoreExtTypeʺ〉
  〈sequence〉
    〈element name=ʺsubProductʺ
      type=ʺnamestoreExt:subProductTypeʺ⁄〉
  〈⁄sequence〉
〈⁄complexType〉

〈!-- Child response elements. --〉
〈element name=ʺnsExtErrDataʺ type=ʺnamestoreExt:nsExtErrDataTypeʺ⁄〉

〈!-- 〈prdErrData〉 error response elements. --〉
〈complexType name=ʺnsExtErrDataTypeʺ〉
  〈sequence〉
    〈element name=ʺmsgʺ type=ʺnamestoreExt:msgTypeʺ⁄〉
  〈⁄sequence〉
  〈⁄complexType〉

〈!-- 〈prdErrData〉 〈msg〉 element. --〉
〈complexType name=ʺmsgTypeʺ〉
  〈simpleContent〉
    〈extension base=ʺnormalizedStringʺ〉
      〈attribute name=ʺcodeʺ
        type=ʺnamestoreExt:prdErrCodeTypeʺ use=ʺrequiredʺ⁄〉
      〈attribute name=ʺlangʺ type=ʺlanguageʺ default=ʺenʺ⁄〉
    〈⁄extension〉
  〈⁄simpleContent〉
〈⁄complexType〉

〈!-- 〈prdErrData〉 error response codes. --〉
〈simpleType name=ʺprdErrCodeTypeʺ〉
  〈restriction base=ʺunsignedShortʺ〉
    〈enumeration value=ʺ1ʺ⁄〉
  〈⁄restriction〉
〈⁄simpleType〉

〈!-- End of schema. --〉
〈⁄schema〉

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

XML templates⁄schema for lowbalance-poll-1.0 (Low Balance Mapping)

*	Template: The templates for lowbalance-poll-1.0 can be found in Chapter 3, EPP 
Command Mapping of the relevant EPP documentation, 
http:⁄⁄www.verisigninc.com⁄assets⁄low-balance-mapping.pdf.
*	Schema: This schema describes the extension mapping for the account low balance 
notification. The mapping extends the EPP base mapping so an account holder can be 
notified via EPP poll messages whenever the available credit for an account reaches or 
goes below the credit threshold.


〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ?〉

〈schema targetNamespace=ʺhttp:⁄⁄www.Verisign.com⁄epp⁄lowbalance-poll-1.0ʺ
  xmlns:lowbalance-poll=ʺhttp:⁄⁄www.Verisign.com⁄epp⁄lowbalance-poll-1.0ʺ
  xmlns:eppcom=ʺurn:ietf:params:xml:ns:eppcom-1.0ʺ
  xmlns=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
  elementFormDefault=ʺqualifiedʺ〉

〈!-- Import common element types.--〉
〈import namespace=ʺurn:ietf:params:xml:ns:eppcom-1.0ʺ
  schemaLocation=ʺeppcom-1.0.xsdʺ⁄〉

〈annotation〉
  〈documentation〉
    Extensible Provisioning Protocol v1.0
    Verisign poll notification specification for low balance notifications.
  〈⁄documentation〉
〈⁄annotation〉

〈!--Child elements found in EPP commands.--〉
〈element name=ʺpollDataʺ type=ʺlowbalance-poll:pollDataTypeʺ⁄〉

〈!--Child elements of the 〈notifyData〉 element for the low balance.--〉
〈complexType name=ʺpollDataTypeʺ〉
  〈sequence〉
    〈element name=ʺregistrarNameʺ type=ʺeppcom:labelTypeʺ⁄〉
    〈element name=ʺcreditLimitʺ type=ʺnormalizedStringʺ⁄〉
    〈element name=ʺcreditThresholdʺ
      type=ʺlowbalance-poll:thresholdTypeʺ⁄〉
    〈element name=ʺavailableCreditʺ type=ʺnormalizedStringʺ⁄〉
  〈⁄sequence〉
〈⁄complexType〉

〈complexType name=ʺthresholdTypeʺ〉
  〈simpleContent〉
    〈extension base=ʺnormalizedStringʺ〉
      〈attribute name=ʺtypeʺ
        type=ʺlowbalance-poll:thresholdValueTypeʺ
        use=ʺrequiredʺ⁄〉
    〈⁄extension〉
  〈⁄simpleContent〉
〈⁄complexType〉

〈simpleType name=ʺthresholdValueTypeʺ〉
  〈restriction base=ʺtokenʺ〉
    〈enumeration value=ʺFIXEDʺ⁄〉
    〈enumeration value=ʺPERCENTʺ⁄〉
  〈⁄restriction〉
〈⁄simpleType〉

〈!-- End of schema.--〉
〈⁄schema〉




6	PROPRIETARY EPP EXTENSION CONSISTENCY WITH REGISTRATION LIFECYCLE 

Verisign’s proprietary EPP extensions, defined in Section 5 above, are consistent with the 
registration lifecycle documented in the response to Question 27, Registration Lifecycle.  Details 
of the registration lifecycle are presented in that response. As new registry features are 
required, we develop proprietary EPP extensions to address new operational requirements. 
Consistent with ICANN procedures we adhere to all applicable Registry Services Evaluation 
Process (RSEP) procedures.

1 COMPLETE KNOWLEDGE AND UNDERSTANDING OF THIS ASPECT OF REGISTRY TECHNICAL REQUIREMENTS

Verisign has operated the Whois lookup service for the gTLDs and ccTLDs we manage since
1991, and will provide these proven services for the ARABIC_TRANSLITERATION_OF_.COM gTLD registry. In
addition, we continue to work with the Internet community to improve the utility of Whois data,
while thwarting its application for abusive uses.

1.1 High-Level Whois System Description

Like all other components of our registry service, our Whois system is designed and built for
both reliability and performance in full compliance with applicable RFCs. Our current Whois
implementation has answered more than five billion Whois queries per month for the TLDs we
manage, and has experienced more than 250,000 queries per minute in peak conditions. The
proposed gTLD uses a Whois system design and approach that is comparable to the current
implementation. Independent quality control testing ensures our Whois service is RFC-
compliant through all phases of its lifecycle.

Our redundant Whois databases further contribute to overall system availability and reliability.
The hardware and software for our Whois service is architected to scale both horizontally (by
adding more servers) and vertically (by adding more CPUs and memory to existing servers) to
meet future need.

We can fine-tune access to our Whois database on an individual Internet Protocol (IP) address
basis, and we work with registrars to help ensure their services are not limited by any restriction
placed on Whois. We provide near real-time updates for Whois services for the TLDs under our
management. As information is updated in the registration database, it is propagated to the
Whois servers for quick publication. These updates align with the near real-time publication of
Domain Name System (DNS) information as it is updated in the registration database. This
capability is important for the ARABIC_TRANSLITERATION_OF_.COM gTLD registry as it is Verisign’s experience
that when DNS data is updated in near real time, so should Whois data be updated to reflect the
registration specifics of those domain names.

Verisign’s Whois response time has been less than 500 milliseconds for 95 percent of all Whois
queries in .com, .net, .tv, and .cc. The response time in these TLDs, combined with our
capacity, enables the Whois system to respond to up to 30,000 searches (or queries) per
second for a total capacity of 2.6 billion queries per day.

The Whois software written by Verisign complies with RFC 3912. We use an advanced in-
memory database technology to provide exceptional overall system performance and security.
In accordance with RFC 3912, we provide a website at whois.nic.〈TLD〉 that provides free
public query-based access to the registration data.

We currently operate both thin and thick Whois systems.

Verisign commits to implementing a RESTful Whois service upon finalization of the relevant
standards and protocols by the IETF (Internet Engineering Task Force).

Provided Functionalities for User Interface

To use the Whois service via port 43, the user enters the applicable parameter on the command
line as illustrated here:

* For domain name: whois EXAMPLE.TLD

* For registrar: whois ʺregistrar Example Registrar, Inc.ʺ

* For name server: whois ʺNS1.EXAMPLE.TLDʺ or whois ʺname server (IP address)ʺ

To use the Whois service via the web-based directory service search interface:

* Go to http:⁄⁄whois.nic.〈TLD〉

* Click on the appropriate button (Domain, Registrar, or Name Server)

* Enter the applicable parameter:
a. Domain name, including the TLD (e.g., EXAMPLE.TLD)
b. Full name of the registrar, including punctuation (e.g., Example Registrar, Inc.)
c. Full host name or the IP address (e.g., NS1.EXAMPLE.TLD or 198.41.3.39)

* Click on the Submit button.

Provisions to Ensure That Access Is Limited to Legitimate Authorized Users and Is in Compliance
with Applicable Privacy Laws or Policies

To further promote reliable and secure Whois operations, Verisign has implemented rate-limiting
characteristics within the Whois service software. For example, to prevent data mining or other
abusive behavior, the service can throttle a specific requestor if the query rate exceeds a
configurable threshold. In addition, QoS technology enables rate limiting of queries before they
reach the servers, which helps protect against denial of service (DoS) and distributed denial of
service (DDoS) attacks.

Our software also permits restrictions on search capabilities. For example, wild card searches
can be disabled. If needed, 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. Furthermore, we are
European Union (EU) Safe Harbor certified and have worked with European data protection
authorities to address applicable privacy laws by developing a tiered Whois access structure
that requires users who require access to more extensive data to (i) identify themselves, (ii)
confirm that their use is for a specified purpose and (iii) enter into an agreement governing their
use of the more extensive Whois data.

1.2 Relevant Network Diagrams

Figure 26-1 (see Attachment VRSN_.comAra_Q26 Figures for all figures in this
response) provides a summary network diagram of the Whois service provided by Verisign. The
figure details the configuration with one resolution⁄Whois site. For the ARABIC_TRANSLITERATION_OF_.COM
gTLD, we provide Whois service from six of our 17 primary sites based on the proposed gTLD’s
traffic volume and patterns. A functionally equivalent resolution architecture configuration exists
at each Whois site.

1.3 IT and Infrastructure Resources

Figure 26-2 summarizes the IT and infrastructure resources that Verisign uses to provision
Whois services from Verisign primary resolution sites. As needed, virtual machines are created
based on actual and projected demand.

1.4 Description of Interconnectivity with Other Registry Systems

Figure 26-3 provides a technical overview of Verisign’s registry system, and shows how the
Whois service component fits into this larger system and interconnects with other system
components.

1.5 Frequency of Synchronization Between Servers

Synchronization between the SRS and the geographically distributed Whois resolution sites
occurs approximately every three minutes. We use a two-part Whois update process to ensure
Whois data is accurate and available. Every 12 hours an initial file is distributed to each
resolution site. This file is a complete copy of all Whois data fields associated with each domain
name under management. As interactions with the SRS cause the Whois data to be changed,
these incremental changes are distributed to the resolution sites as an incremental file update.
This incremental update occurs approximately every three minutes. When the new 12-hour full
update is distributed, this file includes all past incremental updates. Our approach to frequency
of synchronization between servers meets the Performance Specifications defined in
Specification 10 of the Registry Agreement for new gTLDs.

2 TECHNICAL PLAN SCOPE⁄SCALE CONSISTENT WITH THE OVERALL BUSINESS APPROACH
AND PLANNED SIZE OF THE REGISTRY

Our scaling models are proven predictors of needed capacity and related cost. As such, they
provide the means to link the projected infrastructure needs of the ARABIC_TRANSLITERATION_OF_.COM gTLD
with necessary implementation and sustainment cost. Using the projected usage volume for the
most likely scenario (defined in Question 46, Template 1 – Financial Projections: Most Likely) as
an input to our scaling models, we derived the necessary infrastructure required to implement
and sustain this gTLD. Cost related to this infrastructure is provided as “Total Critical Registry
Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46 financial projections
response.

3 TECHNICAL PLAN THAT IS ADEQUATELY RESOURCED IN THE PLANNED COSTS DETAILED
IN THE FINANCIAL SECTION

As an experienced backend registry provider, we have developed a set of proprietary resourcing
models to project the number and type of personnel resources necessary to operate a TLD. We
routinely adjust these staffing models to account for new tools and process innovations. These
models enable us to continually right-size our staff to accommodate projected demand and
meet service level agreements as well as Internet security and stability requirements. Using the
projected usage volume for the most likely scenario (defined in Question 46, Template 1 –
Financial Projections: Most Likely) as an input to our staffing models, we derived the necessary
personnel levels required for this gTLD’s initial implementation and ongoing maintenance.
Cost related to this infrastructure is provided as “Total Critical Registry Function Cash Outflows”
(Template 1, Line IIb.G) within the Question 46 financial projections response.

We employ more than 1,040 individuals of which more than 775 comprise our technical work
force. (Current statistics are publicly available in our quarterly filings.) Drawing from this pool of
on-hand and fully committed technical resources, we have maintained DNS operational
accuracy and stability 100 percent of the time for more than 13 years for .com, proving our
ability to align personnel resource growth to the scale increases of our TLD service offerings.

We project we will use the following personnel roles, which are described in Section 5 of the
response to Question 31, Technical Overview of Proposed Registry, to support Whois services:

* Application Engineers: 19
* Database Engineers: 3
* Quality Assurance Engineers: 11

4 COMPLIANCE WITH RELEVANT RFC

Verisign’s Whois service complies with the data formats defined in Specification 4 of the
Registry Agreement. We will provision Whois services for registered domain names and
associated data in the top-level domain (TLD). Our Whois services are accessible over Internet
Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6), via both Transmission Control
Protocol (TCP) port 43 and a web-based directory service at whois.nic.〈TLD〉, which in
accordance with RFC 3912, provides free public query-based access to domain name, registrar,
and name server lookups. Our proposed Whois system meets all requirements as defined by
ICANN for each registry under our management. Evidence of this successful implementation,
and thus compliance with the applicable RFCs, can be verified by a review of the .com and .net
Registry Operator’s Monthly Reports that we file with ICANN. These reports provide evidence of
our ability to meet registry operation service level agreements (SLAs) comparable to those
detailed in Specification 10. The reports are accessible at the following URL:
http:⁄⁄www.icann.org⁄en⁄tlds⁄monthly-reports⁄.

5 COMPLIANCE WITH SPECIFICATIONS 4 AND 10 OF REGISTRY AGREEMENT

In accordance with Specification 4, Verisign provides a Whois service that is available via both
port 43 in accordance with RFC 3912, and a web-based directory service at whois.nic.〈TLD〉
also in accordance with RFC 3912, thereby providing free public query-based access. We
acknowledge that ICANN reserves the right to specify alternative formats and protocols, and
upon such specification, we will implement such alternative specification as soon as reasonably
practicable.

The format of the following data fields conforms to the mappings specified in Extensible
Provisioning Protocol (EPP) RFCs 5730 – 5734 so the display of this information (or values
returned in Whois responses) can be uniformly processed and understood: domain name
status, individual and organizational names, address, street, city, state⁄province, postal code,
country, telephone and fax numbers, email addresses, date, and times.

Specifications for data objects, bulk access, and lookups comply with Specification 4 and are
detailed in the following subsections, provided in both bulk access and lookup modes.

Bulk Access Mode

This data is provided on a daily schedule to a party designated from time to time in writing by
ICANN. The specification of the content and format of this data, and the procedures for
providing access, shall be as stated below, until revised in the ICANN Registry Agreement.

The data is provided in three files:

* Domain Name File: For each domain name, the file provides the domain name, server
name for each name server, registrar ID, and updated date.

* Name Server File: For each registered name server, the file provides the server name,
each IP address, registrar ID, and updated date.

* Registrar File: For each registrar, the following data elements are provided: registrar ID,
registrar address, registrar telephone number, registrar email address, Whois server,
referral URL, updated date, and the name, telephone number, and email address of all
the registrarʹs administrative, billing, and technical contacts.

Lookup Mode

Figures 26-4 through Figure 26-6 provide the query and response format for domain name,
registrar, and name server data objects

5.1 Specification 10, RDDS Registry Performance Specifications

Verisign’s Whois service meets all registration data directory services (RDDS) registry
performance specifications detailed in Specification 10, Section 2. Evidence of this performance
can be verified by a review of the .com and .net Registry Operator’s Monthly Reports that we file
monthly with ICANN. These reports are accessible from the ICANN website at the following
URL: http:⁄⁄www.icann.org⁄en⁄tlds⁄monthly-reports⁄.

In accordance with RDDS registry performance specifications detailed in Specification 10, our
Whois service meets the following proven performance attributes:

* RDDS availability: Fewer than or equal to 864 min of downtime (approximately 98%)

* RDDS query RTT: Fewer than or equal to 2000 ms, for at least 95% of the queries

* RDDS update time: Fewer than or equal to 60 min, for at least 95% of the probes

6 SEARCHABLE WHOIS

Verisign provides a searchable Whois service for the ARABIC_TRANSLITERATION_OF_.COM gTLD. We have
experience in providing tiered access to Whois for the .name registry, and we use these
methods and control structures to help reduce potential malicious use of the function. The
searchable Whois system currently uses Apache’s Lucene full text search engine to index
relevant Whois content with near-real time incremental updates from the provisioning system.

Features of our searchable Whois function include:

* Provision of a web-based searchable directory service

* Ability to perform partial match, at least, for the following data fields: domain name,
contacts and registrant’s name, and contact and registrant’s postal address, including all
the sub-fields described in EPP (e.g., street, city, state, or province)

* Ability to perform exact match, at least, on the following fields: registrar ID, name server
name, and name server’s IP address (only applies to IP addresses stored by the
registry, i.e., glue records)

* Ability to perform Boolean search supporting, at least, the following logical operators to
join a set of search criteria: AND, OR, NOT

* Search results that include domain names that match the selected search criteria

Our implementation of searchable Whois is EU Safe Harbor certified and includes appropriate
access control measures that help ensure that only legitimate authorized users can use the
service. Furthermore, our compliance office monitors current ICANN policy and applicable
privacy laws or policies to help ensure the solution is maintained within compliance of applicable
regulations. Features of these access control measures include:

* All unauthenticated searches are returned as thin results.

* Registry system authentication is used to grant access to appropriate users for thick
Whois data search results.

* Account access is granted by our defined ARABIC_TRANSLITERATION_OF_.COM gTLD admin user.

Potential Forms of Abuse and Related Risk Mitigation

Leveraging our experience providing tiered access to Whois for the .name registry and interacting
with ICANN, data protection authorities, and applicable industry groups, we are knowledgeable of the
likely data mining forms of abuse associated with a searchable Whois service. Figure 26-7 summarizes these
potential forms of abuse and our approach to mitigate the identified risk.

1 COMPLETE KNOWLEDGE AND UNDERSTANDING OF REGISTRATION LIFECYCLES AND STATES

Verisign’s registry implements the full registration lifecycle for domain names supporting the
operations in the Extensible Provisioning Protocol (EPP) specification. The registration lifecycle
of the domain name starts with registration and traverses various states as specified in the
following sections. The registry system provides options to update domain names with different
server and client status codes that block operations based on the EPP specification. The
system also provides different grace periods for different billable operations, where the price of
the billable operation is credited back to the registrar if the billable operation is removed within
the grace period. Together Figure 27-1 and Figure 27-2 (see Attachment VRSN_.comAra_Q27
Figures for all figures in this response) define the registration states comprising the registration
lifecycle and explain the trigger points that cause state-to-state transitions. States are
represented as green rectangles within Figure 27-1.

1.1 Registration Lifecycle of Create⁄Update⁄Delete

The following section details the create⁄update⁄delete processes and the related renewal
process that we follow. For each process, this response defines the process function and its
characterization, and as appropriate provides a process flow chart.

Create Process
The domain name lifecycle begins with a registration or what is referred to as a Domain Name
Create operation in EPP. The system fully supports the EPP Domain Name Mapping as defined
by RFC 5731, where the associated objects (e.g., hosts and contacts) are created independent
of the domain name.

Process Characterization
The Domain Name Create command is received, validated, run through a set of business rules,
persisted to the database, and committed in the database if all business rules pass. The domain
name is included with the data flow to the DNS and Whois resolution services. If no name
servers are supplied, the domain name is not included with the data flow to the DNS. A
successfully created domain name has the created date and expiration date set in the database.
Creates are subject to grace periods as described in Section 1.3 of this response.

The Domain Name Create operation (Figure 27-3) requires the following attributes:

* Domain name meets the string restrictions.
* Domain name does not already exist.
* Registrar is authorized to create a domain name in
ARABIC_TRANSLITERATION_OF_.COM.
* Registrar has available credit.
* Authorization Information (Auth-Info) value is valid.
* Required contacts (e.g., registrant, administrative contact, technical contact, and billing
contact) are specified and exist.
* Specified name servers (hosts) exist, and there is a maximum of 13 name servers.
* Period in units of years with a maximum value of 10 (default period is one year).

Renewal Process
The domain name can be renewed unless it has any form of Pending Delete, Pending Transfer,
or Renew Prohibited.

A request for renewal that sets the expiry date to more than ten years in the future is denied.
The registrar must pass the current expiration date (without the timestamp) to support the
idempotent features of EPP, where sending the same command a second time does not cause
unexpected side effects.

Automatic renewal occurs when a domain name expires. On the expiration date, the registry
extends the registration period one year and debits the registrar account balance. In the case of
an auto-renewal of the domain name, a separate Auto-Renew grace period applies. Renewals
are subject to grace periods as described in Section 1.3 of this response.

Process Characterization
The Domain Name Renew command is received, validated, authorized, and run through a set of
business rules. The data is updated and committed in the database if it passes all business
rules. The updated domain name’s expiration date is included in the flow to the Whois resolution
service.

The Domain Name Renew operation (Figure 27-4) requires the following attributes:
* Domain name exists and is sponsored by the requesting registrar.
* Registrar is authorized to renew a domain name in
ARABIC_TRANSLITERATION_OF_.COM.
* Registrar has available credit.
* Passed current expiration date matches the domain name’s expiration date.
* Period in units of years with a maximum value of 10 (default period is one year). A domain
name expiry past ten years is not allowed.

Registrar Transfer Procedures
A registrant may transfer the domain name from the current registrar to another registrar. The
database system allows a transfer as long as the transfer is not within the initial 60 days, per
industry standard, of the original registration date.

The registrar transfer process goes through many process states, which are described in detail
below, unless it has any form of Pending Delete, Pending Transfer, or Transfer Prohibited.

A transfer can only be initiated when the appropriate Auth-Info is supplied. The Auth-Info for
transfer is only available to the current registrar. Any other registrar requesting to initiate a
transfer on behalf of a registrant must obtain the Auth-Info from the registrant.

The Auth-Info is available to the registrant upon request. The registrant is the only party other
than the current registrar that has access to the Auth-Info. Registrar transfer entails a specified
extension of the expiry date for the object. The registrar transfer is a billable operation and is
charged identically to a renewal for the same extension of the period. This period can be from
one to ten years, in one-year increments.

Because registrar transfer involves an extension of the registration period, the rules and policies
applying to how the resulting expiry date is set after transfer are based on the renewal policies
on extension.

Per industry standard, a domain name cannot be transferred to another registrar within the first
60 days after registration. This restriction continues to apply if the domain name is renewed
during the first 60 days. Transfer of the domain name changes the sponsoring registrar of the
domain name, and also changes the child hosts (ns1.sample.xyz) of the domain name (sample
.xyz).

The domain name transfer consists of five separate operations:

* Transfer Request (Figure 27-5): Executed by a non-sponsoring registrar with the valid
Auth-Info provided by the registrant. The Transfer Request holds funds of the requesting
registrar but does not bill the registrar until the transfer is completed. The sponsoring
registrar receives a Transfer Request poll message.
* Transfer Cancel (Figure 27-6): Executed by the requesting registrar to cancel the pending
transfer. The held funds of the requesting registrar are reversed. The sponsoring registrar
receives a Transfer Cancel poll message.
* Transfer Approve (Figure 27-7): Executed by the sponsoring registrar to approve the
Transfer Request. The requesting registrar is billed for the Transfer Request and the
sponsoring registrar is credited for an applicable Auto-Renew grace period. The requesting
registrar receives a Transfer Approve poll message.
* Transfer Reject (Figure 27-8): Executed by the sponsoring registrar to reject the pending
transfer. The held funds of the requesting registrar are reversed. The requesting registrar
receives a Transfer Reject poll message.
* Transfer Query (Figure 27-9): Executed by either the requesting registrar or the sponsoring
registrar of the last transfer.

The registry auto-approves a transfer if the sponsoring registrar takes no action. The requesting
registrar is billed for the Transfer Request and the sponsoring registrar is credited for an
applicable Auto-Renew grace period. The requesting registrar and the sponsoring registrar
receive a Transfer Auto-Approve poll message.

Delete Process
A registrar may choose to delete the domain name at any time.

Process Characterization
The domain name can be deleted, unless it has any form of Pending Delete, Pending Transfer,
or Delete Prohibited.

A domain name is also prohibited from deletion if it has any in-zone child hosts that are name
servers for domain names. For example, the domain name “sample.xyz” cannot be deleted if an
in-zone host “ns.sample.xyz” exists and is a name server for “sample2.xyz.”

If the Domain Name Delete occurs within the Add grace period, the domain name is
immediately deleted and the sponsoring registrar is credited for the Domain Name Create. If the
Domain Name Delete occurs outside the Add grace period, it follows the Redemption grace
period (RGP) lifecycle.

Update Process
The sponsoring registrar can update the following attributes of a domain name:

* Auth-Info
* Name servers
* Contacts
* Statuses (e.g., Client Delete Prohibited, Client Hold, Client Renew Prohibited, Client
Transfer Prohibited, Client Update Prohibited)

Process Characterization
Updates are allowed provided that the update includes the removal of any Update Prohibited
status. The Domain Name Update operation is detailed in Figure 27-10.

A domain name can be updated unless it has any form of Pending Delete, Pending Transfer, or
Update Prohibited.

1.2 Pending, Locked, Expired, and Transferred

Verisign handles pending, locked, expired, and transferred domain names as described here.
When the domain name is deleted after the five-day Add grace period, it enters into the Pending
Delete state. The registrant can return its domain name to active any time within the five-day
Pending Delete grace period. After the five-day Pending Delete grace period expires, the
domain name enters the Redemption Pending state and then is deleted by the system. The
registrant can restore the domain name at any time during the Redemption Pending state.

When a non-sponsoring registrar initiates the domain name transfer request, the domain name
enters Pending Transfer state and a notification is mailed to the sponsoring registrar for
approvals. If the sponsoring registrar doesn’t respond within five days, the Pending Transfer
expires and the transfer request is automatically approved.

EPP specifies both client (registrar) and server (registry) status codes that can be used to
prevent registry changes that are not intended by the registrant. Currently, many registrars use
the client status codes to protect against inadvertent modifications that would affect their
customers’ high-profile or valuable domain names.

Verisign’s registry service supports the following client (registrar) and server (registry) status
codes:

* clientHold
* clientRenewProhibited
* clientTransferProhibited
* clientUpdateProhibited
* clientDeleteProhibited
* serverHold
* serverRenewProhibited
* serverTransferProhibited
* serverUpdateProhibited
* serverDeleteProhibited

1.3 Add Grace Period, Redemption Grace Period, and Notice Periods for Renewals or Transfers

* Add Grace Period: The Add grace period is a specified number of days following the initial
registration of the domain name. The current value of the Add grace period for all registrars
is five days.

* Redemption Grace Period: If the domain name is deleted after the five-day grace period
expires, it enters the Redemption grace period and then is deleted by the system. The
registrant has an option to use the Restore Request command to restore the domain name
within the Redemption grace period. In this scenario, the domain name goes to Pending
Restore state if there is a Restore Request command within 30 days of the Redemption
grace period. From the Pending Restore state, it goes either to the OK state, if there is a
Restore Report Submission command within seven days of the Restore Request grace
period, or a Redemption Period state if there is no Restore Report Submission command
within seven days of the Restore Request grace period.

* Renew Grace Period: The Renew⁄Extend grace period is a specified number of days
following the renewal⁄extension of the domain name’s registration period. The current value
of the Renew⁄Extend grace period is five days.

* Auto-Renew Grace Period: All auto-renewed domain names have a grace period of 45
days.

* Transfer Grace Period: Domain names have a five-day Transfer grace period.

1.4 Aspects of the Registration Lifecycle Not Covered by Standard EPP RFCs

Our registration lifecycle processes and code implementations adhere to the standard EPP
RFCs related to the registration lifecycle. By adhering to the RFCs, our registration lifecycle is
complete and addresses each registration-related task comprising the lifecycle. No aspect of
our registration lifecycle is not covered by one of the standard EPP RFCs and thus no additional
definitions are provided in this response.

2 CONSISTENCY WITH ANY SPECIFIC COMMITMENTS MADE TO REGISTRANTS AS ADAPTED
TO THE OVERALL BUSINESS APPROACH FOR THE PROPOSED gTLD

The registration lifecycle described above applies to the
ARABIC_TRANSLITERATION_OF_.COM gTLD as well as other TLDs managed by Verisign;
thus we remain consistent with commitments made to our registrants. No unique or specific
registration lifecycle modifications or adaptations are required to support the overall business
approach for the ARABIC_TRANSLITERATION_OF_.COM gTLD.

3 COMPLIANCE WITH RELEVANT RFCs

Our registration lifecycle complies with RFCs 5730 – 5734 and 3915. The system fully supports
the EPP Domain Name Mapping (RFC 5731), where the associated objects (e.g., hosts and
contacts) are created independent of the domain name.

In addition, in accordance with RFCs 5732 and 5733, the registration system enforces the
following registration constraints:

* Uniqueness⁄Multiplicity: A second-level domain name is unique in the
ARABIC_TRANSLITERATION_OF_.COM database. Two identical second-level domain
names cannot simultaneously exist in ARABIC_TRANSLITERATION_OF_.COM. Further, a
second-level domain name cannot be created if it conflicts with a reserved domain name.

* Point of Contact Associations: The domain name is associated with the following points of
contact. Contacts are created and managed independently according to RFC 5733.
a. Registrant
b. Administrative contact
c. Technical contact
d. Billing contact

* Domain Name Associations: Each domain name is associated with:
a. A maximum of 13 hosts, which are created and managed independently according to
RFC 5732
b. An Auth-Info, which is used to authorize certain operations on the object
c. Status(es), which are used to describe the domain name’s status in the registry
d. A created date, updated date, and expiry date

4 DEMONSTRATES THAT TECHNICAL RESOURCES REQUIRED TO CARRY THROUGH THE PLANS FOR
THIS ELEMENT ARE ALREADY ON HAND OR READILY AVAILABLE

Verisign has developed a set of proprietary resourcing models to project the number and type of
personnel resources necessary to operate a TLD. These routinely adjusted models enable us to
continually right-size staff to meet projected demand, service level agreements, and
requirements for Internet security and stability. Using the projected usage volume for the most
likely scenario (defined in Question 46, Template 1 – Financial Projections: Most Likely) as an
input to our staffing models, we derived the personnel levels required for this gTLD’s initial
implementation and ongoing maintenance. Cost related to this infrastructure is provided as
“Total Critical Registry Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46
response.

We employ more than 1,040 individuals; more than 775 comprise our technical work force,
enabling us to draw from this pool and align personnel resource growth to the scale increases of
our TLD service offerings.

We expect to use the following personnel roles, which are described in Section 5 of the
response to Question 31, to support the registration lifecycle:

* Application Engineers: 19
* Customer Support Personnel: 36
* Database Administrators: 8
* Database Engineers: 3
* Quality Assurance Engineers: 11
* SRS System Administrators: 13

To implement and manage the ARABIC_TRANSLITERATION_OF_.COM gTLD as described in
this application, we scale, as needed, the size of each technical area now supporting our
portfolio of TLDs. Consistent with our resource modeling, we periodically review the level of
work to be performed and adjust staff levels for each technical area.

1. COMPREHENSIVE ABUSE POLICIES, WHICH INCLUDE CLEAR DEFINITIONS OF WHAT CONSTITUTES
ABUSE IN THE TLD, AND PROCEDURES THAT WILL EFFECTIVELY MINIMIZE POTENTIAL FOR ABUSE IN THE TLD

Verisign has more than 16 years’ experience in protecting our domains and Domain Name
System (DNS) from malicious abuse, and we offer multiple services, products, and policies to
combat abuse of the ARABIC_TRANSLITERATION_OF_.COM gTLD.

Definitions

Malicious abuse of the ARABIC_TRANSLITERATION_OF_.COM gTLD, where software is
disseminated to infiltrate or damage a computer system without the owner’s informed consent,
can include the following types of abuse:

* Trojan ⁄ Malware Executable(s): A malicious executable is hosted on a server.

* Trojan ⁄ Malware Drive-By: A website is crafted such that it attempts to exploit a
vulnerability in a browser or browser plugin (e.g., Flash, PDF, Java) for the purpose of
automatically downloading and installing a malicious executable on a client machine.

* Phishing: A link in an email (often sent as spam) points to fraudulent web pages⁄ website
(primarily Trojan ⁄ Malware Drive-By). These fraudulent web pages are designed to trick
recipients into divulging sensitive data such as user names or passwords.

* Command-and-Control (CnC): A server is used to send and receive commands from
infected machines (bots).

* Mass Registrations: Many different domain names are used as part of a CnC
infrastructure. The domain names are linked to a specific malware family and are registered
in close proximity to each other (time-wise) or by a common entity (malicious actor).

We offer a number of security services to protect registrants and minimize the potential for
abuse. These products include:

* Verisign MalDetector: This new commercial service enables registrars to offer malware
scanning to their customers. MalDetector analyzes a website’s content by scanning the
site’s web pages (text, video, images, ads, web code) for malware and obfuscations (hidden
malware code). If MalDetector detects malware code in the website content, it provides
remediation instructions for removing the malicious code.

* Verisign Domain Name System Security Extensions (DNSSEC) Signing Service: This
services helps registrars build the infrastructure capability to protect users from redirection to
unintended sites while reducing the cost, complexity, and administrative burden associated
with implementing DNSSEC.

* Verisign Registry Lock Service: This service enables registrars to offer server-level
protection for registrants’ ARABIC_TRANSLITERATION_OF_.COM domain name records,
thereby guarding against unintended changes, deletions, or transfers. These modification
may result in malicious use of the domain name.

* Verisign Registry-Registrar Two-Factor Authentication: Helps registrars better manage
and control communications with the Verisign registry by providing a mechanism to validate
that requested changes come from authorized personnel and update authorized contacts as
personnel changes occur.

In the case of other forms of illegal activity, we work with law enforcement personnel, as
needed, to mitigate abuse through the judicial system.

1.1 Abuse Prevention and Mitigation Implementation Plan

The security services described in the preceding section are currently implemented in the other
TLDs that Verisign operates. These services are available immediately to the
ARABIC_TRANSLITERATION_OF_.COM gTLD, without the need for additional implementation.

The ARABIC_TRANSLITERATION_OF_.COM gTLD is added to the root zone, and second-
level domain names are provisioned through Verisign’s Shared Registration System
(SRS). Registrars have the ARABIC_TRANSLITERATION_OF_.COM gTLD and the products
and services described in this application added to their account in the SRS. Registrars are
required to complete a ramp-up period during which they test their Extensible Provisioning
Protocol (EPP) client applications and services through our Operational Test Environment
(OTE). The OTE is a functional equivalent to the production environment that allows registrars
to determine whether their client applications are production ready. Once the registrar has
completed the testing and certification of its client applications and services, it is granted access
to the production environment and may begin processing domain names registrations to be
published in the ARABIC_TRANSLITERATION_OF_.COM gTLD zone.

1.2 Policies for Handling Complaints Regarding Abuse

Verisign handles complaints regarding abuse as detailed in this section.

Abuse complaints are initially addressed to the Registrar of Record (ROR). If registrars or
registrants need to escalate an abuse complaint, our Customer Service Center (CSC) is the
initial point of contact. Our Customer Support includes the 24⁄7 onsite CSC staff and on-call
support from Tier 3 teams (e.g., registry operations staff, engineers, and developers) during
non-business hours. Our primary concern is to resolve issues quickly. As such, we maintain a
formal escalation process to ensure that all issues are addressed promptly by the appropriate
person⁄teams.

Abuse complaints are first directed to the Verisign CSC, which manages the complaint through
the processes outlined in Section 3.2.2. Our CSC provides world-class support to our
customers with key performance metrics that support a timely response to customer issues,
including complaints of abuse. Team leads actively manage all access channels to ensure
appropriate responsiveness via each access channel.

1.3 Proposed Measures for Removal of Orphan Glue Records

Although orphan glue records may support correct and ordinary operation of the Domain Name
System (DNS), registry operators are required to remove orphan glue records (as defined at
http:⁄⁄www.icann.org⁄en⁄committees⁄security⁄sac048.pdf) when provided with evidence in written
form that such records are present in connection with malicious conduct. Verisign’s registration
system is specifically designed to not allow orphan glue records. Registrars are required to
delete⁄move all dependent DNS records before deleting the parent domain name.

To prevent orphan glue records, we perform the following checks before removing a domain or
name server:

Checks during domain delete:

* A parent domain name deletion transaction is not allowed if any other domain name in the
zone refers to the child name server.

* If the parent domain name is the only domain name using the child name server, then both
the domain name and the glue record are removed from the zone.

Check during explicit name server delete:

* We confirm that the current name server is not referenced by any in-zone domain name
before deleting the name server.

Zone-file impact:

* If the parent domain name references the child name server AND if other domain names in
the zone also reference it AND if the parent domain name is assigned a serverHold status,
then the parent domain name is removed from the zone file, but the name server glue
record is not.

* If no domain names reference a name server, then the zone file removes the glue record.

1.4 Resourcing Plans

Details related to resourcing plans for the initial implementation and ongoing maintenance of our
abuse plan are provided in Section 2 of this response.

1.5 Measures to Promote Whois Accuracy

Verisign performs periodic Whois reviews to verify accuracy and completeness of data for which
the registry is authoritative. For data maintained in the registry database for which the registry is
not authoritative and is therefore unable to verify registrant contact data, the registry validates
the syntax and completeness of all required contact fields during registration and modification
transactions. In addition, we coordinate with the respective registrars to promote accuracy of
these data, including periodic notifications of ICANN’s Whois Data Reminder Policy.

1.5.1 Authentication of Registrant Information

Authentication of registrant information is performed by the registrant’s registrar, since the
registry has no direct relationship with the registrant. The registration rules for
ARABIC_TRANSLITERATION_OF_.COM require creation of an AuthInfo code for each domain
name. This AuthInfo code is required to initiate a request to transfer the domain name between
registrars. Use of this authorization by the gaining registrar is intended to prevent unauthorized
transfers of domain names.

1.5.2 Regular Monitoring of Registration Data for Accuracy and Completeness

Verisign has established policies and procedures to encourage registrar compliance with
ICANN’s Whois accuracy requirements. We incorporate the following services into our full-
service registry operations.

Registrar Self Certification

Our self-certification program consists, in part, of evaluations applied equally to all operational
ICANN accredited registrars and conducted from time to time throughout the year. Process
steps are as follows:

* Verisign sends an email notification to the ICANN primary registrar contact, requesting that
the contact go to a designated URL, log in with his⁄her Web ID and password, and complete
and submit the online form. The contact must submit the form within 15 business days of
receipt of the notification.

* When the form is submitted, we send the registrar an automated email confirming that the
form was successfully submitted.

* We review the submitted form to ensure the certifications are compliant.

* We send the registrar an email notification if the registrar is found to be compliant in all
areas.

* If a review of the response indicates that the registrar is out of compliance or if we have
follow-up questions, the registrar has 10 days to respond to the inquiry.

* If the registrar does not respond within 15 business days of receiving the original
notification, or if it does not respond to the request for additional information, we send the
registrar a Breach Notice and give the registrar 30 days to cure the breach.

* If the registrar does not cure the breach, we terminate the Registry-Registrar Agreement
(RRA).

Whois Data Reminder Process

Verisign regularly reminds registrars of their obligation to comply with ICANN’s Whois Data Reminder
Policy, which was adopted by ICANN as a consensus policy on 27 March 2003
(http:⁄⁄www.icann.org⁄en⁄registrars⁄wdrp.htm). We send a notice to all registrars once a year
reminding them of their obligation to be diligent in validating the Whois information provided
during the registration process, to investigate claims of fraudulent Whois information, and to cancel
domain name registrations for which Whois information is determined to be invalid.

1.6 Malicious or Abusive Behavior Definitions, Metrics, and Service Level Requirements
for Resolution

Please see Section 1.0 for the definition of potential forms of abuse specific to the
ARABIC_TRANSLITERATION_OF_.COM gTLD. See Section 3.2.2 for a definition of Verisign’s
response procedures.

The initial response from Customer Service is within 20 seconds or less for 90% of phone calls.
Verification of malicious activity and removal of confirmed malicious infections is completed
within 24 hours.

1.7 Controls to Ensure Proper Access to Domain Functions

The following sections describe various controls that Verisign employs to ensure appropriate
access to domain functions.

1.7.1 Multi-Factor Authentication

To ensure proper access to domain functions, we incorporate our Registry-Registrar Two-Factor
Authentication Service into our full-service registry operations. The service is designed to
improve domain name security and assist registrars in protecting the accounts they manage by
providing another level of assurance that only authorized personnel can communicate with the
registry. As part of the service, dynamic one-time passwords (OTPs) augment the user names
and passwords currently used to process update, transfer, and⁄or deletion requests. These
OTPs enable transaction processing to be based on requests that are validated both by “what
users know” (i.e., their user name and password) and “what users have” (i.e., a two-factor
authentication credential with a one-time-password).

Registrars can use the OTP when communicating directly with our Customer Service
department as well as when using the registrar portal to make manual updates, transfers, and⁄or
deletion transactions. The Two-Factor Authentication Service is an optional service offered to
registrars that execute the Registry-Registrar Two-Factor Authentication Service Agreement. As
shown in Figure 28-1 (see Attachment VRSN_.comAra_Q28 Figures for all figures in this
response), the registrars’ authorized contacts use the OTP to enable strong authentication when
they contact the registry. There is no charge for the Registry-Registrar Two-Factor
Authentication Service. It is enabled only for registrars that wish to take advantage of the added
security provided by the service.

1.7.2 Requiring Multiple, Unique Points of Contact

Each user of the system is required to have an account established with a responsibility role
assigned to him⁄her. The authoritative contact for the account is the ICANN Primary Contact. In
addition to the Administrative Contact, the following roles are available: Billing, Technical, Legal,
Marketing, Administrative, CEO, and Technical 24⁄7. Only one user is designated as the ICANN
Primary and, as such, is the authoritative contact on the account should any conflict arise.

2. TECHNICAL PLAN THAT IS ADEQUATELY RESOURCED IN THE PLANNED COSTS DETAILED
IN THE FINANCIAL SECTION

As an experienced backend registry provider, we have developed a set of proprietary resourcing
models to project the number and type of personnel resources necessary to operate a TLD. We
routinely adjust these staffing models to account for new tools and process innovations. These
models enable us to continually right-size our staff to accommodate projected demand and
meet service level agreements as well as Internet security and stability requirements. Using the
projected usage volume for the most likely scenario (defined in Question 46, Template 1 –
Financial Projections: Most Likely) as an input to our staffing models, we derived the necessary
personnel levels required for this gTLD’s initial implementation and ongoing maintenance. Cost
related to this infrastructure is provided as “Total Critical Registry Function Cash Outflows”
(Template 1, Line IIb.G) within the Question 46 financial projections response.

We employ more than 1,040 individuals of which more than 775 comprise our technical work
force. (Current statistics are publicly available in our quarterly filings.)

We project we will use the following personnel roles, which are described in Section 5 of the
response to Question 31, Technical Overview of Proposed Registry, to support abuse
prevention and mitigation:

* Application Engineers: 19
* Business Continuity Personnel: 3
* Customer Affairs Organization: 9
* Customer Support Personnel: 36
* Information Security Engineers: 11
* Network Administrators: 11
* Network Architects: 4
* Network Operations Center (NOC) Engineers: 33
* Project Managers: 25
* Quality Assurance Engineers: 11
* Systems Architects: 9

To implement and manage the ARABIC_TRANSLITERATION_OF_.COM gTLD as described in
this application, we scale, as needed, the size of each technical area now supporting our
portfolio of TLDs. Consistent with our resource modeling, we periodically review the level of
work to be performed and adjust staff levels for each technical area.

When usage projections indicate a need for additional staff, our internal staffing group uses an
in-place staffing process to identify qualified candidates. These candidates are then interviewed
by the lead of the relevant technical area. By scaling one common team across all our TLDs
instead of creating a new entity to manage only this proposed gTLD, we realize significant
economies of scale and ensure our TLD best practices are followed consistently. This
consistent application of best practices helps ensure the security and stability of both the
Internet and this proposed gTLD. Moreover, by augmenting existing teams, we afford new
employees the opportunity to be mentored by existing senior staff. This mentoring minimizes
start-up learning curves and helps ensure that new staff members properly execute their duties.

3. POLICIES AND PROCEDURES IDENTIFY AND ADDRESS THE ABUSIVE USE OF REGISTERED NAMES AT STARTUP
AND ON AN ONGOING BASIS

3.1 Start-Up Anti-Abuse Policies and Procedures

We incorporate the following domain name abuse prevention service into our full-service
registry operations. This service is available at the time of domain name registration.

Registry Lock

The Registry Lock Service allows registrars to offer server-level protection for their registrants’
domain names. A registry lock can be applied during the initial standup of the domain name or
at any time that the registry is operational.

Specific EPP status codes are set on the domain name to prevent malicious or inadvertent
modifications, deletions, and transfers. Typically, these ‘server’ level status codes can only be
updated by the registry. The registrar only has ‘client’ level codes and cannot alter ‘server’ level
status codes. The registrant must provide a pass phrase to the registry before any updates are
made to the domain name. However, with Registry Lock, registrars can also take advantage of
server status codes.

The following EPP server status codes are applicable for domain names: (i)
serverUpdateProhibited, (ii) serverDeleteProhibited, and (iii) serverTransferProhibited. These
statuses may be applied individually or in combination.

The EPP also enables setting host (i.e., name server) status codes to prevent deleting or
renaming a host or modifying its IP addresses. Setting host status codes at the registry reduces
the risk of inadvertent disruption of DNS resolution for domain names.

The Registry Lock Service is used in conjunction with a registrar’s proprietary security measures
to bring a greater level of security to registrants’ domain names and help mitigate potential for
unintended deletions, transfers, and⁄or updates.

Two components comprise the Registry Lock Service:

* Registrars provide Verisign with a list of the domain names to be placed on the server status
codes. During the term of the service agreement, the registrar can add domain names to be
placed on the server status codes and⁄or remove domain names currently placed on the
server status codes. We then manually authenticate that the registrar submitting the list of
domain names is the registrar of record for such domain names.

* If registrars require changes (including updates, deletes, and transfers) to a domain name
placed on a server status code, we follow a secure, authenticated process to perform the
change. This process includes a request from a registrar-authorized representative for
Verisign to remove the specific registry status code, validation of the authorized individual by
Verisign, removal of the specified server status code, registrar completion of the desired
change, and a request from the registrar-authorized individual to reinstate the server status
code on the domain name. This process is designed to complement automated transaction
processing through the Shared Registration System (SRS) by using independent
authentication by trusted registry experts.

3.2 Ongoing Anti-Abuse Policies and Procedures

3.2.1 Policies and Procedures That Identify Malicious or Abusive Behavior

We incorporate the following service into our full-service registry operations.

Malware Scanning Service

Registrants are often unknowing victims of malware exploits. We have developed proprietary
code to help identify malware in the zones we manage, which in turn helps us to identify
malicious code hidden in ARABIC_TRANSLITERATION_OF_.COM domain names.

MalDetector, our malware scanning service, helps prevent
ARABIC_TRANSLITERATION_OF_.COM websites from infecting other websites by scanning
web pages for embedded malicious content that will infect visitors’ websites. Our malware
scanning technology uses a combination of in-depth malware behavioral analysis, anti-virus
results, detailed malware patterns, and network analysis to discover known exploits for the
particular scanned zone. If malware is detected, the service sends the registrant a report that
contains the number of malicious domain names found and details about malicious content
within its TLD zones. Reports with remediation instructions are provided to help the response
team quickly and effectively remove the malicious code.

3.2.2 Policies and Procedures That Address the Abusive Use of Registered Names

Suspension Processes

In the case of domain name abuse, Verisign verifies the nature of the abuse and remediates the
abuse using the procedures detailed in this section and in Figure 28-2.

Step 1.1: Verisign Notification. External party escalates the abuse notification to Verisign for
processing, documented by:

* Threat domain name

* Registrar of record (ROR)Incident narrative, threat analytics, screen shots to depict abuse,
and⁄or other evidence

* Threat classification

* Recommended timeframe for action

* Technical details (e.g., Whois records, IP addresses, hash values, anti-virus detection
results⁄nomenclature, name servers, domain name statuses that are relevant to the suspension)

* Contact details (e.g. name, phone, email address)

* Escalation history (initial timeframe of report to ROR, response from ROR, and so on)

Step 1.2: Registry Notification Verification. When we receive a request for escalation from an
external party, we perform the following verification procedures:

* Validate that all the required data appears in the notification.
* Validate that the request for escalation is for a registered domain name.
* Return a case number for tracking purposes.

Step 1.3: Escalation Rejection. If required data is missing from the request for escalation, or
the domain name is not registered, the request will be rejected and returned to the external
party with the following information:

* Threat domain name
* Verisign case number
* Error reason

Step 1.4: Registrar Notification. Once we have performed the verification, we notify the
registrar of the issue. Registrar notification includes the following information:

* Threat domain name
* Verisign case number
* Classification of type of domain name abuse
* Evidence of abuse
* Verisign anti-abuse contact name and number

Step 1.5: Registrant Notification. Once the registrar receives the notification from Verisign, it
may, at its discretion, notify the registrant and⁄or take any appropriate action.

Step 1.6: Website⁄Domain Cleanup. We may work with the registrar to complete the following
steps:

* Remediation steps: The registrar performs the remediation, and can elect to have us
deploy MalDetector, our malware scanning service, to determine the remediation needed to
remove the malware.

* Additional action needed: We provide additional comments to the registrar or information
to contact the Internet service provider (ISP) or hosting company for additional action.

Step 1.7: Cleanup Acknowledgement. We notify the external party that the abuse cleanup has
been completed. Acknowledgement of the cleanup includes the following information:

* Threat domain name
* Verisign case number
* Domain name
* Verisign abuse contact name and number
* Cleanup status

4. WHEN EXECUTED IN ACCORDANCE WITH THE REGISTRY AGREEMENT, PLANS WILL RESULT IN COMPLIANCE
WITH CONTRACTUAL REQUIREMENTS

All Verisign abuse mitigation policies are based on the corresponding terms in the Registry
Agreement and the Registry-Registrar Agreement as applicable. Whenever we develop a policy,
we look first at the language of our agreements to determine what we can and cannot do. We
then structure policies that are based on these determinations and appropriate stakeholders,
such as registrars, to develop policies with processes to monitor compliance with the policies.

In addition, ICANN recently asked us to participate (along with some other registries) in its 2011
Pilot Registry Self-Assessment. We are willingly cooperating with this pilot, for which we provide
ICANN with our certification that we comply with specific terms of our Registry Agreements (as
identified by ICANN).

5. TECHNICAL PLAN SCOPE⁄SCALE THAT IS CONSISTENT WITH THE OVERALL BUSINESS APPROACH
AND PLANNED SIZE OF THE REGISTRY

We have developed and use proprietary system scaling models to guide the growth of our TLD
supporting infrastructure. These models direct our infrastructure scaling to include, but not be
limited to, server capacity, data storage volume, and network throughput that are aligned to
projected demand and usage patterns. We periodically update these models to account for the
adoption of more capable and cost-effective technologies.

Our scaling models are proven predictors of needed capacity and related cost. As such, they
provide the means to link the projected infrastructure needs of the
ARABIC_TRANSLITERATION_OF_.COM gTLD with necessary implementation and
sustainment cost. Using the projected usage volume for the most likely scenario (defined in
Question 46, Template 1 – Financial Projections: Most Likely) as an input to our scaling models,
we derived the necessary infrastructure required to implement and sustain this gTLD. Cost
related to this infrastructure is provided as “Other Operating Cost” (Template 1, Line I.L) within
the Question 46 financial projections response.

1 MECHANISMS DESIGNED TO PREVENT ABUSIVE REGISTRATIONS

Rights protection is a core objective of Verisign. We will implement and adhere to any rights
protection mechanisms (RPMs) that may be mandated from time to time by ICANN, including
each mandatory RPM set forth in the Trademark Clearinghouse model contained in the Registry
Agreement, specifically Specification 7. We acknowledge that, at a minimum, ICANN requires a
Sunrise period, a Trademark Claims period, and interaction with the Trademark Clearinghouse
with respect to the registration of domain names for the
ARABIC_TRANSLITERATION_OF_.COM gTLD. It should be noted that because ICANN, as of
the time of this application submission, has not issued final guidance with respect to the
Trademark Clearinghouse, we cannot fully detail the specific implementation of the Trademark
Clearinghouse within this application. We will adhere to all processes and procedures to comply
with ICANN guidance once this guidance is finalized.

As described in this response, we implement a Sunrise period and Trademark Claims service
with respect to the registration of domain names within the
ARABIC_TRANSLITERATION_OF_.COM gTLD. Certain aspects of the Sunrise period and⁄or
Trademark Claims service may be administered on behalf of Verisign by Verisign-approved
registrars depending on final implementation specification detail related to the Trademark
Clearinghouse.

Sunrise Service

We implement a Sunrise service procedure for at least 30 days prior to launch of the general
registration of domain names in the ARABIC_TRANSLITERATION_OF_.COM gTLD as
provided by the Trademark Clearinghouse model set forth in the ICANN Applicant Guidebook.
The ARABIC_TRANSLITERATION_OF_.COM Sunrise service will comply with the
requirements outlined in the current Applicant Guidebook as well as any final guidance to be
issued pertaining to the operation of the Trademark Clearinghouse.

Trademark Claims Service

We also implement a Trademark Claims service for at least 60 days after the launch of the
general registration of domain names in the ARABIC_TRANSLITERATION_OF_.COM gTLD.
The ARABIC_TRANSLITERATION_OF_.COM Trademark Claims service will comply with the
requirements outlined in the current Applicant Guidebook as well as any final guidance to be
issued pertaining to the operation of the Trademark Clearinghouse.

2 MECHANISMS DESIGNED TO IDENTIFY AND ADDRESS THE ABUSIVE USE OF REGISTERED NAMES
ON AN ONGOING BASIS

In addition to the Sunrise and Trademark Claims services described in Section 1 of this
response, we implement and adhere to RPMs post-launch as mandated by ICANN, and we
confirm that registrars accredited for the ARABIC_TRANSLITERATION_OF_.COM gTLD are in
compliance with these mechanisms. Certain aspects of these post-launch RPMs may be
administered on behalf of Verisign by Verisign-approved registrars.

These post-launch RPMs include the established Uniform Domain-Name Dispute-Resolution
Policy (UDRP), as well as the newer Uniform Rapid Suspension System (URS) and Trademark
Post-Delegation Dispute Resolution Procedure (PDDRP). Where applicable, Verisign
implements all determinations and decisions issued under the corresponding RPM.

After a domain name is registered, trademark holders can object to the registration through the
UDRP or URS. Objections to the operation of the gTLD can be made through the PDDRP.

The following descriptions provide implementation details of each post-launch RPM for the
ARABIC_TRANSLITERATION_OF_.COM gTLD:

* UDRP: The UDRP provides a mechanism for complainants to object to domain name
registrations. The complainant files its objection with a UDRP provider and the domain name
registrant has an opportunity to respond. The UDRP provider makes a decision based on
the papers filed. If the complainant is successful, ownership of the domain name registration
is transferred to the complainant. If the complainant is not successful, ownership of the
domain name remains with the domain name registrant. Verisign and entities operating on
our behalf adhere to all decisions rendered by UDRP providers.

* URS: We also provide for a Uniform Rapid Suspension (URS) system as specified in the
Applicant Guidebook. Similar to the UDRP, a complainant files its complaint with a URS
provider. The URS provider conducts an administrative review for compliance with
applicable filing requirements. If the complaint passes administrative review, the URS
provider sends Verisign, the registry operator for ARABIC_TRANSLITERATION_OF_.COM,
a Notice of Complaint. Within 24 hours of receipt of the Notice of Complaint, we place the
subject domain name on “lock,” (serverUpdateProhibited, serverTransferProhibited, and
serverDeleteProhibited) which restricts all changes to the registration data but allows the
name to continue to resolve. After the domain name is placed on lock, the URS provider
notifies the registrant of the complaint. The registrant is then given an opportunity to
respond. The URS provider must then conduct a review of the complaint and response
based on the rules outlined in the Uniform Rapid Suspension System Draft Procedures set
forth in the Applicant Guidebook. If the complainant is successful, the registry operator is
informed and the domain name is suspended for the balance of the registration period; the
domain name will not resolve to the original website, but to an informational web page
provided by the URS provider. If the complainant is not successful, the lock is removed and
full control of the domain name registration is returned to the domain name registrant.
Similar to the existing UDRP, Verisign and entities operating on our behalf adhere to the
decisions rendered by the URS providers.

* PDDRP: As provided in the Applicant Guidebook, all registries are required to implement the
PDDRP. The PDDRP provides a mechanism for a complainant to object to the registry
operator’s manner of operation or use of the gTLD. The complainant files its objection with a
PDDRP provider, who performs a threshold review. The registry operator has the
opportunity to respond and the provider issues its determination based on the papers filed,
although there may be opportunity for further discovery and a hearing. Verisign participates
in the PDDRP process for the ARABIC_TRANSLITERATION_OF_.COM gTLD as specified
in the Applicant Guidebook.

Additional Measures Specific to Rights Protection

We provide additional measures against potentially abusive registrations. These measures help
mitigate phishing, pharming, and other Internet security threats. The measures exceed the
minimum requirements for RPMs defined by Specification 7 of the Registry Agreement and are
available at the time of registration. These measures include:

* Rapid Takedown or Suspension Based on Court Orders: We comply promptly with any
order from a court of competent jurisdiction that directs us to take any action on a domain
name that is within our technical capabilities as a TLD registry. These orders may be issued
when abusive content, such as child pornography, counterfeit goods, or illegal
pharmaceuticals, is associated with the domain name.

* Anti-Abuse Process: We implement an anti-abuse process that is executed based on the
type of domain name action requested. These actions are coordinated with the domain
name’s registrar of record. The anti-abuse process is for malicious exploitation of the DNS
infrastructure, such as phishing, botnets, and malware.

* Authentication Procedures: We use two-factor authentication to augment security
protocols for telephone, email, and chat communications.

* Registry Lock: This Verisign service allows registrants to lock a domain name at the
registry level to protect against both unintended and malicious changes, deletions, and
transfers. Only Verisign, as the registry operator, can release the lock; thus all other entities
that normally are permitted to update Shared Registration System (SRS) records are
prevented from doing so. This lock is released only after the registrar request to unlock is
validated.

* Malware Code Identification: This safeguard reduces opportunities for abusive behaviors
that use registered domain names in the gTLD. Registrants are often unknowing victims of
malware exploits. As a backend registry services provider, we have developed proprietary
code to help identify malware in the zones we manage, which in turn helps registrars by
identifying malicious code hidden in their domain names.

* DNSSEC Signing Service: Domain Name System Security Extensions (DNSSEC) helps
mitigate pharming attacks that use cache poisoning to redirect unsuspecting users to
fraudulent websites or addresses. It uses public key cryptography to digitally sign DNS data
when it comes into the system and then validate it at its destination. The
ARABIC_TRANSLITERATION_OF_.COM gTLD is DNSSEC-enabled as part of our core
backend registry services.

* Commingling Restriction: If the Language Tag specified in the IDN registration is not from
an approved language authorities table, and so does not have a List of Included Characters,
then Verisign applies a restriction to prevent commingling of different scripts in a single
domain. That is, if an IDN contains code points from two or more Unicode scripts, then that
IDN registration is rejected. For example, a character from the Latin script cannot be used in
the same IDN with any Cyrillic character. All code points within an IDN must come from the
same Unicode script. This is done to prevent confusable code points from appearing in the
same IDN.

3. RESOURCING PLANS

As an experienced registry operator, we have developed a set of proprietary resourcing models
to project the number and type of personnel resources necessary to operate a TLD. We
routinely adjust these staffing models to account for new tools and process innovations. These
models enable us to continually right-size our staff to accommodate projected demand and
meet service level agreements as well as Internet security and stability requirements. Using the
projected usage volume for the most likely scenario (defined in Question 46, Template 1 –
Financial Projections: Most Likely) as an input to our staffing models, we derived the necessary
personnel levels required for this gTLD’s initial implementation and ongoing maintenance.

We project we will use the following personnel roles, which are described in Section 5 of the
response to Question 31, Technical Overview of Proposed Registry, to support the
implementation of RPMs:

* Customer Affairs Organization: 9
* Customer Support Personnel: 36
* Information Security Engineers: 11

To implement and manage the ARABIC_TRANSLITERATION_OF_.COM gTLD as described in
this application, we scale, as needed, the size of each technical area now supporting our
portfolio of TLDs. Consistent with our resource modeling, we periodically review the level of
work to be performed and adjust staff levels for each technical area.

1 DETAILED DESCRIPTION OF PROCESSES AND SOLUTIONS DEPLOYED TO MANAGE LOGICAL SECURITY
ACROSS INFRASTRUCTURE AND SYSTEMS, MONITORING AND DETECTING THREATS AND SECURITY
VULNERABILITIES AND TAKING APPROPRIATE STEPS TO RESOLVE THEM

Verisign’s comprehensive security policy has evolved over the years as part of managing some
of the world’s most critical TLDs. Our Information Security Policy is the primary guideline that
sets the baseline for all other policies, procedures, and standards that we follow. This security
policy addresses all of the critical components for the management of backend registry services,
including architecture, engineering, and operations.

Our general security policies and standards with respect to these areas are provided as follows:

Architecture

* Information Security Architecture Standard: This standard establishes the Verisign
standard for application and network architecture. The document explains the methods
for segmenting application tiers, using authentication mechanisms, and implementing
application functions.

* Information Security Secure Linux Standard: This standard establishes the
information security requirements for all systems that run Linux throughout the Verisign
organization.

* Information Security Secure Oracle Standard: This standard establishes the
information security requirements for all systems that run Oracle throughout the Verisign
organization.

* Information Security Remote Access Standard: This standard establishes the
information security requirements for remote access to terminal services throughout the
Verisign organization.

* Information Security SSH Standard: This standard establishes the information security
requirements for the application of Secure Shell (SSH) on all systems throughout the
Verisign organization.

Engineering

* Secure SSL⁄TLS Configuration Standard: This standard establishes the information
security requirements for the configuration of Secure Sockets Layer⁄Transport Layer
Security (SSL⁄TLS) for all systems throughout the Verisign organization.

* Information Security C++ Standards: These standards explain how to use and
implement the functions and application programming interfaces (APIs) within C++. The
document also describes how to perform logging, authentication, and database
connectivity.

* Information Security Java Standards: These standards explain how to use and
implement the functions and APIs within Java. The document also describes how to
perform logging, authentication, and database connectivity.

Operations

* Information Security DNS Standard: This standard establishes the information
security requirements for all systems that run DNS systems throughout the Verisign
organization.

* Information Security Cryptographic Key Management Standard: This standard
provides detailed information on both technology and processes for the use of
encryption on Verisign information security systems.

* Secure Apache Standard: We have a multitude of Apache web servers, which are
used in both production and development environments on the Verisign intranet and on
the Internet. They provide a centralized, dynamic, and extensible interface to various
other systems that deliver information to the end user. Because of their exposure and
the confidential nature of the data that these systems host, adequate security measures
must be in place. The Secure Apache Standard establishes the information security
requirements for all systems that run Apache web servers throughout the Verisign
organization.

* Secure Sendmail Standard: We use sendmail servers in both the production and
development environments on the Verisign intranet and on the Internet. Sendmail allows
users to communicate with one another via email. The Secure Sendmail Standard
establishes the information security requirements for all systems that run sendmail
servers throughout the Verisign organization.

* Secure Logging Standard: This standard establishes the information security logging
requirements for all systems and applications throughout the Verisign organization.
Where specific standards documents have been created for operating systems or
applications, the logging standards have been detailed. This document covers all
technologies.

* Patch Management Standard: This standard establishes the information security patch
and upgrade management requirements for all systems and applications throughout
Verisign.

General

* Secure Password Standard: Because passwords are the most popular and, in many
cases, the sole mechanism for authenticating a user to a system, great care must be
taken to help ensure that passwords are “strong” and secure. The Secure Password
Standard details requirements for the use and implementation of passwords.

* Secure Anti-Virus Standard: Verisign must be protected continuously from computer
viruses and other forms of malicious code. These threats can cause significant damage
to the overall operation and security of the Verisign network. The Secure Anti-Virus
Standard describes the requirements for minimizing the occurrence and impact of these
incidents.

Security processes and solutions for the ARABIC_TRANSLITERATION_OF_.COM gTLD are based on the
standards defined above, each of which is derived from our experience and industry best
practice. These standards comprise the framework for the overall security solution and
applicable processes implemented across all products under our management. The security
solution and applicable processes include, but are not limited to:

* System and network access control (e.g., monitoring, logging, and backup)

* Independent assessment and periodic independent assessment reports

* Denial of service (DoS) and distributed denial of service (DDoS) attack mitigation

* Computer and network incident response policies, plans, and processes

* Minimization of risk of unauthorized access to systems or tampering with registry data

* Intrusion detection mechanisms, threat analysis, defenses, and updates

* Auditing of network access

* Physical security

Further details of these processes and solutions are provided in Part B of this response.

1.1 Security Policy and Procedures for the Proposed Registry

Specific security policy related details, requested as the bulleted items of Question 30 – Part A,
are provided here.

Independent Assessment and Periodic Independent Assessment Reports

To help ensure effective security controls are in place, we conduct a yearly American Institute of
Certified Public Accountants (AICPA) and Canadian Institute of Chartered Accountants (CICA)
SAS 70 audit on all of our data centers, hosted systems, and applications. During these SAS 70
audits, security controls at the operational, technical, and human level are rigorously tested.
These audits are conducted by a certified and accredited third party and help ensure that
Verisign in-place environments meet the security criteria specified in our customer contractual
agreements and are in accordance with commercially accepted security controls and practices.
We also perform numerous audits throughout the year to verify our security processes and
activities. These audits cover many different environments and technologies and validate our
capability to protect our registry and DNS resolution environments. Figure 30A-1 (see
Attachment VRSN_.comAra_Q30A_Figures for all figures in this response) lists a subset of the
audits that Verisign conducts. For each audit program or certification listed in Figure 30A-1, we
have included, as attachments to the Part B component of this response, copies of the
assessment reports conducted by the listed third-party auditor. (See VRSN_.comAra_Q30B-
1_Attachment_SAS70; VRSN_.comAra_Q30B-2_Attachment_KPMGSysTrust; VRSN_.comAra
_Q30B-3_Attachment_KPMG 10K; and VRSN_.comAra_Q30B-4_Attachment_InfoSecPolicy.)

From our experience operating registries, we have determined that together these audit
programs and certifications provide a reliable means to ensure effective security controls are in
place and that these controls are sufficient to meet ICANN security requirements and therefore
are commensurate with the guidelines defined by ISO 27001.

Augmented Security Levels or Capabilities

See Section 5 of this response.

Commitments Made to Registrants Concerning Security Levels
See Section 4 of this response.

2 SECURITY CAPABILITIES ARE CONSISTENT WITH THE OVERALL BUSINESS APPROACH
AND PLANNED SIZE OF THE REGISTRY

3 TECHNICAL PLAN ADEQUATELY RESOURCED IN THE PLANNED COSTS DETAILED IN THE FINANCIAL SECTION

As an experienced backend registry provider, we have developed and use a set of proprietary
resourcing models to project the number and type of personnel resources necessary to operate
a TLD. We routinely adjust these staffing models to account for new tools and process
innovations. These models enable us to continually right-size our staff to accommodate
projected demand and meet service level agreements as well as Internet security and stability
requirements. Using the projected usage volume for the most likely scenario (defined in
Question 46, Template 1 – Financial Projections: Most Likely) as an input to our staffing models,
we derived the necessary personnel levels required for this gTLD’s initial implementation and
ongoing maintenance. Cost related to this infrastructure is provided as “Total Critical Registry
Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46 financial projections
response.

We project we will use the following personnel role, which is described in Section 5 of the
response to Question 31, Technical Overview of Proposed Registry, to support our security
policy:

* Information Security Engineers: 11

4 SECURITY MEASURES ARE CONSISTENT WITH ANY COMMITMENTS MADE TO REGISTRANTS
REGARDING SECURITY LEVELS

For the ARABIC_TRANSLITERATION_OF_.COM gTLD, no unique security measures or commitments must be
made by Verisign to any registrant.

5 SECURITY MEASURES ARE APPROPRIATE FOR THE APPLIED-FOR gTLD STRING (FOR EXAMPLE,
APPLICATIONS FOR STRINGS WITH UNIQUE TRUST IMPLICATIONS, SUCH AS FINANCIAL SERVICES-ORIENTED
STRINGS, WOULD BE EXPECTED TO PROVIDE A COMMENSURATE LEVEL OF SECURITY)

No unique security measures are necessary to implement the ARABIC_TRANSLITERATION_OF_.COM gTLD. As
defined in Section 1 of this response, we commit to providing backend registry services in
accordance with the following international and relevant security standards:

* American Institute of Certified Public Accountants (AICPA) and Canadian Institute of
Chartered Accountants (CICA) SAS 70

* WebTrust⁄SysTrust for Certification Authorities (CA)

Daniel Blättler	Gérant (Manager)
Romain Jean-Pierre Cholat	Gérant (Manager) & President

Daniel Blättler	Gérant (Manager)
Romain Jean-Pierre Cholat	Gérant (Manager) & President

New gTLD Application Submitted to ICANN by: VeriSign Sarl

String: كوم

Originally Posted: 13 June 2012

Application ID: 1-1254-25640

Applicant Information

1. Full legal name

2. Address of the principal place of business

3. Phone number

4. Fax number

5. If applicable, website or URL

Primary Contact

6(a). Name

6(b). Title

6(c). Address

6(d). Phone Number

6(e). Fax Number

6(f). Email Address

Secondary Contact

7(a). Name

7(b). Title

7(c). Address

7(d). Phone Number

7(e). Fax Number

7(f). Email Address

Proof of Legal Establishment

8(a). Legal form of the Applicant

8(b). State the specific national or other jursidiction that defines the type of entity identified in 8(a).

8(c). Attach evidence of the applicant's establishment.

9(a). If applying company is publicly traded, provide the exchange and symbol.

9(b). If the applying entity is a subsidiary, provide the parent company.

9(c). If the applying entity is a joint venture, list all joint venture partners.

Applicant Background

11(a). Name(s) and position(s) of all directors

11(b). Name(s) and position(s) of all officers and partners

11(c). Name(s) and position(s) of all shareholders holding at least 15% of shares

11(d). For an applying entity that does not have directors, officers, partners, or shareholders: Name(s) and position(s) of all individuals having legal or executive responsibility

Applied-for gTLD string

13. Provide the applied-for gTLD string. If an IDN, provide the U-label.

14(a). If an IDN, provide the A-label (beginning with "xn--").

14(b). If an IDN, provide the meaning or restatement of the string in English, that is, a description of the literal meaning of the string in the opinion of the applicant.

14(c). If an IDN, provide the language of the label (in English).

14(c). If an IDN, provide the language of the label (as referenced by ISO-639-1).

14(d). If an IDN, provide the script of the label (in English).

14(d). If an IDN, provide the script of the label (as referenced by ISO 15924).

14(e). If an IDN, list all code points contained in the U-label according to Unicode form.

15(a). If an IDN, Attach IDN Tables for the proposed registry.

15(b). Describe the process used for development of the IDN tables submitted, including consultations and sources used.

15(c). List any variant strings to the applied-for gTLD string according to the relevant IDN tables.

16. Describe the applicant's efforts to ensure that there are no known operational or rendering problems concerning the applied-for gTLD string. If such issues are known, describe steps that will be taken to mitigate these issues in software and other applications.

17. (OPTIONAL) Provide a representation of the label according to the International Phonetic Alphabet (http://www.langsci.ucl.ac.uk/ipa/).

Mission/Purpose

18(a). Describe the mission/purpose of your proposed gTLD.

18(b). How do you expect that your proposed gTLD will benefit registrants, Internet users, and others?

18(c). What operating rules will you adopt to eliminate or minimize social costs?

Community-based Designation

19. Is the application for a community-based TLD?

20(a). Provide the name and full description of the community that the applicant is committing to serve.

20(b). Explain the applicant's relationship to the community identified in 20(a).

20(c). Provide a description of the community-based purpose of the applied-for gTLD.

20(d). Explain the relationship between the applied-for gTLD string and the community identified in 20(a).

20(e). Provide a description of the applicant's intended registration policies in support of the community-based purpose of the applied-for gTLD.

20(f). Attach any written endorsements from institutions/groups representative of the community identified in 20(a).

Geographic Names

21(a). Is the application for a geographic name?

Protection of Geographic Names

22. Describe proposed measures for protection of geographic names at the second and other levels in the applied-for gTLD.

Registry Services

23. Provide name and full description of all the Registry Services to be provided.

Demonstration of Technical & Operational Capability

24. Shared Registration System (SRS) Performance

25. Extensible Provisioning Protocol (EPP)

26. Whois

27. Registration Life Cycle

28. Abuse Prevention and Mitigation

29. Rights Protection Mechanisms

30(a). Security Policy: Summary of the security policy for the proposed registry

© Internet Corporation For Assigned Names and Numbers.