New gTLD Application Submitted to ICANN by: Lance Armstrong Foundation

Application Downloaded On: 25 Mar 2014

String: livestrong

Application ID: 1-2090-26288

Applicant Information

1. Full legal name
Lance Armstrong Foundation

2. Address of the principal place of business
2201 E. 6th Street Austin, Texas - 78702 US

3. Phone number
1 877 236 8820

4. Fax number
1 512 236 8482

5. If applicable, website or URL
http://www.livestrong.org

Primary Contact

6(a). Name
Greg Lee

6(b). Title
Chief Financial Officer

6(c). Address

6(d). Phone Number
(512) 658-4913

6(e). Fax Number

6(f). Email Address
greg.lee@livestrong.org

Secondary Contact

7(a). Name
Travis Rimel

7(b). Title
Director of Creative Strategy and Services

7(c). Address

7(d). Phone Number
(512) 924-6661

7(e). Fax Number
1 512 236 8482

7(f). Email Address
travis.rimel@livestrong.org

Proof of Legal Establishment

8(a). Legal form of the Applicant
Non-profit institution - 501(c)(3)

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

8(c). Attach evidence of the applicant's establishment.
Attachments are not displayed on this form.

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

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

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

Applicant Background

11(a). Name(s) and position(s) of all directors
Name
Position
Amelie RamirezTreasurer
Blaine RollinsSecretary
Craig NicholsDirector
David JohnsonDirector
E. Lee WalkerDirector
Harold FreemanDirector
J. Dennis CavnerDirector
Jeffery GarveyChairman
Joseph AragonaDirector
Julian DayDirector
Michael SherwinDirector
Mitch StollerDirector
Sanjay GuptaDirector

11(b). Name(s) and position(s) of all officers and partners
Name
Position
Doug UlmanPresident
Greg D. Lee, CPAChief Financial Officer
Morgan BinswangerEvec VP

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

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

Applied-for gTLD string

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


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



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



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



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



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



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



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



15A. If an IDN, upload IDN tables for the proposed registry. An IDN table must include:
  1. the applied-for gTLD string relevant to the tables,
  2. the script or language designator (as defined in BCP 47),
  3. table version number,
  4. effective date (DD Month YYYY), and
  5. contact name, email address, and phone number.
    Submission of IDN tables in a standards-based format is encouraged.



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



15C. List any variants to the applied-for gTLD string according to the relevant IDN tables.



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

Verisign, 〈the gTLD applicant〉’s selected backend registry services provider, operates the 〈new string〉 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).

Bi-directional rules for impacted scripts, outlined in RFC 5893 (Right-to-Left Scripts for IDNA), specify the relevant rules for the 〈new string〉 gTLD.

Because these rendering issues only occur when mixing bi-directional scripts, and because the 〈gTLD string〉 gTLD is left-to-right only, we do not anticipate rendering issues to affect the user experience for our clients.


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



18A. Describe the mission/purpose of your proposed gTLD.

The mission and purpose of the Lance Armstrong Foundation is to inspire and empower those affected by cancer.

We plan to use our proposed gTLD to further the foundationʹs mission and purpose. Specifically, we will use our proposed gTLD to strengthen and clarify ou relationship with our corporate partners, with whom we engage in cause marketing and sponsorship relationships.


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

i. The goal of our proposed gTLD is to leverage our relationships with our corporate partners, and strengthen and clarify our relationships with them. For example, Nike, Inc., is one of our corporate partners and the exclusive licensee for sports apparel and accessories. As part of our corporate partner guidelines, we will require our partners to market, promote and sell the LIVESTRONG branded collection on a version of the proposed gTLD (e.g. www.nike.livestrong). The goal of our proposed gTLD would specialize in our corporate partners and sponsorships. In partnership with our corporate partners and sponsors, the goal is to offer the highest level of service and continue to build the highest brand equity⁄reputation with our constituents.
ii. Given that we will be using the proposed gTLD internally, we do not believe there will be issues of competition. In terms of differentiation and innovation, we believe this is an innovative approach to clarify and strengthen our relationship with our corporate partners and sponsors.
iii. In partnership with our corporate partners and sponsors, the goal is to increase the level of user experience. We believe our innovative approach will increase our constituent’s user experience by eliminating confusion and creating a consistent, dedicated Top Level Domain for LIVESTRONG-branded product. Users will also benefit from the LIVESTRONG gTLD because they will have a warranty as to the origin, authenticity, and quality of goods and services offered thereunder since our only content, products, and services and⁄or our corporate partnersʹ and sponsorsʹ content, products,and services will be available thereunder.
iv. We will only be using the proposed gTLD for internally for our corporate partners and sponsors. We will be the registrant for any and all domain names under the gTLD and weʹll allow our partners and sponsors to post content.
v. The proposed gTLD will only be offered to our corporate partners and sponsors, who are all required by agreement to be compliant with state and federal laws regarding consumer privacy. User data concerning the gTLD will only be used for internal purposes or as otherwise agreed upon in writing with our corporate partners and sponsors.


18C. What operating rules will you adopt to eliminate or minimize social costs (e.g., time or financial resource costs, as well as various types of consumer vulnerabilities)? What other steps will you take to minimize negative consequences/costs imposed upon consumers?

We plan to only offer use of the domain names under the gTLD to our corporate partners and sponsors. We will not be offering these domain names for a price. The duration of each domain name registration will be concurrent with the term of our agreement with each applicable corporate partner and sponsor.


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

No


20A. Provide the name and full description of the community that the applicant is committing to serve. In the event that this application is included in a community priority evaluation, it will be scored based on the community identified in response to this question. The name of the community does not have to be formally adopted for the application to be designated as community-based.



20B. Explain the applicant’s relationship to the community identified in 20(a).



20C. Provide a description of the community-based purpose of the applied-for gTLD.



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



20E. Provide a complete description of the applicant’s intended registration policies in support of the community-based purpose of the applied-for gTLD. Policies and enforcement mechanisms are expected to constitute a coherent set.



20F. Attach any written endorsements for the application from established institutions representative of the community identified in 20(a). An applicant may submit written endorsements by multiple institutions, if relevant to the community.



21A. Is the application for a geographic name?

No


22. Describe proposed measures for protection of geographic names at the second and other levels in the applied-for gTLD. This should include any applicable rules and procedures for reservation and/or release of such names.

The Applicant will initially reserve country names from use in the second and other levels of the TLD, and other such names designated by ICANN and pursuant to Specification 5 and ICANN’s ongoing policies and regulations. In this regard, Applicant will at all times comply with ICANN’s geographic and all other reservation requirements as outlined in the Registry Agreement and Applicant’s reserved name list mentioned below. Applicant’s TLD will be operated as a Specification 9 exempt system, and the Applicant may, over time, utilize the reserved country names in the second and other country levels in order to organize content within the domain in a meaningful way. However, in such event, before the Applicant begins using such initially reserved country names, Applicant will provide a window during which governments, ICANN, public authorities or IGOs may submit a demand to block names with national or geographic significance at the second level of the TLD at no cost to the blocking authority. In the event of such occurrence, Applicant will at all times comply with all ICANN mandates and shall establish a notice mechanism and blocking procedure to effectuate such action.
 
All geographic and geopolitical names contained in the ISO 3166-1 list from time to time shall initially be reserved at both the second level and at all other levels within the TLD at which the Applicant provides for registrations. All names shall be reserved both in English and in all related official languages as may be directed by ICANN or the GAC. In addition, Applicant shall reserve names of territories, distinct geographic locations, and other geographic and geopolitical names as ICANN may direct from time to time. Such names shall be reserved from registration during any sunrise period, and shall be registered in ICANN's name prior to start-up and open registration in the TLD. Applicant shall post and maintain an updated listing of all such names on its website, which list shall be subject to change at ICANN's direction. Upon determination by ICANN of appropriate standards and qualifications for registration following input from interested parties in the Internet community, such names may be approved for registration to the appropriate authoritative body.
 
Pursuant to any ICANN directive allowing release after the blocking period has concluded, a contact will be delegated and information posted to enable governments, public authorities, or IGOs to challenge abuses of names with national or geographic significance at the second level of the TLD during the operation of the TLD. Challenges will be reviewed on their merits and resolved in a way that demonstrates that the Applicant respects sensitivities regarding terms with national, cultural, geographic and religious significance while enabling Applicant to provide content to users in a logical and organized fashion.
 
Additionally, Verisign, as Applicant’s back-end registry provider, provides a mechanism through their registry solution 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 Applicant’s TLD, 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 located at: 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, Applicant 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.


23. Provide name and full description of all the Registry Services to be provided. Descriptions should include both technical and business components of each proposed service, and address any potential security or stability concerns.
The following registry services are customary services offered by a registry operator:
  1. Receipt of data from registrars concerning registration of domain names and name servers.
  2. Dissemination of TLD zone files.
  3. Dissemination of contact or other information concerning domain name registrations (e.g., port-43 WHOIS, Web- based Whois, RESTful Whois service).
  4. Internationalized Domain Names, where offered.
  5. DNS Security Extensions (DNSSEC). The applicant must describe whether any of
    these registry services are intended to be offered in a manner unique to the TLD.
Additional proposed registry services that are unique to the registry must also be described.

Customary Registry Services

As The Lance Armstrong Foundation’s 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‑1summarizes 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‑2of 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‑1and Figure 23‑2.

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

Verisign is The Lance Armstrong Foundation’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‑3describes 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‑1and Figure 23‑2.

iv. Operation of the Registry Zone Servers

Verisign is The Lance Armstrong Foundation’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 The Lance Armstrong Foundation’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‑1and Figure 23‑2.

1 Other Products or Services the Registry Operator Is Required to Provide Because of the Establishment of a Consensus Policy

Verisign, The Lance Armstrong Foundation’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 .livestrong gTLD, 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.

1.1             Inter-Registrar Transfer Policy (IRTP)

Technical Component: In compliance with the IRTP consensus policy, Verisign, The Lance Armstrong Foundation’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. The Lance Armstrong Foundation’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 The Lance Armstrong Foundation in a consulting capacity as needed. 

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


1.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 The Lance Armstrong Foundation to assess registration fees upon registrars that have exceeded the AGP thresholds stipulated in the AGP Limits Policy.  Further, The Lance Armstrong Foundation accepts and evaluates all exemption requests received from registrars and determines whether the exemption request meets the exemption criteria. The Lance Armstrong Foundation maintains all AGP Limits Policy exemption request activity so that this material may be included within The Lance Armstrong Foundation’s Monthly Registry Operator Report to ICANN.
Registrars that exceed the limits established by the policy may submit exemption requests to The Lance Armstrong Foundation for consideration. The Lance Armstrong Foundation’s compliance office reviews these exemption requests in accordance with the AGP Limits Policy and renders a decision. Upon request, The Lance Armstrong Foundation 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, The Lance Armstrong Foundation 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, The Lance Armstrong Foundation’s backend registry services provider, has had experience with this policy since its implementation in April 2009 and is available to support The Lance Armstrong Foundation in a consulting capacity as needed. 


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

1.3             Registry Services Evaluation Policy (RSEP)

Technical Component: Verisign, The Lance Armstrong Foundation’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, The Lance Armstrong Foundation’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 .livestrong TLD.


2   Products or Services Only a Registry Operator Is Capable of Providing by Reason of Its Designation As the Registry Operator

Verisign, The Lance Armstrong Foundation’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.
The Lance Armstrong Foundation 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.

2.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 .livestrong TLD.


24. Shared Registration System (SRS) Performance:
describe

Robust Plan for Operating a Reliable SRS
High-Level Shared Registration System (SRS) System Description
Verisign, the Lance Armstrong’s selected provider of backend registry services, provides and operates a robust and reliable SRS that enables multiple registrars to provide domain name registration services in the top-level domain (TLD). Verisign’s proven reliable SRS serves approximately 915 registrars, and Verisign, as a company, has 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 .livestrong gTLD domain names in a single architecture.
To flexibly accommodate the scale of its transaction volumes, as well as new technologies, Verisign employs 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. Verisign’s standards mandate that no more than 40 percent of the total available physical memory on the database server will be allocated for these functions.

Verisign’s SRS is built upon a three-tier architecture as illustrated in Figure 241 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 .livestrong gTLD. The application servers store the Lance Armstrong Foundation’s data in the registry database, which comprises the third and final tier. This simple, industry-standard design has been highly effective with other customers for whom Verisign provides backend registry services.
Database Layer: The database is the heart of this architecture. It stores all the essential information provisioned from registrars through the gateway servers. Separate servers query the database, extract updated zone and Whois information, validate that information, and distribute it around the clock to Verisign’s worldwide domain name resolution sites.


