Application number: 1-1145-38018 for VeriSign, Inc.

VeriSign, Inc.

12061 Bluemont Way
Reston Virginia 20190
US

1 703 948 3200

1 703 421 2034

http:⁄⁄www.verisigninc.com

Mr. Joe Alton Waldron

Director, Product Management

1 703 948 4553

1 703 948 3689

JoeWaldronVRSN@verisign.com

Ms. Sarah Elizabeth Goddard-Langstone

Director, Product Management

1 703 948 4553

1 703 948 3689

SarahLangstoneVRSN@verisign.com

Corporation

Delaware

Not Available

NASDAQ

Not applicable.

Not applicable.

Demetrios James Bidzos
Executive Chairman; Director and Chairman of the Board; President; Chief Executive Officer
John Dewitt Cox Roach
Director
Kathleen Ann Cote
Director; Chairman, Corporate Governance & Nominating Committee
Louis Allen Simpson
Director; Chairman, Compensation Committee
Roger Herman Moore
Director
Timothy Tomlinson
Director
William Lawrence Chenevich
Director; Chairman, Audit Committee

Demetrios James Bidzos
Executive Chairman; Director and Chairman of the Board; President; Chief Executive Officer
John Calys
Interim Chief Financial Officer, Vice President, and Controller
Patrick Steven Kane
Senior Vice President and General Manager, Naming Services
Richard Henley Goshorn
Senior Vice President, General Counsel & Secretary

comsec

Not Available

Having successfully operated TLDs for more than 16 years and having used IDNs in our
registries since 2000, Verisign has deep knowledge and understanding of potential operational
or rendering problems associated with TLDs and IDN strings.
Verisign operates the .comsec gTLD in compliance with the most recently approved versions of
the ICANN IDN Guidelines and RFC application protocol, currently RFC 5891, Internationalized
Domain Names in Applications (IDNA 2008).
The .comsec gTLD is a left-to-right script. Because rendering issues only occur when mixing bi-
directional scripts, and because .comsec is left-to-right only, Verisign does not anticipate
rendering issues.

1 MISSION AND PURPOSE OF PROPOSED GTLD
The primary mission of .comsec is to provide a generic top-level domain (gTLD) that supports a wide range of value-added services to enhance and improve the Internet experience for registrants and users alike. 

2 BENEFITS TO REGISTRANTS, INTERNET USERS, AND OTHERS
The .comsec gTLD will provide domain name registrants and Internet users with an exciting new gTLD that is supported by Verisign’s world-renowned registry infrastructure, which has a proven track record of stability and security. 

2.1 Business Goals
Verisign will work to build .comsec as a global gTLD brand that provides registrants with a robust range of value-added services. 

2.2. Competition, Differentiation, and Innovation Goals
Verisign is developing .comsec with a focus on providing registrants a suite of value-added services intended to enhance and strengthen the online properties of .comsec registrants. 

2.3 User Experience Goals
Verisign strives to maintain an exemplary level of stability, security and availability across all domains for which it provides stewardship. Verisign’s commitment to .comsec registrants is that the infrastructure operating their domain will provide a robust level of operational stability. 

2.4 Measures to Protect Privacy and Confidentiality
Verisign limits information collection from registrants to ICANN mandated data points that are required in the registration of a domain name and used solely for the purpose of publishing to the publicly available Whois service. Whois Terms of Use are available on our website at:
http:⁄⁄www.verisigninc.com⁄en_US⁄products-and-services⁄domain-name-services⁄whois⁄terms-of-use⁄index.xhtml

2.5 Outreach and Communications
Verisign will engage in an international marketing and public relations campaign to educate users about the unique value and benefits of the .comsec gTLD. The campaign will feature standalone marketing and public relations efforts, as well as channel⁄registrar promotional efforts. The outreach campaign focuses on three areas:
• Registrars: Verisign will work extensively with its registrar channel to promote the benefits and value of .comsec domain names, and will help registrars identify the types of prospective registrants that may benefit from the value-added services .comsec offers. 
• Registrants: Verisign will target marketing efforts at registrants that are likely to find specific value in .comsec’s value-added services. 
• Users: Focusing on public relations and media outreach, Verisign will educate users about what it means when an Internet address is registered in .comsec

3 OPERATING RULES TO MINIMIZE SOCIAL COSTS
Verisign is committed to adhering fully to all of the standards and procedures in the Applicant Guidebook to ensure the stable, secure, and lawful launch and operation of .comsec. 

3.1 Sunrise Period with Dispute Resolution Process

3.1.1 Resolution of Multiple Applications
Domain name registrations are processed on a first-come, first-served basis. We do not batch registration requests, so once we receive an initial domain name registration request, we do not process any other registration requests for that domain name. This policy is in effect for the Sunrise and Trademark Claims periods as well as for general availability post launch.

3.1.2 General Launch and Trademark Claims Service Period
Verisign also implements a Trademark Claims Service for 60 days after the launch of the general registration of domain names in the .comsec gTLD. The .comsec Trademark Claims Service complies 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.

3.2 Cost Benefits for Registrants
Verisign does not intend to offer discount programs for .comsec at launch, but may do so at some future date. 

3.3 Contractual Commitments Regarding Price Escalation
Verisign commits to notifying all .comsec registrars at least 6 months in advance of any pricing increase. 


4 OTHER STEPS TO MINIMIZE NEGATIVE CONSEQUENCES⁄COSTS IMPOSED UPON CONSUMERS
Verisign has implemented extensive abuse prevention and rights protection measures, which are outlined in the response to Question 28, Abuse Prevention and Mitigation, and the response to Question 29, Rights Protection Mechanisms. 

