gTLD	Full Legal Name	E-mail suffix	Detail
.ONYOURSIDE	Nationwide Mutual Insurance Company	nationwide.com	View

1 CUSTOMARY REGISTRY SERVICES
As Nationwide Mutual Insurance Co.ʹs (“Applicant”) selected provider of backend 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. Verisign’s 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. Verisign’s operational environments not only meet the security criteria specified in its 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. Verisign’s 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 Verisign currently complies. Please see the response to Question 30, Security Policy, for details of the security features of Verisign’s registry services.

Verisign’s registry services fully 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, Verisign’s 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, Verisign helps to ensure its 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 its leadership in authoring RFCs for EPP, Domain Name System Security Extensions (DNSSEC), and other DNS services, Verisign has created and contributed to several now well-established IETF standards and is a regular and long-standing participant in key Internet standards forums.

Figure 23-1 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. Customary registry services are provided in the same manner as Verisign provides these services for its existing gTLDs.

Through these established registry services, Verisign has proven its ability to operate a reliable and low-risk registry that supports millions of transactions per day. Verisign is 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, Verisign allocates the applicable RFCs to each of the five customary registry services (items A – E above). For each registry service, Verisign also provides evidence in Figure 23-2 of Verisign’s RFC compliance and includes 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 is Applicant’s selected provider of backend registry services. 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 clientHold, serverHold 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
Verisign is Applicant’s selected provider of backend registry services. Verisign, as a company, 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. Verisign also uses Anycast techniques and regional Internet resolution sites to expand coverage, accommodate emergency or surge capacity, and support system availability during maintenance procedures. Verisign operates Applicant’s gTLD from a minimum of eight of its 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 expands resolution sites based on traffic volume and patterns. Further details of the geographic diversity of Verisign’s zone servers are provided in the response to Question 34, Geographic Diversity. Moreover, additional details of Verisign’s 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, Applicant’s selected provider of backend registry services, 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 TLD, Verisign implements these services using the same proven processes and procedures currently in-place for all registries under Verisign’s management. Furthermore, Verisign executes these services on computing platforms comparable to those of other registries under Verisign’s management. Verisign’s extensive experience with consensus policy required services and its 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, Verisign, Applicant’s selected provider of backend registry services, has designed its registration systems to systematically restrict the transfer of domain names within 60 days of the initial create date. In addition, Verisign has 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. Applicant’s 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: Verisign is 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: Verisign has been in compliance with the IRTP since November 2004 and is available to support Applicant in a consulting capacity as needed.
Unique to the TLD: This service is not provided in a manner unique to the TLD.

2.2 Add Grace Period (AGP) Limits Policy
Technical Component: Verisign’s registry system monitors registrars’ Add grace period deletion activity and provides reporting that permits Applicant to assess registration fees upon registrars that have exceeded the AGP thresholds stipulated in the AGP Limits Policy. Further, Applicant accepts and evaluates all exemption requests received from registrars and determines whether the exemption request meets the exemption criteria. Applicant maintains all AGP Limits Policy exemption request activity so that this material may be included within Applicant’s Monthly Registry Operator Report to ICANN.

Registrars that exceed the limits established by the policy may submit exemption requests to Applicant for consideration. Applicant’s compliance office reviews these exemption requests in accordance with the AGP Limits Policy and renders a decision. Upon request, Applicant submits 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, Applicant identifies 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: Verisign is 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: Verisign, Applicant’s backend registry services provider, has had experience with this policy since its implementation in April 2009 and is available to support Applicant in a consulting capacity as needed.

Unique to the TLD: This service is not provided in a manner unique to the TLD.

2.3 Registry Services Evaluation Policy (RSEP)
Technical Component: Verisign, Applicant’s selected provider of backend registry services, adheres to all RSEP submission requirements. Verisign has followed the process many times and is 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, Verisign, Applicant’s backend registry services provider, identifies any potential security and stability concerns in accordance with RSEP stability and security requirements. Verisign never launches 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 TLD.

3 PRODUCTS OR SERVICES ONLY A REGISTRY OPERATOR IS CAPABLE OF PROVIDING BY REASON OF ITS DESIGNATION AS THE REGISTRY OPERATOR
Verisign, Applicant’s selected backend registry services provider, has 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.

Applicant is 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 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 one-time-password 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: Verisign is 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 TLD.

gTLD	Full Legal Name	E-mail suffix	Detail
.大拿	VeriSign Sarl	verisign.com	View

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_.netSimpChin_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
CHINESE_SIMPLIFIED_TRANSLITERATION_OF_.NET 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
CHINESE_SIMPLIFIED_TRANSLITERATION_OF_.NET 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
CHINESE_SIMPLIFIED_TRANSLITERATION_OF_.NET 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
CHINESE_SIMPLIFIED_TRANSLITERATION_OF_.NET 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
CHINESE_SIMPLIFIED_TRANSLITERATION_OF_.NET gTLD.