Figure 241: SRS Architecture. Verisign’s SRS is hierarchically designed to meet the forecasted registration volume of the .livestrong gTLD, and it can be scaled to meet future registration volume increases.
Scalability and Performance. Verisign, the Lance Armstrong Foundation’s selected backend registry services provider, implements its scalable SRS on a supportable infrastructure that achieves the availability requirements in Specification 10. Verisign employs the design patterns of simplicity and parallelism in both its software and systems, based on its experience that these factors contribute most significantly to scalability and reliable performance. Going counter to feature-rich development patterns, Verisign intentionally minimizes 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 242 depicts EPP traffic flows and local redundancy in Verisign’s 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 Verisign to take down individual system components for maintenance and upgrades, with little to no performance impact. With Verisign’s redundant design, Verisign can perform routine maintenance while the remainder of the system remains online and unaffected. For the .livestrong gTLD registry, this flexibility minimizes unplanned downtime and provides a more consistent end-user experience.
Representative Network Diagrams
Figure 243 provides a summary network diagram of the Lance Armstrong Foundation’s selected backend registry services provider’s (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.

Figure 243: SRS Network Diagram. Verisign’s fully redundant SRS design and geographically separated data centers help ensure service level availability requirements are met.

Number of Servers
As the Lance Armstrong Foundation’s selected provider of backend registry services, Verisign continually reviews its server deployments for all aspects of its registry service. Verisign evaluates usage based on peak performance objectives as well as current transaction volumes, which drive the quantity of servers in its implementations. Verisign’s 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 .livestrong gTLD, Verisign uses a minimum of 100 dedicated servers per SRS site. These servers are virtualized to meet demand.

Description of Interconnectivity with Other Registry Systems
Figure 244 provides a technical overview of the the Lance Armstrong Foundation’s selected backend registry services provider’s (Verisign’s) SRS, showing how the SRS component fits into this larger system and interconnects with other system components.

Figure 244: Technical Overview. Verisign’s SRS provides the registrar-facing component of the system establishing the zone file needed to enable DNS and Whois services.
Frequency of Synchronization Between Servers
As the Lance Armstrong Foundation’s selected provider of backend registry services, Verisign uses synchronous replication to keep the Verisign 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.
Synchronization Scheme
Verisign uses synchronous replication to keep the Verisign 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.”
Scalability and Performance Are Consistent with the overall business approach and planned size of the registry
Verisign is an experienced backend registry provider that has developed and uses proprietary system scaling models to guide the growth of its TLD supporting infrastructure. These models direct Verisign’s 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. Verisign periodically updates 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 .livestrong 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 its scaling models, Verisign derived the necessary infrastructure required to implement and sustain this gTLD. Verisign’s pricing for the backend registry services it provides to the Lance Armstrong Foundation fully accounts for cost related to this infrastructure, which is provided as “Total Critical Registry Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46 financial projections response.
Technical plan that is adequately resourced in the planned costs detailed in the financial section
Verisign, the the Lance Armstrong Foundation’s selected provider of backend registry services, is an experienced backend registry provider that has developed a set of proprietary resourcing models to project the number and type of personnel resources necessary to operate a TLD. Verisign routinely adjusts these staffing models to account for new tools and process innovations. These models enable Verisign to continually right-size its 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 its staffing models, Verisign derived the necessary personnel levels required for this gTLD’s initial implementation and ongoing maintenance. Verisign’s pricing for the backend registry services provided to the Lance Armstrong Foundation fully accounts for this personnel-related cost, which is provided as “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 its technical work force. (Current statistics are publicly available in Verisign’s quarterly filings.) Drawing from this pool of on-hand and fully committed technical resources, Verisign has maintained DNS operational accuracy and stability 100 percent of the time for more than 13 years for .com, proving Verisign’s ability to align personnel resource growth to the scale increases of Verisign’s TLD service offerings.
Verisign projects it 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 .livestrong gTLD as described in this application, Verisign, the Lance Armstrong Foundation’s selected backend registry services provider, scales, as needed, the size of each technical area now supporting its portfolio of TLDs. Consistent with its resource modeling, Verisign periodically reviews the level of work to be performed and adjusts staff levels for each technical area.
When usage projections indicate a need for additional staff, Verisign’s 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 its TLDs instead of creating a new entity to manage only this proposed gTLD, Verisign realizes significant economies of scale and ensures its 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 Verisign holds all contributing staff members accountable to the same procedures that guide its execution of the Internet’s largest TLDs (i.e., .com and .net). Moreover, by augmenting existing teams, Verisign affords 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.
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,the Lance Armstrong Foundation’s selected backend registry services provider, provides these services using its SRS, which complies fully with Specification 6, Section 1.2 of the Registry Agreement. In using its SRS to provide backend registry services, Verisign implements and complies with relevant existing RFCs (i.e., 5730, 5731, 5732, 5733, 5734, and 5910) and intends 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, Verisign’s 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. Verisign does 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, the Lance Armstrong Foundation 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 Verisign files with ICANN. These reports detail Verisign’s operational status of the .com and .net registries, which use an SRS design and approach comparable to the one proposed for the .livestrong gTLD. These reports provide evidence of Verisign’s 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, Verisignʹs SRS meets the following performance attributes:
EPP service availability: ≤ 864 minutes of downtime (≈98%)
EPP session-command round trip time (RTT): ≤4000 milliseconds (ms), for at least 90 percent of the commands
EPP query-command RTT: ≤2000 ms, for at least 90 percent of the commands
EPP transform-command RTT: ≤4000 ms, for at least 90 percent of the commands


25. Extensible Provisioning Protocol (EPP): provide a detailed description of the interface with registrars, including how the applicant will comply with EPP in RFCs 3735 (if applicable), and 5730-5734.
If intending to provide proprietary EPP extensions, provide documentation consistent with RFC 3735, including the EPP templates and schemas that will be used.
Describe resourcing plans (number and description of personnel roles allocated to this area).
A complete answer is expected to be no more than 5 pages. If there are proprietary EPP extensions, a complete answer is also expected to be no more than 5 pages per EPP extension.

Complete knowledge and understanding of this aspect of registry technical requirements

Verisign, The Lance Armstrong Foundation’s selected backend registry services provider, has used Extensible Provisioning Protocol (EPP) since its inception and possesses complete knowledge and understanding of EPP registry systems. Its first EPP implementation— for a thick registry for the .name generic top-level domain (gTLD)—was in 2002. Since then Verisign has continued its RFC-compliant use of EPP in multiple TLDs, as detailed in Figure 251.

TLD Year EPP Support Commenced
.name 2002
.tv ⁄ .cc             2004
.com ⁄ .net 2005
.jobs 2006

Figure 251: EPP Implementations. Verisign has repeatedly proven its ability to successfully implement EPP for both small and large registries.

Verisign’s understanding of EPP and its 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). Verisign has 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 registry systems for which Verisign is the registry operator or provides backend registry services use EPP. Upon approval of this application, Verisign will use EPP to provide the backend registry services for this gTLD. The .com, .net, and .name registries for which Verisign is the registry operator use an SRS design and approach comparable to the one proposed for this gTLD. Approximately 915 registrars use the Verisign 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⁄.
Verisign has 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.

EPP Interface with Registrars

Verisign, The Lance Armstrong Foundation’s selected backend registry services provider, 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. Verisign’s 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⁄currentregistrars⁄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.

Technical plan scope⁄scale consistent with the overall business approach and planned size of the registry

Verisign, The Lance Armstrong Foundation’s selected backend registry services provider, is an experienced backend registry provider that has developed and uses proprietary system scaling models to guide the growth of its TLD supporting infrastructure. These models direct Verisign’s 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. Verisign periodically updates 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 livestrong 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 its scaling models, Verisign derived the necessary infrastructure required to implement and sustain this gTLD. Verisign’s pricing for the backend registry services it provides to The Lance Armstrong Foundation fully accounts for cost related to this infrastructure, which is provided as “Total Critical Registry Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46 financial projections response.
Technical plan that is adequately resourced in the planned costs detailed in the financial section

Verisign, The Lance Armstrong Foundation’s selected backend registry services provider, is an experienced backend registry provider that has developed a set of proprietary resourcing models to project the number and type of personnel resources necessary to operate a TLD. Verisign routinely adjusts these staffing models to account for new tools and process innovations. These models enable Verisign to continually right-size its 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 its staffing models, Verisign derived the necessary personnel levels required for this gTLD’s initial implementation and ongoing maintenance. Verisign’s pricing for the backend registry services it provides to The Lance Armstrong Foundation fully accounts for cost related to this infrastructure, which is provided as “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 its technical work force. (Current statistics are publicly available in Verisign’s quarterly filings.) Drawing from this pool of on-hand and fully committed technical resources, Verisign has maintained DNS operational accuracy and stability 100 percent of the time for more than 13 years for .com, proving Verisign’s ability to align personnel resource growth to the scale increases of Verisign’s TLD service offerings.

Verisign projects it 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 livestrong gTLD as described in this application, Verisign, The Lance Armstrong Foundation’s selected backend registry services provider, scales, as needed, the size of each technical area now supporting its portfolio of TLDs. Consistent with its resource modeling, Verisign periodically reviews the level of work to be performed and adjusts staff levels for each technical area.

When usage projections indicate a need for additional staff, Verisign’s 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 its TLDs instead of creating a new entity to manage only this proposed gTLD, Verisign realizes significant economies of scale and ensures its 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 Verisign holds all contributing staff members accountable to the same procedures that guide its execution of the Internet’s largest TLDs (i.e., .com and .net). Moreover, by augmenting existing teams, Verisign affords 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.

Ability to comply with Relevant RFCs

Verisign, The Lance Armstrong Foundation’s selected backend registry services provider, incorporates design reviews, code reviews, and peer reviews into its software development lifecycle (SDLC) to ensure compliance with the relevant RFCs. Verisign’s 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. Verisign’s 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 livestrong 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)

Proprietary EPP Extensions

Verisign, The Lance Armstrong Foundation’s selected backend registry services provider, uses its SRS to provide registry services. The SRS supports the following EPP specifications, which Verisign 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⁄consolidatemapping.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 RFCcompliant EPP implementation.

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, The Lance Armstrong Foundation’s selected backend registry services provider, use these EPP templates and schemas, as will the proposed TLD. For each proprietary XML template⁄schema Verisign provides a reference to the applicable template and includes the schema.

XML templates⁄schema for idnLang-1.0

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⁄idnlanguage-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

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⁄rgppoll-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

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⁄whoisinfo-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 (consoliDate)

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

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

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

Proprietary EPP Extension Consistency with Registration Lifecycle