No

Not Available

No

The Verisign registry solution provides a mechanism for reserving second-level domain 
names that prevents them from being registered. This functionality includes a list of 
strings that the system will not allow to be registered. Strings can be added and 
removed from this list as needed.

For the protection of geographic names for the .comsec gTLD, the country and 

territory names contained in the following internationally recognized lists shall be 
blocked initially:

* The short form (in English) of all country and territory names, including the 
European Union, contained on the International Organization for Standardization (ISO) 
3166-1 list: 

http:⁄⁄www.iso.org⁄iso⁄support⁄country_codes⁄iso_3166_code_lists⁄iso-3166-
1_decoding_table.htm#EU

* The United Nations Group of Experts on Geographical Names (UNGEGN), 
Technical Reference Manual for the Standardization of Geographical Names, Part III 
Names of Countries of the World:

http:⁄⁄unstats.un.org⁄unsd⁄geoinfo⁄UNGEGN⁄publications.html

* The list of United Nations member states, in six official United Nations 
languages, prepared by the Working Group on Country Names of the United Nations 
Conference on the Standardization of Geographical Names. The most recent list of 
country names approved by the Working Group was submitted on behalf of UNGEGN 
for the Ninth UN Conference on the Standardization of Geographical Names in August 
2007: E⁄CONF.98⁄89 Add.1 (http:⁄⁄unstats.un.org⁄unsd⁄geoinfo⁄ungegn⁄docs⁄9th-
uncsgn-docs⁄econf⁄9th_UNCSGN_e-conf-98-89-add1.pdf)


As new versions of these three internationally recognized lists are published, Verisign 
will update the list of names reserved by the Verisign registry system to reflect any 
changes.


In addition to providing protection for geographic names, this reserved name 
functionality will be used to reserve other names specifically ineligible for delegation. 
For example, Section 2.2.1.2.3 of the Applicant Guidebook lists strings associated with 
the International Olympic Committee and the International Red Cross and Red Crescent 
organizations to be prohibited from delegation per the Government Advisory Committee 
(GAC) request.

All the strings on these lists as well as any others put forth by the GAC and approved by 
ICANN will be included in the list of reserved names.

There are no plans at this time to release any of the reserved names. If, however, 
Verisign intends to release any of the names at a future date, we will follow the 
appropriate procedures, outlined in Section 5 of Specification 5, on the release of 
reserved names.

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_.comsec_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 
.comsec 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 
.comsec 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 
.comsec 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 
.comsec 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 
.comsec 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 .comsec 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_.comsec_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 .comsec 
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 across all domains for which it provides stewardship.

* 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 .comsec 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 .comsec 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 registry operator, 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 .comsec 
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 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. 
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 .comsec 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 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 .comsec 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_.comsec_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 registry operator, 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 .comsec 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 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. 
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 .comsec 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 .comsec 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. The schemas below are also attached.


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

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

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


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

* Go to http:⁄⁄whois.nic.comsec

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

* Enter the applicable parameter:
a. Domain name, including the TLD (e.g., EXAMPLE.COMSEC)
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.COMSEC 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_.comsec_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 .comsec 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

As an experienced registry operator, 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 .comsec 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 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. 
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


To implement and manage the .comsec 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 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.comsec, 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.comsec 
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 .comsec 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 .comsec 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_.comsec_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 .comsec.
* 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 .comsec.
* 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.comsec) of the domain name (sample 
.comsec). 

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.comsec” cannot be deleted if an 
in-zone host “ns.sample.comsec” exists and is a name server for “sample2.comsec.”

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 
.comsec 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 .comsec 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 
.comsec database. Two identical second-level domain 
names cannot simultaneously exist in .comsec. 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 .comsec 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.
 

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

Definitions

Malicious abuse of the .comsec 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’ .comsec 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 .comsec gTLD, without the need for additional implementation. 

The .comsec gTLD is added to the root zone, and second-level domain names are provisioned through Verisign’s Shared Registration System (SRS). Registrars have the .comsec gTLD 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 .comsec 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 CSC provides world-class support to our customers with key performance metrics that support a timely response to customer issues, including complaints of abuse. 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. 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 .comsec 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 .comsec 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_.comsec_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 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 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. 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 .comsec 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 .comsec domain names. 

MalDetector, our malware scanning service, helps prevent .comsec 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 .comsec 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 .comsec 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 .comsec 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 .comsec gTLD as provided by the Trademark Clearinghouse model set forth in the ICANN Applicant Guidebook. The .comsec 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 .comsec gTLD. The .comsec 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 .comsec 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 .comsec 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 .comsec, 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 .comsec gTLD as specified in the Applicant Guidebook.


Additional Measures Specific to Rights Protection

We provide additional measures which 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 Orders issued 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. 

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

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

* 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 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 implementation of RPMs:

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

To implement and manage the .comsec 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 ensureour 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.

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 .comsec 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_.comsec_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_.comsec_Q30B-
1_Attachment_SAS70; VRSN_.comsec_Q30B-2_Attachment_KPMGSysTrust; VRSN_.comsec 
_Q30B-3_Attachment_KPMG 10K; and VRSN_.comsec_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

As an experienced registry operator, 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 .comsec 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 ADEQUATELY RESOURCED IN THE PLANNED COSTS DETAILED IN THE FINANCIAL SECTION

As an experienced registry operator, 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 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 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

To implement and manage the .comsec 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 SECURITY MEASURES ARE CONSISTENT WITH ANY COMMITMENTS MADE TO REGISTRANTS 
REGARDING SECURITY LEVELS

For the .comsec 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 .comsec 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)