The Lance Armstrong Foundation’s selected backend registry services provider’s (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, Verisign develops proprietary EPP extensions to address new operational requirements. Consistent with ICANN procedures Verisign adheres to all applicable Registry Services Evaluation Process (RSEP) procedures.
 
Verisign, our selected backend registry services provider, uses its SRS to support the following EPP specifications (also attached as requested), which Verisign developed following the guidelines in RFC 3735, where the XML templates and XML schemas are defined in the specifications:

Consolidate-mapping [attached]
Low-balance-mapping [attached]
Namestore-extension [attached]
Whois-info-extension [attached]
Rgp-poll-mapping [attached]
Idn-language-tag [attached]


26. Whois: describeA complete answer should include, but is not limited to:Frequency of synchronization between servers.
To be eligible for a score of 2, answers must also include:A complete answer is expected to be no more than 5 pages.

Complete knowledge and understanding of this aspect of registry technical requirements
Verisign, The Lance Armstrong Foundation’s selected backend registry services provider, has operated the Whois lookup service for the gTLDs and ccTLDs it manages since 1991, and will provide these proven services for the livestrong gTLD registry. In addition, it continues to work with the Internet community to improve the utility of Whois data, while thwarting its application for abusive uses.
High-Level Whois System Description
Like all other components of The Lance Armstrong Foundation’s selected backend registry services provider’s (Verisign’s) registry service, Verisign’s Whois system is designed and built for both reliability and performance in full compliance with applicable RFCs. Verisign’s current Whois implementation has answered more than five billion Whois queries per month for the TLDs it manages, 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 Verisign’s Whois service is RFC-compliant through all phases of its lifecycle.
Verisignʹs redundant Whois databases further contribute to overall system availability and reliability. The hardware and software for its 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.
Verisign can fine-tune access to its Whois database on an individual Internet Protocol (IP) address basis, and it works with registrars to help ensure their services are not limited by any restriction placed on Whois. Verisign provides near real-time updates for Whois services for the TLDs under its 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 livestrong 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 Verisign’s 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. Verisign uses an advanced in-memory database technology to provide exceptional overall system performance and security. In accordance with RFC 3912, Verisign provides a website at whois.nic.〈TLD〉 that provides free public query-based access to the registration data.
Verisign currently operates both thin and thick Whois systems.
Verisign commits to implementing a RESTful Whois service upon finalization of agreements with the IETF (Internet Engineering Task Force).
Provided Functionalities for User Interface
To use the Whois service via port 43, the user enters the applicable parameter on the command line as illustrated here:
For domain name: whois EXAMPLE.TLD
For registrar: whois ʺregistrar Example Registrar, Inc.ʺ
For name server: whois ʺNS1.EXAMPLE.TLDʺ or whois ʺname server (IP address)ʺ

To use the Whois service via the web-based directory service search interface:
Go to http:⁄⁄whois.nic.〈TLD〉
Click on the appropriate button (Domain, Registrar, or Name Server)
Enter the applicable parameter:
Domain name, including the TLD (e.g., EXAMPLE.TLD)
Full name of the registrar, including punctuation (e.g., Example Registrar, Inc.)
Full host name or the IP address (e.g., NS1.EXAMPLE.TLD or 198.41.3.39)
Click on the Submit button.
Provisions to Ensure That Access Is Limited to Legitimate Authorized Users and Is in Compliance with Applicable Privacy Laws or Policies
To further promote reliable and secure Whois operations, Verisign, The Lance Armstrong Foundation’s selected backend registry services provider, 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.
Verisign’s 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, Verisign is European Union (EU) Safe Harbor certified and has 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.
Relevant Network Diagrams
Figure 261 provides a summary network diagram of the Whois service provided by Verisign, The Lance Armstrong Foundation’s selected backend registry services provider. The figure details the configuration with one resolution⁄Whois site. For the livestrong gTLD Verisign provides Whois service from 6 of its 17 primary sites based on the proposed gTLD’s traffic volume and patterns. A functionally equivalent resolution architecture configuration exists at each Whois site.

Figure 261: Whois Service Network Diagram. By distributing Whois service across multiple resolution sites, Whois transactions are highly available and performed with low latency.
IT and Infrastructure Resources
Figure 262 summarizes the IT and infrastructure resources that Verisign, The Lance Armstrong Foundation’s selected backend registry services provider, uses to provision Whois services from Verisign primary resolution sites. As needed, virtual machines are created based on actual and projected demand.
Component Implementation⁄Configuration
Load Balancers Deployed as a pair for maximum availability and resilience.
Help ensure workload is evenly distributed across all systems within the livestrong gTLD resolution network.
Layer-3 Switches Four switches are installed in Verisign’s resolution network environment: two for front-office management, and two for back-office management.
Switches provide both routing and switching for the livestrong gTLD environment across the front-office network.
Terminal Servers Deployed as a pair of terminal servers to enable out-of-band management of all network hardware.
Used in the event that primary network access is unavailable at Verisign’s primary resolution sites.
Virtual Private Networks (VPN) Pair of VPNs installed at each of Verisign’s primary resolution sites for secure remote access to the installed systems.
Commodity Servers Supporting Whois data processing needs, each commodity server consists of the following specifications:
Two central processing units (CPUs)
2 – 6 gigabytes (GB) random access memory (RAM) (as dictated by the server function)
2x73GB hard drive
Database Servers Supporting Whois data processing needs, each database server consists of the following specifications:
16 cores (4 x quad-core CPUs)
64GB RAM
5x73GB hard drive
Figure 262: Whois IT and Infrastructure Resources. Verisign uses a common Whois resolution network architecture at each primary site provisioning the Whois service.

Description of Interconnectivity with Other Registry Systems
Figure 263 provides a technical overview of the registry system provided by Verisign, The Lance Armstrong Foundation’s selected backend registry services provider, and shows how the Whois service component fits into this larger system and interconnects with other system components.

Figure 263: Technical Overview. Verisign’s Whois services are co-located at DNS locations.
Frequency of Synchronization Between Servers
Synchronization between the SRS and the geographically distributed Whois resolution sites occurs approximately every three minutes. Verisign, The Lance Armstrong Foundation’s selected backend registry services provider, uses 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. Verisign’s approach to frequency of synchronization between servers meets the Performance Specifications defined in Specification 10 of the Registry Agreement for new gTLDs.
Technical plan scope⁄scale consistent with the overall business approach and planned size of the registry
Verisign, The Lance Armstrong Foundation’s selected backend registry services provider, is an experienced backend registry provider that has developed and uses proprietary system scaling models to guide the growth of its TLD supporting infrastructure. These models direct Verisign’s 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. Verisign periodically updates 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 livestrong 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 its scaling models, Verisign derived the necessary infrastructure required to implement and sustain this gTLD. Verisign’s pricing for the backend registry services it provides to The Lance Armstrong Foundation fully accounts for cost related to this infrastructure, which is provided as “Total Critical Registry Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46 financial projections response.
Technical plan that is adequately resourced in the planned costs detailed in the financial section
Verisign, The Lance Armstrong Foundation’s selected backend registry services provider, is an experienced backend registry provider that has developed a set of proprietary resourcing models to project the number and type of personnel resources necessary to operate a TLD. Verisign routinely adjusts these staffing models to account for new tools and process innovations. These models enable Verisign to continually right-size its 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 its staffing models, Verisign derived the necessary personnel levels required for this gTLD’s initial implementation and ongoing maintenance. Verisign’s pricing for the backend registry services it provides to The Lance Armstrong Foundation fully accounts for cost related to this infrastructure, which is provided as “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 its technical work force. (Current statistics are publicly available in Verisign’s quarterly filings.) Drawing from this pool of on-hand and fully committed technical resources, Verisign has maintained DNS operational accuracy and stability 100 percent of the time for more than 13 years for .com, proving Verisign’s ability to align personnel resource growth to the scale increases of Verisign’s TLD service offerings.
Verisign projects it 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 livestrong gTLD as described in this application, Verisign, The Lance Armstrong Foundation’s selected backend registry services provider, scales, as needed, the size of each technical area now supporting its portfolio of TLDs. Consistent with its resource modeling, Verisign periodically reviews the level of work to be performed and adjusts staff levels for each technical area.
When usage projections indicate a need for additional staff, Verisign’s 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 its TLDs instead of creating a new entity to manage only this proposed gTLD, Verisign realizes significant economies of scale and ensures its 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 Verisign holds all contributing staff members accountable to the same procedures that guide its execution of the Internet’s largest TLDs (i.e., .com and .net). Moreover, by augmenting existing teams, Verisign affords 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.
Compliance with Relevant RFC
The Lance Armstrong Foundation’s selected backend registry services provider’s (Verisign’s) Whois service complies with the data formats defined in Specification 4 of the Registry Agreement. Verisign will provision Whois services for registered domain names and associated data in the top-level domain (TLD). Verisign’s Whois services are accessible over Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6), via both Transmission Control Protocol (TCP) port 43 and a web-based directory service at whois.nic.〈TLD〉, which in accordance with RFC 3912, provides free public query-based access to domain name, registrar, and name server lookups. Verisign’s proposed Whois system meets all requirements as defined by ICANN for each registry under Verisign 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 Verisign files with ICANN. These reports provide evidence of Verisign’s 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⁄.
Compliance with Specifications 4 and 10 of Registry Agreement
In accordance with Specification 4, Verisign, The Lance Armstrong Foundation’s selected backend registry services provider, provides a Whois service that is available via both port 43 in accordance with RFC 3912, and a web-based directory service at whois.nic.〈TLD〉 also in accordance with RFC 3912, thereby providing free public query-based access. Verisign acknowledges that ICANN reserves the right to specify alternative formats and protocols, and upon such specification, Verisign 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 264 through Figure 266 provide the query and response format for domain name, registrar, and name server data objects.
Figure 264: Domain Name Data Object

Figure 265: Registrar Data Object

Figure 266: Name Server Data Object

Specification 10, RDDS Registry Performance Specifications
The 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 Verisign files 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, Verisignʹs Whois service meets the following proven performance attributes:
RDDS availability: ≤ 864 min of downtime (≈98%)
RDDS query RTT: ≤ 2000 ms, for at least 95% of the queries
RDDS update time: ≤ 60 min, for at least 95% of the probes
Searchable WhoIS
Verisign, The Lance Armstrong Foundation’s selected backend registry services provider, provides a searchable Whois service for the livestrong gTLD. Verisign has experience in providing tiered access to Whois for the .name registry, and uses 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 the Verisign 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)


27. Registration Life Cycle: provide a detailed description of the proposed registration lifecycle for domain names in the proposed gTLD. The description must:The description of the registration lifecycle should be supplemented by the inclusion of a state diagram, which captures definitions, explanations of trigger points, and transitions from state to state.
If applicable, provide definitions for aspects of the registration lifecycle that are not covered by standard EPP RFCs.
A complete answer is expected to be no more than 5 pages.

Complete Knowledge and Understanding of Registration Lifecycles and States
Starting with domain name registration and continuing through domain name delete operations, The Lance Armstrong Foundation’s selected backend registry services provider’s (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 271 and Figure 272 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 271.

Figure 271: Registration Lifecycle State Diagram

Figure 272: Registration States
Registration Lifecycle of Create⁄Update⁄Delete
The following section details the create⁄update⁄delete processes and the related renewal process that Verisign, The Lance Armstrong Foundation’s selected backend registry services provider, follows. 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, Add Grace Period, Redemption Grace Period, and Notice Periods for Renewals or Transfers.
The Domain Name Create operation is detailed in Figure 273 and requires the following attributes:
A domain name that meets the string restrictions.
A domain name that does not already exist.
The registrar is authorized to create a domain name in livestrong.
The registrar has available credit.
A valid Authorization Information (Auth-Info) value.
Required contacts (e.g., registrant, administrative contact, technical contact, and billing contact) are specified and exist.
The specified name servers (hosts) exist, and there is a maximum of 13 name servers.
A period in units of years with a maximum value of 10 (default period is one year).

Figure 273: Create Process Flow Chart
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, Add Grace Period, Redemption Grace Period, and Notice Periods for Renewals or Transfers.
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 is detailed in Figure 274 and requires the following attributes:
A domain name that exists and is sponsored by the requesting registrar.
The registrar is authorized to renew a domain name in livestrong.
The registrar has available credit.
The passed current expiration date matches the domain name’s expiration date.
A 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.

Figure 274: Renewal Process Flow Chart
Registrar Transfer Procedures. A registrant may transfer his⁄her domain name from his⁄her 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 made available to the registrant upon request. The registrant is the only party other than the current registrar that has access to the Auth-Info. Registrar transfer entails a specified extension of the expiry date for the object. The registrar transfer is a billable operation and is charged identically to a renewal for the same extension of the period. This period can be from one to ten years, in one-year increments.
Because registrar transfer involves an extension of the registration period, the rules and policies applying to how the resulting expiry date is set after transfer are based on the renewal policies on extension.
Per industry standard, a domain name cannot be transferred to another registrar within the first 60 days after registration. This restriction continues to apply if the domain name is renewed during the first 60 days. Transfer of the domain name changes the sponsoring registrar of the domain name, and also changes the child hosts (ns1.sample.xyz) of the domain name (sample .xyz).
The domain name transfer consists of five separate operations:
Transfer Request (Figure 275): 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 276): 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 277): 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 278): 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 279): 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.

Figure 275: Transfer Request Process

Figure 276: Transfer Cancel Process

Figure 277: Transfer Approve Process

Figure 278: Transfer Reject Process

Figure 279: Transfer Query Process
Delete Process. A registrar may choose to delete the domain name at any time.
Process Characterization. The domain name can be deleted, unless it has any form of Pending Delete, Pending Transfer, or Delete Prohibited.
A domain name is also prohibited from deletion if it has any in-zone child hosts that are name servers for domain names. For example, the domain name “sample.xyz” cannot be deleted if an in-zone host “ns.sample.xyz” exists and is a name server for “sample2.xyz.”
If the Domain Name Delete occurs within the Add grace period, the domain name is immediately deleted and the sponsoring registrar is credited for the Domain Name Create. If the Domain Name Delete occurs outside the Add grace period, it follows the Redemption grace period (RGP) lifecycle.
Update Process. The sponsoring registrar can update the following attributes of a domain name:
Auth-Info
Name servers
Contacts (i.e., registrant, administrative contact, technical contact, and billing contact)
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 2710.
A domain name can be updated unless it has any form of Pending Delete, Pending Transfer, or Update Prohibited.


Figure 2710: Update Process Flow Chart
Pending, Locked, Expired, and Transferred
Verisign, The Lance Armstrong Foundation’s selected backend registry services provider, 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
Add Grace Period, Redemption Grace Period, and Notice Periods for Renewals or Transfers
Verisign, The Lance Armstrong Foundation’s selected backend registry services provider, handles Add grace periods, Redemption grace periods, and notice periods for renewals or transfers as described here.
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.
Aspects of the Registration Lifecycle Not Covered by Standard EPP RFCs
The Lance Armstrong Foundation’s selected backend registry services provider’s (Verisign’s) registration lifecycle processes and code implementations adhere to the standard EPP RFCs related to the registration lifecycle. By adhering to the RFCs, Verisign’s registration lifecycle is complete and addresses each registration-related task comprising the lifecycle. No aspect of Verisign’s registration lifecycle is not covered by one of the standard EPP RFCs and thus no additional definitions are provided in this response.
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 livestrong gTLD as well as other TLDs managed by Verisign, The Lance Armstrong Foundation’s selected backend registry services provider; thus Verisign remains consistent with commitments made to its registrants. No unique or specific registration lifecycle modifications or adaptations are required to support the overall business approach for the livestrong gTLD.
To accommodate a range of registries, Verisign’s registry implementation is capable of offering both a thin and thick Whois implementation, which is also built upon Verisign’s award-winning ATLAS infrastructure.
Compliance with relevant RFCs
The Lance Armstrong Foundation’s selected backend registry services provider’s (Verisign’s) registration lifecycle complies with applicable RFCs, specifically RFCs 5730 – 5734 and 3915. 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.

In addition, in accordance with RFCs 5732 and 5733, the Verisign registration system enforces the following domain name registration constraints:
Uniqueness⁄Multiplicity: A second-level domain name is unique in the livestrong database. Two identical second-level domain names cannot simultaneously exist in livestrong. 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.
Registrant
Administrative contact
Technical contact
Billing contact
Domain Name Associations: Each domain name is associated with:
A maximum of 13 hosts, which are created and managed independently according to RFC 5732
An Auth-Info, which is used to authorize certain operations on the object
Status(es), which are used to describe the domain name’s status in the registry
A created date, updated date, and expiry date

Demonstrates that technical resources required to carry through the plans for this element are already on hand or readily available
Verisign, The Lance Armstrong Foundation’s selected backend registry services provider, is an experienced backend registry provider that has developed a set of proprietary resourcing models to project the number and type of personnel resources necessary to operate a TLD. Verisign routinely adjusts these staffing models to account for new tools and process innovations. These models enable Verisign to continually right-size its 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 its staffing models, Verisign derived the necessary personnel levels required for this gTLD’s initial implementation and ongoing maintenance. Verisign’s pricing for the backend registry services it provides to The Lance Armstrong Foundation fully accounts for cost related to this infrastructure, which is provided as “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 its technical work force. (Current statistics are publicly available in Verisign’s quarterly filings.) Drawing from this pool of on-hand and fully committed technical resources, Verisign has maintained DNS operational accuracy and stability 100 percent of the time for more than 13 years for .com, proving Verisign’s ability to align personnel resource growth to the scale increases of Verisign’s TLD service offerings.

Verisign projects it 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 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 livestrong gTLD as described in this application, Verisign, The Lance Armstrong Foundation’s selected backend registry services provider, scales, as needed, the size of each technical area now supporting its portfolio of TLDs. Consistent with its resource modeling, Verisign periodically reviews the level of work to be performed and adjusts staff levels for each technical area.
When usage projections indicate a need for additional staff, Verisign’s 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 its TLDs instead of creating a new entity to manage only this proposed gTLD, Verisign realizes significant economies of scale and ensures its 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 Verisign holds all contributing staff members accountable to the same procedures that guide its execution of the Internet’s largest TLDs (i.e., .com and .net). Moreover, by augmenting existing teams, Verisign affords 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.


28. Abuse Prevention and Mitigation: Applicants should describe the proposed policies and procedures to minimize abusive registrations and other activities that have a negative impact on Internet users. A complete answer should include, but is not limited to:To be eligible for a score of 2, answers must include measures to promote Whois accuracy as well as measures from one other area as described below.A complete answer is expected to be no more than 20 pages.

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
1.1 livestrong Abuse Prevention and Mitigation Implementation Plan
.livestrong will not be open to the public for registration. All instances of this TLD will be licensed to existing partners of The Lance Armstrong Foundation. All partners are contractually bound to use any instance of the TLD within the strict requirements of each of their respective agreements.
1.2 Policies for Handling Complaints Regarding Abuse
.livestrong will not be open to the public for registration.
1.3 Proposed Measures for Removal of Orphan Glue Records
Although orphan glue records often support correct and ordinary operation of the Domain Name System (DNS), registry operators will be 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. The Lance Armstrong Foundation’s selected backend registry services provider’s (Verisign’s) registration system is specifically designed to not allow orphan glue records. Registrars are required to delete⁄move all dependent DNS records before they are allowed to delete the parent domain.
To prevent orphan glue records, Verisign performs the following checks before removing a domain or name server:

Checks during domain delete:
Parent domain delete is not allowed if any other domain in the zone refers to the child name server.
If the parent domain is the only domain using the child name server, then both the domain and the glue record are removed from the zone.

Check during explicit name server delete:
Verisign confirms that the current name server is not referenced by any domain name (in-zone) before deleting the name server.

Zone-file impact:
If the parent domain references the child name server AND if other domains in the zone also reference it AND if the parent domain name is assigned a serverHold status, then the parent domain goes out of the zone but the name server glue record does not.
If no domains 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 The Lance Armstrong Foundation’s abuse plan are provided in Section 2 of this response.
1.5 Measures to Promote Whois Accuracy
〈Applicant to complete: Provide high-level overview of Sections 1.5.1 through 1.5.3. Describe audit procedures or other methods used to verify Whois accuracy. Note that evidence of measures to promote Whois accuracy is required to receive a score of 2 on this response.〉
1.5.1 Authentication of Registrant Information
.livestrong will not be open to the public for registration.
1.5.2 Regular Monitoring of Registration Data for Accuracy and Completeness
Verisign, The Lance Armstrong Foundation’s selected backend registry services provider, has established policies and procedures to encourage registrar compliance with ICANN’s Whois accuracy requirements. Verisign provides the following services to The Lance Armstrong Foundation for incorporation into its full-service registry operations.
Registrar self certification. 〈If the applicant is managing registrars directly, the applicant may need to modify this section. The following text provides a starting point for applicant provided content.〉
The 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, Verisign sends the registrar an automated email confirming that the form was successfully submitted.
Verisign reviews the submitted form to ensure the certifications are compliant.
Verisign sends 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 Verisign has 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, Verisign sends the registrar a Breach Notice and gives the registrar 30 days to cure the breach.
If the registrar does not cure the breach, Verisign terminates 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). Verisign sends 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.5.3 Use of Registrars
.livestrong will not be open to the public for registration.
1.6 Malicious or Abusive Behavior Definitions, Metrics, and Service Level Requirements for Resolution
.livestrong will not be open to the public for registration.
1.7 Controls to Ensure Proper Access to Domain Functions
.livestrong will not be open to the public for registration.
1.7.1 Multi-Factor Authentication
To ensure proper access to domain functions, The Lance Armstrong Foundation incorporates Verisign’s Registry-Registrar Two-Factor Authentication Service into its 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 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. As shown in Figure 28-1, 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.

Figure 28-1: Verisign Registry-Registrar Two-Factor Authentication Service

1.7.2 Requiring Multiple, Unique Points of Contact
.livestrong will not be open to the public for registration.
1.7.3 Requiring the Notification of Multiple, Unique Points of Contact
.livestrong will not be open to the public for registration.
2. Technical plan that is adequately resourced in the planned costs detailed in the financial section
Resource Planning
.livestrong will not be open to the public for registration.
Resource Planning Specific to Backend Registry Activities
Verisign, The Lance Armstrong Foundation’s selected backend registry services provider, is an experienced backend registry provider that has developed a set of proprietary resourcing models to project the number and type of personnel resources necessary to operate a TLD. Verisign routinely adjusts these staffing models to account for new tools and process innovations. These models enable Verisign to continually right-size its 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 its staffing models, Verisign derived the necessary personnel levels required for this gTLD’s initial implementation and ongoing maintenance. Verisign’s pricing for the backend registry services it provides to The Lance Armstrong Foundation fully accounts for cost related to this infrastructure, which is provided as “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 its technical work force. (Current statistics are publicly available in Verisign’s quarterly filings.) Drawing from this pool of on-hand and fully committed technical resources, Verisign has maintained DNS operational accuracy and stability 100 percent of the time for more than 13 years for .com, proving Verisign’s ability to align personnel resource growth to the scale increases of Verisign’s TLD service offerings.
Verisign projects it 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 .livestrong gTLD as described in this application, Verisign, The Lance Armstrong Foundation’s selected backend registry services provider, scales, as needed, the size of each technical area now supporting its portfolio of TLDs. Consistent with its resource modeling, Verisign periodically reviews the level of work to be performed and adjusts staff levels for each technical area.
When usage projections indicate a need for additional staff, Verisign’s 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 its TLDs instead of creating a new entity to manage only this proposed gTLD, Verisign realizes significant economies of scale and ensures its 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 Verisign holds all contributing staff members accountable to the same procedures that guide its execution of the Internet’s largest TLDs (i.e., .com and .net). Moreover, by augmenting existing teams, Verisign affords 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

Verisign, The Lance Armstrong Foundation’s selected backend registry services provider, provides the following domain name abuse prevention services, which The Lance Armstrong Foundation incorporates into its full-service registry operations. These services are 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 Extensible Provisioning Protocol (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, provided via Verisign, The Lance Armstrong Foundation’s subcontractor, 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:
The Lance Armstrong Foundation and⁄or its registrars provides Verisign, The Lance Armstrong Foundation’s selected provider of backend registry services, 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. Verisign then manually authenticates that the registrar submitting the list of domain names is the registrar-of-record for such domain names.
If The Lance Armstrong Foundation and⁄or its registrars requires changes (including updates, deletes, and transfers) to a domain name placed on a server status code, Verisign follows a secure, authenticated process to perform the change. This process includes a request from a The Lance Armstrong Foundation-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 The Lance Armstrong Foundation-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.


The Lance Armstrong Foundation intends to charge registrars based on the market value of the Registry Lock Service. A tiered pricing model is expected, with each tier having an annual fee based on per domain name⁄host and the number of domain names and hosts to be placed on Registry Lock server status code(s).
3.2 Ongoing Anti-Abuse Policies and Procedures
3.1 Policies and Procedures That Identify Malicious or Abusive Behavior
Verisign, The Lance Armstrong Foundation’s selected backend registry services provider, provides the following service to The Lance Armstrong Foundation for incorporation into its full-service registry operations.
Malware scanning service. Registrants are often unknowing victims of malware exploits. Verisign has developed proprietary code to help identify malware in the zones it manages, which in turn helps registrars by identifying malicious code hidden in their domain names.
Verisign’s malware scanning service helps prevent websites from infecting other websites by scanning web pages for embedded malicious content that will infect visitors’ websites. Verisign’s 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 registrar a report that contains the number of malicious domains found and details about malicious content within its TLD zones. Reports with remediation instructions are provided to help registrars and registrants eliminate the identified malware from the registrant’s website.
3.2 Policies and Procedures That Address the Abusive Use of Registered Names
Suspension processes.
.livestrong will not be open to the public for registration.
Suspension processes conducted by backend registry services provider. In the case of domain name abuse, The Lance Armstrong Foundation will determine whether to take down the subject domain name. Verisign, The Lance Armstrong Foundation’s selected backend registry services provider, will follow the following auditable processes to comply with the suspension request.

Verisign Suspension Notification. The Lance Armstrong Foundation submits the suspension request to Verisign for processing, documented by:
Threat domain name
Registry incident number
Incident narrative, threat analytics, screen shots to depict abuse, and⁄or other evidence
Threat classification
Threat urgency description
Recommended timeframe for suspension⁄takedown
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)
Incident response, including surge capacity

Verisign Notification Verification. When Verisign receives a suspension request from The Lance Armstrong Foundation, it performs the following verification procedures:
Validate that all the required data appears in the notification.
Validate that the request for suspension is for a registered domain name.
Return a case number for tracking purposes.

Suspension Rejection. If required data is missing from the suspension request, or the domain name is not registered, the request will be rejected and returned to The Lance Armstrong Foundation with the following information:
Threat domain name
Registry incident number
Verisign case number
Error reason

Registrar Notification (Optional). Once Verisign has performed the domain name suspension, and upon The Lance Armstrong Foundation request, Verisign notifies the registrar of the suspension. Registrar notification includes the following information:
Threat domain name
Registry incident number
Verisign case number
Classification of type of domain name abuse
Evidence of abuse
Anti-abuse contact name and number
Suspension status
Date⁄time of domain name suspension

Registrant Notification (Optional). Once Verisign has performed the domain name suspension, and upon The Lance Armstrong Foundation request, Verisign notifies the registrant of the suspension. Registrant notification includes the following information:
Threat domain name
Registry incident number
Verisign case number
Classification of type of domain name abuse
Evidence of abuse
Registrar anti-abuse contact name and number

Upon The Lance Armstrong Foundation request, Verisign can provide a process for registrants to protest the suspension.
Domain Suspension. Verisign places the domain to be suspended on the following statuses:
serverUpdateProhibited
serverDeleteProhibited
serverTransferProhibited
serverHold

Suspension Acknowledgement. Verisign notifies The Lance Armstrong Foundation that the suspension has been completed. Acknowledgement of the suspension includes the following information:
Threat domain name
Registry incident number
Verisign case number
Case number
Domain name
The Lance Armstrong Foundation abuse contact name and number, or registrar abuse contact name and number
Suspension status

4. When executed in accordance with the Registry Agreement, plans will result in compliance with contractual requirements

5. Technical plan scope⁄scale that is consistent with the overall business approach and planned size of the registry
Scope⁄Scale Consistency

Scope⁄Scale Consistency Specific to Backend Registry Activities
Verisign, The Lance Armstrong Foundation’s selected backend registry services provider, is an experienced backend registry provider that has developed and uses proprietary system scaling models to guide the growth of its TLD supporting infrastructure. These models direct Verisign’s 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. Verisign periodically updates 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 〈new string〉 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 its scaling models, Verisign derived the necessary infrastructure required to implement and sustain this gTLD. Verisign’s pricing for the backend registry services it provides to The Lance Armstrong Foundation fully accounts for cost related to this infrastructure, which is provided as “Other Operating Cost” (Template 1, Line I.L) within the Question 46 financial projections response.
 
Applicant intends to request from ICANN an exemption from Specification 9 of the ICANN-Registry Operator Registry Agreement.  As such, Applicant intends to function in such a way that all domain name registrations in the TLD shall be registered to and maintained by Applicant and Applicant will not sell, distribute or transfer control of domain name registrations to any party that is not an Affiliate of Applicant as defined in the ICANN-Registry Operator Registry Agreement.  All domain name registrations intended to be used within Applicant’s registry will be registered to and controlled and maintained by Applicant and for the benefit of Applicant and its users, parents, sisters and Affiliates.
 
In the event that Applicant is not granted an exemption from Specification 9, Applicant will partner with a corporate registrar with expertise in running a registry to support such efforts.  Applicant intends to partner with its current corporate registrar or one of similar technical capability and expertise and allocate the appropriate funds and human resources to ensure that both itself, as the registry operator, and its selected registrar are at all times in compliance with ICANN guidelines.
 
Several measures for discouraging domain name abuse in the Applicant’s TLD and the registration in the Applicant’s TLD of domain names that infringe the intellectual property rights of others are detailed within this section, in the response to question #29 and throughout other portions of the application.  Additionally, it is noted that a major concern of other TLDs, namely, trademark infringement, is of lesser concern as such relates to the Applicant’s TLD.  There will be little to no risk of domain name abuse and improper registration of any infringing subdomains or the like in the TLD and Applicant believes sufficient protection for famous names and trademarks will be provided for because of the fact that: (i) Applicant’s TLD intends to function as a Specification 9 exempt TLD and, thus, all registrations will be approved by and registered only to Applicant; (ii) Applicant will implement and comply with all ICANN-mandated rights protection mechanisms (see response to question #29), and (iii) Applicant’s  current policies will prohibit any registrations by any party that is not the Applicant and registrations will be associated with Applicant and its users, parents, sisters and Affiliates, and more particularly, the content and branded material associated with those entities.  For that reason, in any case, Applicant believes that there will be little to no likelihood of confusion between the trademark holder and Applicant. As users come to know Applicant’s TLD, they will come to understand that any and all content associated with the TLD is also associated with Applicant and its users, parents, sisters and Affiliates, and no other party.
 
This means that there will be little pressure on current trademark holders to believe that they have to defensively obtain all of their trademarks within the TLD.  One event in which a trademark right may be affected is the unlikely instance in which a commonly known name which is identical or confusingly similar to a trademark is registered.  In this event, a trademark holder may submit a request to Applicant to remove the registration or cease use of the subdomain.  Applicant is committed to making every attempt to resolve such disputes in a fair and equitable manner and demonstrating the high value Applicant places on intellectual property rights, including rights associated with trademarks.  Alternatively, or in addition, the trademark holder is free to file a URS, UDRP or any other dispute resolution action pursuant to the ICANN-approved new gTLD guidelines.  Applicant will comply with any and all decisions and orders issued by the adjudicating bodies of these dispute resolution authorities and procedures.  In particular, protection for trademark holders will be provided, without limitation, during the implementation phase of the Trademark Clearinghouse in compliance with protection mechanisms related to the requirements of Specification 7 of the Registry Agreement, the Trademark Clearinghouse and any other relevant rights protections mechanisms.
 
Furthermore, Applicant will provide to ICANN in this application and publish on its website the abuse policy and contact details (as included below and including a valid email and mailing address) to be responsible or addressing matters requiring attention and to handle inquiries related to malicious conduct in the TLD in a timely manner.
 
Additionally, a reserved list of names will be employed to prevent inappropriate name registrations.  This list may be updated periodically based on ICANN directives and guidance.  This list will include, among others, ICANN’s list of reserved names in the Registry Agreement, and certain geographic identifiers as enumerated in the response to question #22.  The list of names reserved from reservation is enumerated below:
 
•             ICANN and IANA-related names (reserved at second and at all other levels)
o             aso
o             gnso
o             icann
o             internic
o             ccnso
o             afrinic
o             apnic
o             arin
o             example
o             gtld-servers
o             iab
o             iana
o             iana-servers
o             iesg
o             ietf
o             irtf
o             istf
o             lacnic
o             latnic
o             rfc-editor
o             ripe
o             root-servers
•             Single-character and two-character labels (reserved at the second level)
•             Tagged domains – labels with hyphens in the third and fourth character positions
•             Registry operations names – (reserved at the second level) reserved for use in connection with the operation of the registry for the Registry TLD.  Registry Operator may use them, but upon conclusion of Registry Operator’s designation as operator of the registry for the Registry TLD they shall be transferred as specified by ICANN:
o             NIC
o             WHOIS
o             WWW
•             TLD labels (e.g., aero, arpa, biz, com, etc.)
•             Geographic and Geopolitical Names. All geographic and geopolitical names contained in the ISO 3166-1 list from time to time shall initially be reserved at both the second level and at all other levels within the TLD at which the Registry Operator provides for registrations. All names shall be reserved both in English and in all related official languages as may be directed by ICANN or the GAC.
 
o             In addition, Registry Operator shall reserve names of territories, distinct geographic locations, and other geographic and geopolitical names as ICANN may direct from time to time. Such names may be reserved from registration during any sunrise period, and may be registered in ICANN's name prior to start-up and open registration in the TLD. Registry Operator may post and maintain an updated listing of all such names on its website, which list may be subject to change at ICANN's direction. Upon determination by ICANN of appropriate standards and qualifications for registration following input from interested parties in the Internet community, such names may be approved for registration to the appropriate authoritative body.
 
The Applicant’s TLD will comply with all applicable trademark and anti-cybersquatting legislation.  In the event of an inconsistency between such legislation and the procedures of Applicant’s TLD, Applicant will revise its procedures to be in compliance therewith. 
 
Should Applicant function as a Specification 9 exempt Registry Operator, Applicant will restrict the transfer of registrations of domain names within its TLD to third parties.
 
1.1          Abuse Prevention and Mitigation Implementation Plan
In addition to developing ICANN policies and the Applicant policies as articulated above, below and pursuant to the attached Abuse Prevention and Mitigation Implementation Plan, the registration process will limit abusive registration practices commonly associated with TLDs in which abusive registrants use false contact information to evade identification or legal process.  Applicant’s TLD intends to function, per the ICANN-Registry Operator Registry Agreement, as a Specification 9 exempt TLD whereby all domain name registrations in the TLD shall be registered to and maintained by Applicant and Applicant will not sell, distribute or transfer control of domain name registrations to any party that is not an Affiliate of Applicant as defined in the ICANN-Registry Operator Registry Agreement.  All domain name registrations intended to be used within Applicant’s registry will be registered to and controlled and maintained by Applicant and its verified and authenticated Affiliates and for the benefit of Applicant and its users, parents, sisters and Affiliates.  All registrations must be requested through one of Applicant’s internal channels and must be verified and approved before registration.  The verification process will be in operation on an ongoing basis.  The verification process is designed to establish that a prospective registrant meets the registration criteria.
a.            A variety of automated and manual procedures will be utilized for verification, including a cross-check of registration against information held by Applicant.
b.            Eligibility of prospective registrants will be verified prior to the addition of a name to the Applicant’s TLD zone file, including but not limited to, review of the request for registration by Applicant’s compliance staff who will attempt to manually verify the affiliation of the prospective registrant with the Applicant.
c.             Applicant will verify contact/WHOIS data for prospective registrants prior to the addition of a name to the Applicant’s TLD zone file.
d.            Applicant will maintain verified contact data for the actual registrant as well as for any proxy services utilized by registrant.  Proxy services eligible for use are limited to services that have demonstrated responsible and responsive business services.
e.            Prospective registrants must represent and warrant that neither the registration of the desired string, nor the manner in which the registration will be used, infringes the legal rights of third parties.
f.             Prospective registrants will disclose their intended use for the domain. Registration will be refused to those who do not indicate at least one acceptable use of the domain. Acceptable uses of the TLD include, but are not limited to the bona fide use or bona fide intent to use the domain name or any content, software, materials, graphics or other information thereon to permit Internet users to access one or more host computers through the DNS:
•             to exchange goods, services or property of any kind;
•             in the ordinary course of trade or business; or
•             to facilitate the exchange of goods, services, information, or property of any kind, or the ordinary course of trade or business.
Additionally, Applicant will implement a number of mechanisms pursuant to all ICANN guidelines and the Registry Agreement for those who are not affiliated with the Applicant to protect their intellectual property.
a.            Pre-Reservation Service:  Applicant may enable existing holders of a trademark to block Applicant’s TLD registrations that correspond to their existing registrations in other ICANN recognized TLDs. 
b.            Trademark Clearinghouse:  Trademark owners will have an extended period in which they can register their trademarks with the Trademark Clearinghouse.  Once registration begins, if a registrant attempts to register a name that has been registered with the Trademark Clearinghouse, the prospective registrant will be notified of the existence of the registration with the Trademark Clearinghouse.
Dispute Resolution Procedures:  Registered domains will be subject to challenge under ordinary domain dispute procedures set forth by ICANN, including but not limited to, Uniform Domain-Name Dispute-Resolution Policy (UDRP), Uniform Rapid Suspension system (URS), Trademark Post-Delegation Dispute Procedure (PDDRP), and Registration Restriction Dispute Resolution Procedure (RRDRP).  Applicant agrees to implement and adhere to any remedies imposed by decision makers under such procedures.
1.2 Policies for Handling Complaints Regarding Abuse
Applicant reserves the right to deny, cancel or transfer any registration or transaction, or place any domain name(s) on registry lock, hold or similar status, that it deems necessary, in its discretion; (1) to protect the integrity and stability of the registry; (2) to comply with any applicable laws, government rules or requirements, requests of law enforcement, or any dispute resolution process; (3) to avoid any liability, civil or criminal, on the part of Applicant, as well as its Affiliates, subsidiaries, officers, directors, and employees; (4) per the terms of the Registration Agreement; or (5) to correct mistakes made by Applicant or its registrar in connection with a domain name registration.
During review of any complaint, Applicant will consider the standards set forth in the ICANN UDRP, in addition to the following modifications:
a.            Evidence that a domain name is identical or confusingly similar to a trademark or service mark in which the complainant has rights can include evidence that the domain name is “...confusingly similar to a trademark, service mark or trade name in which the complainant has rights or the name under which the complainant does business....”  This will grant standing to an entity based upon the entity’s trade name or name under which it does business.
b.            Evidence that a domain has been registered and is being used in bad faith will require a showing that the domain has been registered and/or is being used in bad faith.  This will allow a claim based upon bad faith on the part of the registrant during either registration or use.
c.             Additional indicia of bad faith use will be considered.  These indicia will include (1) use of the domain name inconsistent with the Code, and (2) use of the domain name in connection with a list of prohibited uses, which will include pornography, hacks/cracks content, etc.  The list of prohibited uses may be compiled by Applicant and outside advisors.
d.            Enumerated circumstances for proving a right and legitimate interest will include trade names and names under which business is done where trademarks and service marks currently are noted.  A showing of bad faith registration or use, however, will be considered as prima facie evidence of no legitimate interest.
Applicant also reserves the right to place upon registry lock, hold or similar status a domain name during resolution of a dispute.
All reports of abuse should be sent to an email address that will be publicly identified by Applicant for receiving reports of abuse.
1.3 Proposed Measures for Removal of Orphan Glue Records
Although orphan glue records often support correct and ordinary operation of the Domain Name System (DNS), registry operators will be 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. Applicant’s selected backend registry services provider’s (Verisign’s) registration system is specifically designed to not allow orphan glue records. Registrars are required to delete/move all dependent DNS records before they are allowed to delete the parent domain.
To prevent orphan glue records, Verisign performs the following checks before removing a domain or name server:
 
Checks during domain delete:
•             Parent domain delete is not allowed if any other domain in the zone refers to the child name server.
•             If the parent domain is the only domain using the child name server, then both the domain and the glue record are removed from the zone.
 
Check during explicit name server delete:
•             Verisign confirms that the current name server is not referenced by any domain name (in-zone) before deleting the name server.
 
Zone-file impact:
•             If the parent domain references the child name server AND if other domains in the zone also reference it AND if the parent domain name is assigned a server Hold status, then the parent domain goes out of the zone but the name server glue record does not.
•             If no domains 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 the Applicant’s abuse plan are provided in Section 2 of this response.
1.5 Measures to Promote WHOIS Accuracy
Applicant will maintain a shared registration system for Applicant’s selected registrar.  WHOIS access will be facilitated in compliance with ICANN policies, including without limitation the Registry Agreement.  It is anticipated that information will be provided which is consistent with the WHOIS information currently provided in other TLDs, including identification of the registrant and contact information therefore, administrative, technical and billing contacts, creation and expiration date and DNS settings.  One way that Applicant may ensure compliance with all applicable policies is to mandate that all requests for domains will be required to come from a verified internal corporate channel to ensure that the requestor is affiliated with Applicant.  Such requests will be subject to an internal review and approval process that may be amended from time to time.  In addition, Applicant may provide for additional measures, such as to conduct audits (e.g., compliance with requirements to make WHOIS available, and with the annual WHOIS Data Reminder Policy (WDRP)); investigate complaints of non-compliance (e.g., responses to WHOIS Data Problem Service (WDPRS) notifications); develop documented internal processes and training for personnel assigned by Applicant to complete WHOIS data to ensure that data is provided completely and accurately.
 
At this point, Applicant anticipates that registrant information will be protected or made available as required by ICANN, applicable law or other regulatory bodies.  For technical details regarding how a complete, up-to-date, reliable and conveniently accessible WHOIS database will be provided, see response to question #26.
 
Applicant ensures that the WHOIS database and access thereto will comply with emerging ICANN privacy policies, if and when they become approved.
1.5.1      Authentication of Registrant Information
Applicant intends to function, per the ICANN-Registry Operator Registry Agreement, as a Specification 9 exempt TLD whereby all domain name registrations in the TLD shall be registered to and maintained by Applicant and Applicant will not sell, distribute or transfer control of domain name registrations to any party that is not an Affiliate of Applicant as defined in the ICANN-Registry Operator Registry Agreement.  All domain name registrations intended to be used within Applicant’s registry will be registered to and controlled and maintained by Applicant and for the benefit of Applicant and its users, parents, sisters and Affiliates.  See also section 1.1 above.
1.5.2      Regular Monitoring of Registration Data for Accuracy and Completeness
Applicant intends to function, per the ICANN-Registry Operator Registry Agreement, as a Specification 9 exempt TLD whereby all domain name registrations in the TLD shall be registered to and maintained by Applicant and Applicant will not sell, distribute or transfer control of domain name registrations to any party that is not an Affiliate of Applicant as defined in the ICANN-Registry Operator Registry Agreement.  All domain name registrations intended to be used within Applicant’s registry will be registered to and controlled and maintained by Applicant and for the benefit of Applicant and its users, parents, sisters and Affiliates.  As the only registrations permitted will be from the Applicant entity, the monitoring of the accuracy of registration data will be reasonable and Applicant will periodically (on at least an annual basis) monitor the accuracy and completeness of such information. Verisign, Applicant’s selected backend registry services provider, has established policies and procedures to encourage registrar compliance with ICANN’s WHOIS accuracy requirements. Verisign provides the following services to Applicant for incorporation into its full-service registry operations.
Verisign, the Applicant’s selected backend registry services provider, has established policies and procedures to encourage registrar compliance with ICANN’s WHOIS accuracy requirements. Verisign provides the following services to the Applicant for incorporation into its full-service registry operations.
Registrar self-certification.  Applicant intends to function, per the ICANN-Registry Operator Registry Agreement, as a Specification 9 exempt TLD whereby all domain name registrations in the TLD shall be registered to and maintained by Applicant and Applicant will not sell, distribute or transfer control of domain name registrations to any party that is not an Affiliate of Applicant as defined in the ICANN-Registry Operator Registry Agreement.  All domain name registrations intended to be used within Applicant’s registry will be registered to and controlled and maintained by Applicant and for the benefit of Applicant and its users, parents, sisters and Affiliates.
 
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). Verisign sends 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. Notwithstanding the above, Applicant intends to function, per the ICANN-Registry Operator Registry Agreement, as a Specification 9 exempt TLD whereby all domain name registrations in the TLD shall be registered to and maintained by Applicant and Applicant will not sell, distribute or transfer control of domain name registrations to any party that is not an Affiliate of Applicant as defined in the ICANN-Registry Operator Registry Agreement.  All domain name registrations intended to be used within Applicant’s registry will be registered to and controlled and maintained by Applicant and for the benefit of Applicant and its users, parents, sisters and Affiliates.
1.5.3      Use of Registrars
Applicant intends to function, per the ICANN-Registry Operator Registry Agreement, as a Specification 9 exempt TLD whereby all domain name registrations in the TLD shall be registered to and maintained by Applicant and Applicant will not sell, distribute or transfer control of domain name registrations to any party that is not an Affiliate of Applicant as defined in the ICANN-Registry Operator Registry Agreement.  All domain name registrations intended to be used within Applicant’s registry will be registered to and controlled and maintained by Applicant and for the benefit of Applicant and its users, parents, sisters and Affiliates.
 
At the appropriate time, between post-submission of this application and prior to the Applicant’s TLD launch, Applicant will identify, determine and engage the proper service provider (e.g. Applicant-approved registrar and/or selected backend registry services provider, Verisign) to support its provision of registration and abuse policies.  Any engagement for the implementation and provision of such services shall be in compliance with all ICANN-mandated regulations, agreements, guidance and policies, as it is of paramount importance of the Applicant to protect the rights of all rightsholders.
1.6          Malicious or Abusive Behavior Definitions, Metrics, and Service Level Requirements for Resolution
Pursuant to the attached Abuse Prevention and Mitigation Implementation Plan, Applicant shall implement the following anti-abuse policy as a guideline:
 
The following definitions and policy (“Applicant Domain Anti-Abuse Policy”) shall be in effect between Applicant and its registrar:
 
Abusive use(s) of domain names in this TLD should not be tolerated.  The nature of such abuses creates security and stability issues for the registry, registrars and registrants, as well as for users of the Internet in general.  Applicant defines abusive use as the wrong or excessive use of power, position or ability, and includes, without limitation, the following:
 
•             Illegal or fraudulent actions;
•             Spam: The use of electronic messaging systems to send unsolicited bulk messages.  The term applies to email spam and similar abuses such as instant messaging spam, mobile messaging spam, and the spamming of websites and Internet forums.  An example, for purposes of illustration, would be the use of email in denial-of-service attacks;
•             Phishing: The use of counterfeit web pages that are designed to trick recipients into divulging sensitive data such as usernames, passwords, or financial data;
•             Pharming: The redirecting of unknowing users to fraudulent sites or services, typically through DNS hijacking or poisoning;
•             Willful distribution of malware: The dissemination of software designed to infiltrate or damage a computer system without the owner's informed consent.  Examples include, without limitation, computer viruses, worms, keyloggers, and trojan horses;
•             Fast-flux hosting: Use of fast-flux techniques to disguise the location of websites or other Internet services, or to avoid detection and mitigation efforts, or to host illegal activities.  Fast-flux techniques use DNS to frequently change the location on the Internet to which the domain name of an Internet host or name server resolves.  Fast-flux hosting may be used only with prior permission of LDH;
•             Botnet command and control: Services run on a domain name that are used to control a collection of compromised computers or "zombies," or to direct denial-of-service attacks (DDoS attacks);
•             Distribution of child pornography; and
•             Illegal Access to Other Computers or Networks: Illegally accessing computers, accounts, or networks belonging to another party, or attempting to penetrate security measures of another individual's system (often known as "hacking").  Also, any activity that might be used as a precursor to an attempted system penetration (e.g., port scan, stealth scan, or other information gathering activity).
 
Applicant reserves the right to deny, cancel or transfer any registration or transaction, or place any domain name(s) on registry lock, hold or similar status, that it deems necessary, in its discretion; (1) to protect the integrity and stability of the registry; (2) to comply with any applicable laws, government rules or requirements, requests of law enforcement, or any dispute resolution process; (3) to avoid any liability, civil or criminal, on the part of Applicant, as well as its Affiliates, subsidiaries, officers, directors, and employees; (4) per the terms of the registration agreement or (5) to correct mistakes made by Applicant or its registrar in connection with a domain name registration.
 
Applicant also reserves the right to place upon registry lock, hold or similar status a domain name during resolution of a dispute.
 
Abusive uses, as defined above, undertaken with respect to domain names in this TLD shall give rise to the right of Applicant to take such actions as per its RRA in its sole discretion.
 
All reports of abuse should be sent to an email address that will be publicly identified by Applicant for receiving reports of abuse.
1.7 Controls to Ensure Proper Access to Domain Functions
Applicant intends to function, per the ICANN-Registry Operator Registry Agreement, as a Specification 9 exempt TLD whereby all domain name registrations in the TLD shall be registered to and maintained by Applicant and Applicant will not sell, distribute or transfer control of domain name registrations to any party that is not an Affiliate of Applicant as defined in the ICANN-Registry Operator Registry Agreement.  All domain name registrations intended to be used within Applicant’s registry will be registered to and controlled and maintained by Applicant and for the benefit of Applicant and its users, parents, sisters and Affiliates.  Access to domain functions will be limited to Applicant and its engaged service provider partners by implementing and complying with their established safeguards and access features as articulated below.
1.7.1 Multi-Factor Authentication
To ensure proper access to domain functions, the Applicant incorporates Verisign’s Registry-Registrar Two-Factor Authentication Service into its 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 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. As shown in Figure 28-1, 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
Unique points of contact (POC) and their respective actions will be determined by Applicant at the appropriate time prior to the implementation of the gTLD.
1.7.3      Requiring the Notification of Multiple, Unique Points of Contact
Unique points of contact (POC) and their respective actions will be determined by Applicant at the appropriate time prior to the implementation of the gTLD.
Technical plan that is adequately resourced in the planned costs detailed in the financial section
Resource Planning
Applicant projects it will use the following personnel roles to support the implementation of the policies articulated in this section:
o             1 senior level executive
o             1 marketing/business manager
o             1 technical manager
o             1 administrative professional
 
To implement and manage Applicant’s gTLD as described in this application, Applicant can scale as needed, and utilize resources provided by our foundation, as defined above.In particular, personnel currently involved in the operation of existing .com and .org and .org business can assist with the needs of this new gTLD and may be transitioned over to supporting the gTLD as the ..com and .org and .org businesses wind down in favor of the new gTLD. In addition to these individuals, Applicant parent entity will support implementation of these policies through the provision of their resources as well as additional outside resources on an as-needed basis.  Support from our foundation will include access to a law department, finance department, information systems, technical support, human resources and such other administrative support that may be required.  In particular, we anticipate using outside advisors and lawyers to assist in managing any disputes which must be resolved.  Once the top level domain has been awarded, we do not anticipate disputes beyond what is frequently encountered in operating the .com and .org.  We will utilize outside advisors to provide the additional talent and resources and specialized knowledge that we cannot cost effectively maintain internally.  Projected costs associated with these resources are further discussed in the response to Question 47 below.
Resource Planning Specific to Backend Registry Activities
Verisign, the Applicant’s selected backend registry services provider, is an experienced backend registry provider that has developed a set of proprietary resourcing models to project the number and type of personnel resources necessary to operate a TLD. Verisign routinely adjusts these staffing models to account for new tools and process innovations. These models enable Verisign to continually right-size its 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 its staffing models, Verisign derived the necessary personnel levels required for this gTLD’s initial implementation and ongoing maintenance. Verisign’s pricing for the backend registry services it provides to the Applicant fully accounts for cost related to this infrastructure, which is provided as “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 its technical work force. (Current statistics are publicly available in Verisign’s quarterly filings.) Drawing from this pool of on-hand and fully committed technical resources, Verisign has maintained DNS operational accuracy and stability 100 percent of the time for more than 13 years for .com and .org, proving Verisign’s ability to align personnel resource growth to the scale increases of Verisign’s TLD service offerings.
Verisign projects it 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 TLD as described in this application, Verisign, the Applicant’s selected backend registry services provider, scales, as needed, the size of each technical area now supporting its portfolio of TLDs. Consistent with its resource modeling, Verisign periodically reviews the level of work to be performed and adjusts staff levels for each technical area.
When usage projections indicate a need for additional staff, Verisign’s 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 its TLDs instead of creating a new entity to manage only this proposed gTLD, Verisign realizes significant economies of scale and ensures its 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 Verisign holds all contributing staff members accountable to the same procedures that guide its execution of the Internet’s largest TLDs (i.e., .com and .org and .net). Moreover, by augmenting existing teams, Verisign affords 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.
Policies and procedures identify and address the abusive use of registered names at start-up and on an ongoing basis
Start-Up Anti-Abuse Policies and Procedures
a.            Pre-Reservation Service:  Applicant may enable existing holders of a trademark to block Applicant registrations that correspond to their existing registrations in other ICANN recognized TLDs. 
b.            Trademark Clearinghouse:  Trademark owners will have an extended period in which they can register their trademarks with the Trademark Clearinghouse.  Once registration begins, if a registrant attempts to register a name that has been registered with the Trademark Clearinghouse, the prospective registrant will be notified of the existence of the registration with the Trademark Clearinghouse.
Ongoing Anti-Abuse Policies and Procedures
Policies and Procedures That Identify Malicious or Abusive Behavior
Verisign, the Applicant’s selected backend registry services provider, provides the following service to the Applicant for incorporation into its full-service registry operations.
Malware scanning service. Registrants are often unknowing victims of malware exploits. Verisign has developed proprietary code to help identify malware in the zones it manages, which in turn helps registrars by identifying malicious code hidden in their domain names.
Verisign’s malware scanning service helps prevent websites from infecting other websites by scanning web pages for embedded malicious content that will infect visitors’ websites. Verisign’s 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 registrar a report that contains the number of malicious domains found and details about malicious content within its TLD zones. Reports with remediation instructions are provided to help registrars and registrants eliminate the identified malware from the registrant’s website.
Policies and Procedures That Address the Abusive Use of Registered Names
Suspension processes. In addition to the safeguards and mechanisms additionally provided for above and below and those required by ICANN and applicable law, rightsholders will have the opportunity to provide written notification of claimed abuse and Applicant will investigate notices of abuse and take appropriate actions pursuant to the policies articulated herein and those required by ICANN and applicable law.
Dispute Resolution Procedures:  Registered domains will be subject to challenge under ordinary domain dispute procedures set forth by ICANN, including but not limited to, Uniform Domain-Name Dispute-Resolution Policy (UDRP), Uniform Rapid Suspension system (URS), Trademark Post-Delegation Dispute Procedure (PDDRP), and Registration Restriction Dispute Resolution Procedure (RRDRP).  Applicant agrees to implement and adhere to any remedies imposed by decision makers under such procedures.
Compliance with Court Orders and Law Enforcement Requests: Applicant reserves the right, but disclaims any obligation or responsibility, to (a) refuse to post or communicate or remove any submission from any Applicant site that is deemed to be abusive and (b) identify any user to third parties, and/or disclose to third parties any submission or personally identifiable information, when we believe in good faith that such identification or disclosure will either (i) facilitate compliance with laws, including, for example, compliance with a court order or subpoena, or (ii) help to enforce these policies and/or other Applicant rules or regulations, and/or protect the safety or security of any person or property, including any Applicant site.  Moreover, we retain all rights to remove Submissions at any time for any reason or no reason whatsoever.  Applicant reserves the right to provide information to third parties pursuant to a contractual or legal obligation.
Takedown Procedures:  Applicant will comply with the terms set forth in the Uniform Rapid Suspension (URS) procedure, Trademark Post-Delegation Dispute Procedure (PDDRP), and Registration Restriction Dispute Resolution Procedure (RRDRP).  Applicant agrees to implement and adhere to any remedies imposed by decision makers under such procedures.  Takedown or Suspension requests provided directly to Applicant must demonstrate the following:
•             The complaint must include complainant’s name, address, and email or telephone number (preferably both), and any legal counsel actively representing you in the matter, including their contact information.
•             The complaint must include specific details concerning the alleged Terms violation, including but not limited to: (i) exact URL(s) where we can see the violation, (ii) for matters where URLs cannot be used (i.e., spam and/or phishing allegations), copies of files used as part of the violation and evidence as to their origins (i.e., emails including full headers), and (iii) any other supporting evidence such as screen shots and/or server log files.
•             The terms violation must currently be in active and verifiable use at the time we investigate the matter.
•             Applicant will suspend a registered domain on orders from a court or authority in an ICANN-approved dispute resolution procedure.  The domain name will be unsuspended in view of an executive proceeding on the matter rejecting the request for suspension or upon a showing that the matter has been resolved in favor of the registrant.  Appeals will be handled through the authority issuing the suspension request.
 
Suspension processes conducted by backend registry services provider. In the case of domain name abuse, the Applicant will determine whether to take down the subject domain name. Verisign, the Applicant’s selected backend registry services provider, will follow the following auditable processes (shown in Figure 28-2) to comply with the suspension request.
Verisign Suspension Notification. The Applicant submits the suspension request to Verisign for processing, documented by:
•             Threat domain name
•             Registry incident number
•             Incident narrative, threat analytics, screen shots to depict abuse, and/or other evidence
•             Threat classification
•             Threat urgency description
•             Recommended timeframe for suspension/takedown
•             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)
•             Incident response, including surge capacity
 
Verisign Notification Verification. When Verisign receives a suspension request from the Applicant, it performs the following verification procedures:
•             Validate that all the required data appears in the notification.
•             Validate that the request for suspension is for a registered domain name.
•             Return a case number for tracking purposes.
Suspension Rejection. If required data is missing from the suspension request, or the domain name is not registered, the request will be rejected and returned to the Applicant with the following information:
•             Threat domain name
•             Registry incident number
•             Verisign case number
•             Error reason
 
When executed in accordance with the Registry Agreement, plans will result in compliance with contractual requirements
The Applicant’s proposed Abuse Prevention and Mitigation Implementation Plan is and shall be consistent with the draft Registry Agreement provided by ICANN, including all Specifications, and when executed, Applicant will be compliant with the contractual requirements of the Registry Agreement, including relevant specifications, as well as any and all emerging ICANN policies, if and when they become approved.  In the event that Applicant’s proposed Abuse Prevention and Mitigation Implementation Plan is not consistent with the Registry Agreement, Applicant will amend the Abuse Prevention and Mitigation Implementation Plan to result in compliance.
Technical plan scope/scale that is consistent with the overall business approach and planned size of the registry
Scope/Scale Consistency
Applicant intends to function, per the ICANN-Registry Operator Registry Agreement, as a Specification 9 exempt TLD whereby all domain name registrations in the TLD shall be registered to and maintained by Applicant and Applicant will not sell, distribute or transfer control of domain name registrations to any party that is not an Affiliate of Applicant as defined in the ICANN-Registry Operator Registry Agreement.  All domain name registrations intended to be used within Applicant’s registry will be registered to and controlled and maintained by Applicant and for the benefit of Applicant and its users, parents, sisters and Affiliates.  Applicant does not intend to register in excess of around one thousand registrations at most.  Within that context, Applicant will continue to ensure that the execution and implementation of these policies are consistent with the plan, objective and size of the registry. 
Scope/Scale Consistency Specific to Backend Registry Activities
Verisign, the Applicant’s selected backend registry services provider, is an experienced backend registry provider that has developed and uses proprietary system scaling models to guide the growth of its TLD supporting infrastructure. These models direct Verisign’s 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. Verisign periodically updates 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 TLD 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 its scaling models, Verisign derived the necessary infrastructure required to implement and sustain this gTLD. Verisign’s pricing for the backend registry services it provides to the Applicant fully accounts for cost related to this infrastructure, which is provided as “Other Operating Cost” (Template 1, Line I.L) within the Question 46 financial projections response.


29. Rights Protection Mechanisms: Applicants must describe how their registry will comply with policies and practices that minimize abusive registrations and other activities that affect the legal rights of others, such as the Uniform Domain Name Dispute Resolution Policy (UDRP), Uniform Rapid Suspension (URS) system, and Trademark Claims and Sunrise services at startup.
A complete answer should include:>To be eligible for a score of 2, answers must also include additional measures specific to rights protection, such as abusive use policies, takedown procedures, registrant pre-verification, or authentication procedures, or other covenants.
A complete answer is expected to be no more than 10 pages.

Mechanisms Designed to Prevent abusive registrations
Rights protection is a core objective of The Lance Armstrong Foundation. The Lance Armstrong Foundationwill 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. The Lance Armstrong Foundation acknowledges 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 .livestrong 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, The Lance Armstrong Foundation cannot fully detail the specific implementation of the Trademark Clearinghouse within this application. The Lance Armstrong Foundation will adhere to all processes and procedures to comply with ICANN guidance once this guidance is finalized.
As described in this response, The Lance Armstrong Foundation will implement a Sunrise period and Trademark Claims service with respect to the registration of domain names within the .livestrong gTLD. Certain aspects of the Sunrise period and⁄or Trademark Claims service may be administered on behalf of The Lance Armstrong Foundation by The Lance Armstrong Foundation-approved registrars or by subcontractors of The Lance Armstrong Foundation, such as its selected backend registry services provider, Verisign.
〈In this space, the applicant should detail its plan to execute these two services. While the text below details the specific services that are implemented (i.e., Sunrise period and Trademark Claims service) and how each service is performed, the text does not detail the entity that is responsible for executing the service. Thus for a complete implementation plan, the applicant should consider defining which entity [(e.g., applicant, applicant-approved registrars, applicant subcontractors (such as its selected backend registry services provider, Verisign)] is charged to execute the required service upon gTLD launch. Furthermore, if the applicant plans to implement any additional mechanisms in support of the .livestrong gTLD, please add them below. For example, if applicant has outlined any eligibility restrictions as part of its registration policies (e.g., in Question 18b-iv of the new gTLD application), or if applicant anticipates defensive registrations and⁄or eligibility dispute resolution procedures, the applicant should include them below.〉
Sunrise Period. As provided by the Trademark Clearinghouse model set forth in the ICANN Applicant Guidebook, the Sunrise service pre-registration procedure for domain names continues for at least 30 days prior to the launch of the general registration of domain names in the gTLD (unless The Lance Armstrong Foundation decides to offer a longer Sunrise period).
During the Sunrise period, holders of marks that have been previously validated by the Trademark Clearinghouse receive notice of domain names that are an identical match (as defined in the ICANN Applicant Guidebook) to their mark(s). Such notice is in accordance with ICANN’s requirements and is provided by The Lance Armstrong Foundation either directly or through The Lance Armstrong Foundation-approved registrars.
The Lance Armstrong Foundation requires all registrants, either directly or through The Lance Armstrong Foundation-approved registrars, to i) affirm that said registrants meet the Sunrise Eligibility Requirements (SER) and ii) submit to the Sunrise Dispute Resolution Policy (SDRP) consistent with Section 6 of the Trademark Clearinghouse model. At a minimum The Lance Armstrong Foundation recognizes and honors all word marks for which a proof of use was submitted and validated by the Trademark Clearinghouse as well as any additional eligibility requirements as specified in Question 18.
During the Sunrise period, The Lance Armstrong Foundation and⁄or The Lance Armstrong Foundation-approved registrars, as applicable, are responsible for determining whether each domain name is eligible to be registered (including in accordance with the SERs).
Trademark Claims Service. As provided by the Trademark Clearinghouse model set forth in the ICANN Applicant Guidebook, all new gTLDs will have to provide a Trademark Claims service for a minimum of 60 days after the launch of the general registration of domain names in the gTLD (Trademark Claims period).
During the Trademark Claims period, in accordance with ICANN’s requirements, The Lance Armstrong Foundation or the The Lance Armstrong Foundation-approved registrar will send a Trademark Claims Notice to any prospective registrant of a domain name that is an identical match (as defined in the ICANN Applicant Guidebook) to any mark that is validated in the Trademark Clearinghouse. The Trademark Claims Notice will include links to the Trademark Claims as listed in the Trademark Clearinghouse and will be provided at no cost.
Prior to registration of said domain name, The Lance Armstrong Foundation or the The Lance Armstrong Foundation-approved registrar will require each prospective registrant to provide the warranties dictated in the Trademark Clearinghouse model set forth in the ICANN Applicant Guidebook. Those warranties will include receipt and understanding of the Trademark Claims Notice and confirmation that registration and use of said domain name will not infringe on the trademark rights of the mark holders listed. Without receipt of said warranties, the The Lance Armstrong Foundation or the The Lance Armstrong Foundation-approved registrar will not process the domain name registration.
Following the registration of a domain name, the The Lance Armstrong Foundation-approved registrar will provide a notice of domain name registration to the holders of marks that have been previously validated by the Trademark Clearinghouse and are an identical match. This notice will be as dictated by ICANN. At a minimum The Lance Armstrong Foundation will recognize and honor all word marks validated by 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, The Lance Armstrong Foundation implements and adheres to RPMs post-launch as mandated by ICANN, and confirms that registrars accredited for the .livestrong gTLD are in compliance with these mechanisms. Certain aspects of these post-launch RPMs may be administered on behalf of The Lance Armstrong Foundation by The Lance Armstrong Foundation-approved registrars or by subcontractors of The Lance Armstrong Foundation, such as its selected backend registry services provider, Verisign.
〈 In this space the applicant should detail its plan to execute these post-launch services. Furthermore, the applicant should include below any additional mechanisms that it plans to implement in support of its applied-for gTLD. For example, the applicant should review the “additional measures” section below to determine whether it will be offering some or all of those options. The applicant may also add to the list.〉
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, The Lance Armstrong Foundation will implement 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 .livestrong 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. The Lance Armstrong Foundation and entities operating on its behalf adhere to all decisions rendered by UDRP providers.
URS: As provided in the Applicant Guidebook, all registries are required to implement the URS. Similar to the UDRP, a complainant files its objection with a URS provider. The URS provider conducts an administrative review for compliance with filing requirements. If the complaint passes review, the URS provider notifies the registry operator and locks the domain. A lock means that the registry restricts all changes to the registration data, but the name will continue to resolve. After the domain is locked, the complaint is served to the domain name registrant, who has an opportunity to respond. 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 URS is terminated and full control of the domain name registration is returned to the domain name registrant. Similar to the existing UDRP, The Lance Armstrong Foundation and entities operating on its behalf adhere to 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. The Lance Armstrong Foundation participates in the PDDRP process as specified in the Applicant Guidebook.

Additional Measures Specific to Rights Protection. The Lance Armstrong Foundation provides additional measures against potentially abusive registrations. These measures help mitigate phishing, pharming, and other Internet security threats. The measures exceed the minimum requirements for RPMs defined by Specification 7 of the Registry Agreement and are available at the time of registration. These measures include:


Rapid Takedown or Suspension Based on Court Orders: The Lance Armstrong Foundation complies promptly with any order from a court of competent jurisdiction that directs it to take any action on a domain name that is within its technical capabilities as a TLD registry. These orders may be issued when abusive content, such as child pornography, counterfeit goods, or illegal pharmaceuticals, is associated with the domain name.
Anti-Abuse Process: The Lance Armstrong Foundation implements an anti-abuse process that is executed based on the type of domain name takedown requested. The anti-abuse process is for malicious exploitation of the DNS infrastructure, such as phishing, botnets, and malware.
Authentication Procedures: Verisign, The Lance Armstrong Foundation’s selected backend registry services provider, uses 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 Lance Armstrong Foundation’s backend registry services provider, 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 makes the request to unlock.
Malware Code Identification: This safeguard reduces opportunities for abusive behaviors that use registered domain names in the gTLD. Registrants are often unknowing victims of malware exploits. As The Lance Armstrong Foundation’s backend registry services provider, Verisign has developed proprietary code to help identify malware in the zones it manages, which in turn helps registrars by identifying malicious code hidden in their domain names.
DNSSEC Signing Service: Domain Name System Security Extensions (DNSSEC) helps mitigate pharming attacks that use cache poisoning to redirect unsuspecting users to fraudulent websites or addresses. It uses public key cryptography to digitally sign DNS data when it comes into the system and then validate it at its destination. The .livestrong gTLD is DNSSEC-enabled as part of Verisign’s core backend registry services.
3. Resourcing Plans
Resource Planning
Resource Planning Specific to Backend Registry Activities
Verisign, The Lance Armstrong Foundation’s selected backend registry services provider, is an experienced backend registry provider that has developed a set of proprietary resourcing models to project the number and type of personnel resources necessary to operate a TLD. Verisign routinely adjusts these staffing models to account for new tools and process innovations. These models enable Verisign to continually right-size its 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 its staffing models, Verisign derived the necessary personnel levels required for this gTLD’s initial implementation and ongoing maintenance. Verisign’s pricing for the backend registry services it provides to The Lance Armstrong Foundation fully accounts for cost related to this infrastructure, which is provided as Line IIb.G, Total Critical Registry Function Cash Outflows, within the Question 46 financial projections response.
Verisign employs more than 1,040 individuals of which more than 775 comprise its technical work force. (Current statistics are publicly available in Verisign’s quarterly filings.) Drawing from this pool of on-hand and fully committed technical resources, Verisign has maintained DNS operational accuracy and stability 100 percent of the time for more than 13 years for .com, proving Verisign’s ability to align personnel resource growth to the scale increases of Verisign’s TLD service offerings.
Verisign projects it 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 .livestrong gTLD as described in this application, Verisign, The Lance Armstrong Foundation’s selected backend registry services provider, scales, as needed, the size of each technical area now supporting its portfolio of TLDs. Consistent with its resource modeling, Verisign periodically reviews the level of work to be performed and adjusts staff levels for each technical area.
When usage projections indicate a need for additional staff, Verisign’s 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 its TLDs instead of creating a new entity to manage only this proposed gTLD, Verisign realizes significant economies of scale and ensures its 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 Verisign holds all contributing staff members accountable to the same procedures that guide its execution of the Internet’s largest TLDs (i.e., .com and .net). Moreover, by augmenting existing teams, Verisign affords 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.


30A. Security Policy: provide a summary of the security policy for the proposed registry, including but not limited to:To be eligible for a score of 2, answers must also include:A summary of the above should be no more than 20 pages. Note that the complete security policy for the registry is required to be submitted in accordance with 30(b).


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
The Lance Armstrong Foundation’s selected backend registry services provider’s (Verisign’s) comprehensive security policy has evolved over the years as part of managing some of the world’s most critical TLDs. Verisign’s Information Security Policy is the primary guideline that sets the baseline for all other policies, procedures, and standards that Verisign follows. This security policy addresses all of the critical components for the management of backend registry services, including architecture, engineering, and operations.
Verisign’s 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: Verisign has 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: Verisign uses 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 .livestrong TLD are based on the standards defined above, each of which is derived from Verisign’s experience and industry best practice. These standards comprise the framework for the overall security solution and applicable processes implemented across all products under Verisign’s 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.
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, The Lance Armstrong Foundation, through its selected backend registry services provider, Verisign, conducts a yearly American Institute of Certified Public Accountants (AICPA) and Canadian Institute of Chartered Accountants (CICA) SAS 70 audit on all of its 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 Verisign’s customer contractual agreements and are in accordance with commercially accepted security controls and practices. Verisign also performs numerous audits throughout the year to verify its security processes and activities. These audits cover many different environments and technologies and validate Verisign’s capability to protect its registry and DNS resolution environments. Figure 30A1 lists a subset of the audits that Verisign conducts. For each audit program or certification listed in Figure 30A1, Verisign has included, as attachments to the Part B component of this response, copies of the assessment reports conducted by the listed third-party auditor. From Verisign’s experience operating registries, it has 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.
Figure 30A1: Verisign Independent Assessment Activities

Augmented Security Levels or Capabilities. See Section 5 of this response.
Commitments Made to Registrants Concerning Security Levels. See Section 4 of this response.
Security capabilities are consistent with the overall business approach and planned size of the registry
Consistency of Business Approach and Planned Size of Registry
〈Applicant to complete: Identification and discussion of any non-Verisign security functionality, equipment, or systems related to the business approach and planned size of registry are provided in this space. This would include discussion of any unique security needs necessary to operate the .livestrong gTLD exclusive of the Verisign backend registry service. This would include, but not be limited to, IT and physical security requirements supported by the necessary independent assessment results. Related IT systems and functionality would also need to be detailed in Section 4 below or the appropriate sub-section of response 30B. If none is required, the two bold headers in this Section 2 should be deleted.〉
Consistency of Backend Registry Services with Business Approach and Planned Size of Registry
Verisign, The Lance Armstrong Foundation’s selected backend registry services provider, is an experienced backend registry provider that has developed and uses proprietary system scaling models to guide the growth of its TLD supporting infrastructure. These models direct Verisign’s 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. Verisign periodically updates 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 .livestrong 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 its scaling models, Verisign derived the necessary infrastructure required to implement and sustain this gTLD. Verisign’s pricing for the backend registry services it provides to The Lance Armstrong Foundation fully accounts for cost related to this infrastructure, which is provided as “Total Critical Registry Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46 financial projections response.
Technical plan adequately resourced in the planned costs detailed in the financial section
Resource Planning
〈Applicant to complete: Non-Verisign personnel requirements and necessary cost details are provided in this space related to security services necessary to operate the .livestrong gTLD exclusive of the Verisign backend registry service. If none is required, the two bold headers in this Section 3 should be deleted.〉
Resource Planning Specific to Backend Registry Activities
Verisign, The Lance Armstrong Foundation’s selected backend registry services provider, is an experienced backend registry provider that has developed a set of proprietary resourcing models to project the number and type of personnel resources necessary to operate a TLD. Verisign routinely adjusts these staffing models to account for new tools and process innovations. These models enable Verisign to continually right-size its 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 its staffing models, Verisign derived the necessary personnel levels required for this gTLD’s initial implementation and ongoing maintenance. Verisign’s pricing for the backend registry services it provides to The Lance Armstrong Foundation fully accounts for cost related to this infrastructure, which is provided as “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 its technical work force. (Current statistics are publicly available in Verisign’s quarterly filings.) Drawing from this pool of on-hand and fully committed technical resources, Verisign has maintained DNS operational accuracy and stability 100 percent of the time for more than 13 years for .com, proving Verisign’s ability to align personnel resource growth to the scale increases of Verisign’s TLD service offerings.
Verisign projects it 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 its security policy:
Information Security Engineers: 11

To implement and manage the .livestrong gTLD as described in this application, Verisign, The Lance Armstrong Foundation’s selected backend registry services provider, scales, as needed, the size of each technical area now supporting its portfolio of TLDs. Consistent with its resource modeling, Verisign periodically reviews the level of work to be performed and adjusts staff levels for each technical area.
When usage projections indicate a need for additional staff, Verisign’s 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 its TLDs instead of creating a new entity to manage only this proposed gTLD, Verisign realizes significant economies of scale and ensures its 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 Verisign holds all contributing staff members accountable to the same procedures that guide its execution of the Internet’s largest TLDs (i.e., .com and .net). Moreover, by augmenting existing teams, Verisign affords 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.
Security measures are consistent with any commitments made to registrants regarding security levels

〈This element depends on the specific application being submitted. Assuming no unique security levels are needed, the following text will be used. 〉
Verisign is The Lance Armstrong Foundation’s selected backend registry services provider. For the .livestrong gTLD, no unique security measures or commitments must be made by Verisign or The Lance Armstrong Foundation to any registrant.
〈This response element is gTLD specific and necessary for applications requiring higher⁄different security measures. The response must align with the response to Question 18 where the purpose of the gTLD is presented. This purpose should disclose specific activities related to the .livestrong gTLD that require added⁄different security needs. This Section 4 defines security requirements (i.e., what requires protection), and Section 5 below details the solution approach to each requirement. Section 2 above correlates the proposed higher⁄different security service with the technical, operational, and financial approach. Section 3 above details the necessary level of resources on hand.〉
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)

〈This element will depend on the specific application being submitted. Assuming no unique security measures are needed, the following text will be used. 〉
No unique security measures are necessary to implement the .livestrong gTLD. As defined in Section 1 of this response, Verisign, The Lance Armstrong Foundation’s selected backend registry services provider, commits 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)

〈 This response element is gTLD specific and necessary for applications requiring higher⁄different security measures. The response addresses each security requirement detailed in Section 4 above, providing the solution approach for each specified security requirement. Include the following paragraph and three bullets followed by the gTLD specific response elements.〉
As defined in Section 1 of this response, Verisign, The Lance Armstrong Foundation’s selected backend registry services provider, commits 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)

〈〈Followed by the gTLD specific and necessary security implementations implemented by the applicant.〉〉



© Internet Corporation For Assigned Names and Numbers.