ICANN New gTLD Application

New gTLD Application Submitted to ICANN by: Alliance-One Services, Inc.

String: CSC

Originally Posted: 13 June 2012

Application ID: 1-1674-60067


Applicant Information


1. Full legal name

Alliance-One Services, Inc.

2. Address of the principal place of business

% CSC Building
8616 Freeport Parkway
Irving TX 75063
US

3. Phone number

+1 703 876 1000

4. Fax number

+1 469 499 8240

5. If applicable, website or URL

http:⁄⁄www.csc.com⁄alliance-one

Primary Contact


6(a). Name

Ms. Elisa Renee Cooper

6(b). Title

Director of Product Marketing

6(c). Address


6(d). Phone Number

+1 208 389 5779

6(e). Fax Number


6(f). Email Address

ecooper4@markmonitor.com

Secondary Contact


7(a). Name

Mr. Christopher Ignacio Marin

7(b). Title

Senior Manager, Digital Marketing Platform

7(c). Address


7(d). Phone Number

+1 562 262 0906

7(e). Fax Number


7(f). Email Address

cmarin@csc.com

Proof of Legal Establishment


8(a). Legal form of the Applicant

Corporation

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

Delaware

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.

Alliance-One is 100% owned by Century LLC. Century LLC is 100% owned by Computer Sciences Corporation.

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

John M. AlbaneseSecretary ⁄ Treasurer and Director
Michael W. RisleyPresident and Director

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

John M. AlbaneseSecretary ⁄ Treasurer and Director
Michael W. RisleyPresident and Director

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

Century LLCNot Applicable

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


Applied-for gTLD string


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

CSC

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


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


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


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


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


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


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


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

Attachments are not displayed on this form.

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


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


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

Applicant has consulted with its registry service operator regarding any potential rendering or operational problems with the applied-for gTLD.  Because the applied-for TLD uses standard characters under The American Standard Code for Information Interchange (ASCII) standard, the registry service operator has ensured us that there are no known or likely operational or rendering problems.

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


Mission/Purpose


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

Alliance-One Services, Inc. (“Applicant”) is a wholly-owned subsidiary of Computer Sciences Corporation, Inc. (“CSC”).  CSC was founded more than 50 years ago in 1959, it has become a $16.2B global information technology (“IT”) services powerhouse.  With worldwide headquarters in the Americas, Australia and Asia, as well as Europe, the Middle East and Africa, CSC was ranked 155 on the Fortune 500 for 2011 and was named one of FORTUNE magazine’s “World’s Most Admired Companies.”  CSC offers a complete spectrum of business and technology solutions and services, including cloud computing, mobility solutions, business transformation services, merger and divestiture solutions, collaboration services, value chain optimization, business intelligence services, technology and infrastructure services, SOA solutions, enterprise systems accelerators, applications portfolio management, remote management and testing, cybersecurity, risk governance consulting, information risk management, security options, network management, end user support services, compute services and management and hosting, and storage and information management.  CSC is organized to serve six (6) major industries, including Financial Services, Health Services, the Public Sector, Technology & Consumer, Manufacturing⁄Aerospace & Defense, and Chemical, Energy & Natural Resources.

Applicant will operate the proposed .CSC gTLD (“the TLD”) on behalf of and for the benefit of its parent company, CSC. CSC’s mission is to maintain its status as a global leader in providing technology-enabled business solutions and services. CSC’s mission demands that it make an absolute commitment to excellence in performance by observing the following management principles: commits to client satisfaction as its most important business objective; recognizes that its accomplishments are the work of the people who comprise CSC; requires the highest standards of professionalism and technical competence from its people; maintains the highest standards of ethics and business conduct and operates at all times within the laws of all countries in which it does business; pursues new business opportunities and commits to success in each undertaking; and achieves financial performance consistent with these principles and commensurate with a leadership position in its industry. CSC enhances its customers’ IT through innovation that harnesses the breadth and depth of Applicant’s information, global network, world class products and services, and talented leadership with the best training. Accordingly, CSC strives to help its clients and customers use IT more efficiently to improve their operations and profitability, focus on core competencies and achieve business results such as increased agility, innovation and top-line growth.

As IT-related websites are among the most vulnerable to fraudulent online activity, the TLD’s purpose is to further assist Applicant and CSC in accomplishing its mission of providing completely secure online technology-enabled solutions and services, and being able to provide customers, clients, affiliates and subsidiaries with the most technologically secure and advanced online environment in which to learn about and access the products and services provided by CSC. The TLD will enable CSC to further its goal of adapting and evolving to the host of ever-changing trends and opportunities in furnishing technology-enabled solutions and services. In keeping with its mission to be a global leader in providing technology-enabled solutions and services in a safe, trusted, and responsible manner, upon delegation of the TLD, Applicant, in conjunction with CSC, will initially conduct consumer marketing and technical research to determine the most effective and safest way for Applicant and CSC to market and provide CSC’s technology-enabled solutions and services to its consumers through the TLD. During this initial research period, Applicant and CSC will likely not use the TLD to provide any information or services to the public, but reserves the right to use the TLD for internal purposes, including consumer and security-based testing the TLD for later public use. After the research is completed, Applicant and CSC reserve the right to continue limiting the TLD use for internal purposes only, or if an adequately secure public use is requested by consumers and proven viable, to expand its TLD use accordingly to match its consumers’ Web-based expectations.


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

i. What is the goal of your proposed gTLD in terms of areas of specialty, service levels, or reputation?

Specialty

Currently, there is no top-level domain dedicated to technology-enabled solutions and services, and no top-level domain dedicated to CSC’s brand. The ultimate goal of the TLD in terms of specialty, assuming market research indicates CSC’s customers and other Internet users would find such resources valuable, is to securely provide a top-level domain dedicated to providing technology-enabled solutions and services to Internet users and customers around the globe under its famous and trusted brand. Allowing CSC, via Applicant, to control its own Internet space for its famous brand gives it the ability to customize its domain and website names and signal to the general population of Internet users that Applicant will securely control websites within the TLD without having to incorporate a non-branded, non-industry-related term such as .com, .net, or .biz. This specialty will benefit Internet users seeking secure online technology-enabled solutions and services without the worry that they will become the next phishing victim.

This specialization simultaneously further makes it easier for Internet users who are looking for CSC-related information and IT information to locate this information more efficiently. The appendage of the TLD indicates to users what they can expect to find at that website under the TLD, namely, premier and secure technology-enabled solutions and services offered solely by CSC. It also has another added benefit in that web addresses will become shorter—one impact of a dearth of ‘good’ web addresses has been for them to get longer over time. Using the TLD not only means CSC’s sites can benefit from having an important keyword in their web address, but it will also be much faster to type in the address. Built into a wider process of web optimization and marketing, the inclusion of the TLD as a keyword in every domain name will likely have positive implications for specialty, security, and global promotion purposes. This will increase traffic to these websites, promote competition, and facilitate use and trust by consumers of technology-enabled solutions and services who prefer shorter domain names and want a trusted source of the specific services they seek.

Service Levels

CSC’s brand represents a unique synthesis of innovation and ingenuity that stands for quality, authenticity, and value. Customer satisfaction is also paramount to the brand’s success, and responsibility for customer satisfaction to both internal and external users and customers calls for impeccable service to ensure that their needs are always met. By empowering customers to simplify their personal and business lives, CSC and Applicant seek to establish long-term relationships based on trust and value. Indeed, all of CSC’s companies’ success depends upon honesty and integrity. To that end, CSC recognizes that the CSC brand thrives based on the companies’ commitment to outstanding customer relations as well as extremely careful selection of Affiliates, as defined below in the registration policies in Section IV.

The goal of the TLD, if made public, will be to ensure the highest level of security, quality, and customer service are provided to CSC’s customers and clients, for whom security and quality is a high priority concern in connection with technology-enabled solutions and services. Primarily, this entails ensuring that only CSC’s employees and agents are able to register and control the second-level domain names in the TLD. Regarding security and quality concerns, this entails contracting with and using proven industry experts to provide the highest possible quality in registry and registrar services so as to not compromise the security and quality of the highly confidential information that CSC and Applicant will provide through the TLD.

CSC, through Applicant, will further endeavor, as it does with its current websites, to provide for any outwardly-facing domain name and website in the TLD customer service available by chat and phone, seven (7) days per week to help any customer attempting to learn about or utilize CSC’s services. Similarly, CSC and Applicant will provide the highest level service to trademark and other legal rights owners by providing an easily accessible point-of-contact on any outwardly-facing domain names and websites.

By focusing on the end user, Applicant will ensure that it is providing the best specialized user experience possible. To do this, Applicant will employ customer focused testing to determine what their expectations are for a CSC-branded Web experience and then tailoring the TLD to its end users. For example, when designing its current websites or adding a new tweak to the look of its homepage, CSC takes great care to ensure that they will ultimately serve the Internet user, rather than its own internal goals or bottom line. Technology-enabled solutions and services will be provided through the most secure websites and networks, and at the highest speeds. Both CSC and Applicant will continue to operate under this principle when designing websites and providing online technology-enabled solutions and services in the TLD.

Reputation

CSC already has a reputation for excellence and superior quality in the IT industry, including online through its current websites and domain names. Indeed, technology-enabled solutions and services are among the most vulnerable to fraudulent online activity, and CSC seeks through the operation of the TLD to maintain a reputation for providing the most secure online environment in the industry for all Internet users to use IT more efficiently. CSC also has a reputation of having enhanced technical capabilities and to be an early adopter of technical advancements in the IT industry. The goal of the TLD, if made public, is to continue to promote CSC’s reputation for excellence and high levels of security and its advanced and enhanced technical capabilities.

The TLD will further strive to be known for ensuring only Applicant’s and Applicant’s Affiliates register domain names in the TLD, that those domain names are used for Applicant and CSC-related purposes at the direction of Applicant and CSC, that all information possible will be kept completely confidential, that the Whois is thick and reliable, and that the TLD is responsive to legal rights owners. Indeed, when Internet users visit a website within the TLD, they should know that Applicant and CSC will be the entity providing its world-renowned products and services, and that they can expect the highest level of online service and security. In all, Applicant will strive to continue to be known as an exemplary and model domain name services citizen through the use of the TLD.

ii. What do you anticipate your proposed gTLD will add to the current space, in terms of competition, differentiation, or innovation?

Competition

The TLD will enhance competition to the current Internet space by allowing CSC to control its own Internet space through Applicant and to have the flexibility to innovate and create new online goods and services, and to reach new geographic areas. These innovations to how the Applicant will provide online technology-enabled solutions and services will incentivize existing and new top-level domains and IT service companies that operate on existing and new top-level domains to also improve the security and quality of the technology-enabled solutions and services they provide online and to accelerate the introduction of new goods and services in order to continue attracting new customers. Thus, the entry of the TLD will benefit consumers by increasing the likelihood of the successful introduction of new and innovative online IT goods and services.

Differentiation

The TLD will be differentiated from all other top-level domains currently available in the marketplace because it will be able to affix its renowned brand to second-level domains as the TLD and indicate to Internet users the source of the TLD. Indeed, no other top-level domain is similar in appearance to the TLD, none is used exclusively technology-enabled solutions and services, and⁄or none exclusively serve CSC’s users and customers. In terms of differentiated uses it will be able to customize the second-level domains within the TLD so as to signify the service offered as well as the source of the service. Finally, unlike in existing top-level domains, only Applicant’s employees and affiliated companies will be ever be allowed to register and⁄or operate domain names within the TLD, allowing the TLD to become unique in that customers do not have to fear corruption, security, spam, phishing, or false or inaccurate information—allowing CSC and Applicant to become a truly trusted provider of online technology-enabled solutions and services in contrast to current top-level domains.

Innovation

CSC is already a recognized leader in online IT innovation. Indeed, technology is at the forefront of CSC’s online IT presence. One of the most crucial issues of importance to Applicant’s customers and clients is quality and legitimacy. The TLD, if publicly used, will allow CSC, through Applicant, to provide information, goods and services to its clients and customers in a more technologically advanced way and allow Applicant to implement technical advances that may not have been capable before in a less secure environment to provide its high-quality solutions and services in a superior way.

Indeed, it is difficult in the current Internet space for CSC to innovate and to provide truly high-quality technology-enabled solutions and services websites. With the TLD, CSC can test the TLD’s use with consumers to facilitate their desired Web experience, and can test the use of the TLD to ensure it meet the highest possible security standard. This innovation will promote competition in the Internet space and provide higher levels of service to its users and customers. Moreover, the TLD will be innovative in that it will allow more people to have greater access to a dedicated and secure technology-enabled solutions and services top-level domain. The TLD will also allow Applicant to securely work in communities where access to IT services is limited and to strive to provide high-quality technology-enabled solutions and services to more people.

iii. What goals does your proposed gTLD have in terms of user experience?

Similarly to how it operates its current domain names and websites in third-party top-level domains Applicant will strive to test, develop, and implement the TLD and its websites to satisfy its customers’ Web expectations in the most secure and quality manner. In doing so, Applicant will take great care to ensure that domain names in the TLD will ultimately serve the Internet user, rather than its own internal goal or bottom line. Accordingly, Applicant and CSC will rely on its consumer and security-driven testing to provide the best user experience possible for those seeking robust, reliable, and secure online technology-enabled solutions and services around the globe. Because users will know that all domain names in the TLD will be owned and operated by CSC and Applicant, Applicant anticipates that the TLD will eventually provide an enhanced and secure online technological experience for those interested in obtaining more information about the services of Applicant and Applicant’s Affiliates, as well as using their IT more efficiently to improve operations and profits. The TLD will serve to differentiate CSC from other IT providers and serve to create a more stable, competitive, and active marketplace.

iv. Provide a complete description of the applicant’s intended registration policies in support of the goals listed above.

In order to support the goals listed above, only the authorized employees of CSC and Applicant will be allowed to register domain names within the TLD. Accordingly, the general public will not be allowed to register, buy, or sell domain names in the TLD. Applicant, however, reserves the right to sell, distribute, or transfer control or use of any registrations in the TLD to any third party that is an Affiliate of Applicant under the control of Applicant for uses as specified by Applicant. Affiliate will be defined for the purpose of this application as (i) a person or entity that, directly or indirectly, through one or more intermediaries, controls, is controlled by, or is under common control with, the person or entity specified (i.e., Applicant), and (ii) control (including the terms “controlled by” and “under common control with”) means the possession, directly or indirectly, of the power to direct or cause the direction of the management or policies of a person or entity, whether through the ownership of securities, as trustee or executor, by serving as an employee or a member of a board of directors or equivalent governing body, by contract, by credit arrangement or otherwise.

Domain names within the TLD will be intended for registration and use only by Applicant or its Affiliates, and domain names under the TLD will not be available to the general public for purchase, sale, or registration. As stated above, Applicant intends to operate a closed registry in order to continue offer the high-quality technology-enabled solutions and services it currently offers on its branded websites in existing top-level domains. Accordingly, policies and decisions regarding the registration and use of domain names within the TLD will continue to be provided through an internal team consisting of Applicant’s and CSC’s existing business and marketing decision-making channels.

The abuse prevention and rights protection policies discussed further herein will, of course, limit the TLD’s domain name policies and will also strive to avoid registering domain names that are confusingly similar to third-party’s trademarks and related rights. Obscene, explicit, and offensive domain names will not be entitled to registration.

v. Will your proposed gTLD impose any measures for protecting the privacy or confidential information of registrants or users? If so, please describe any such measures.

Keeping customer information secure and private is of crucial importance to providers of technology-enabled solutions and services, whose websites and goods and services are particularly vulnerable to online fraudulent online activity. Initially, Applicant and CSC intend to operate a registry with limited access so as to ensure the security and privacy of the information available. As Applicant’s and CSC’s use may expand, Applicant and CSC will take all available steps to maintain the security and privacy of the information collected therein, and will remain in compliance with all confidentiality and security regulations in relevant jurisdictions.

For example, CSC already takes steps to safeguard the information of its current online customers and clients. See e.g. CSC, Privacy Policy, available at http:⁄⁄www.csc.com⁄privacy (December 17, 2010).

If the TLD becomes public-facing such that external users are interacting with domains registered in the TLD, Applicant and CSC will, at a minimum, provide similar security measures.

vi. Describe whether and in what ways outreach and communications will help to achieve your projected benefits.

Outreach and communication are among Applicant’s and CSC’s important goals in connection with the TLD. For example, if the TLD is publicly used, it will provide better and more secure access to technology-enabled solutions and services to consumers throughout the globe. CSC intends to institute marketing and outreach efforts to inform the public about the TLD and the content and information available there.

CSC already uses a number of different outreach and communications methods and venues to get its mission and message out to the public, including but not limited to, press releases, featured videos posted on various Internet sites, social media, including but not limited to blogs, YouTube, Twitter, and Facebook, various mobile applications for iPads, iPhones, and Android devices, various news feeds around the globe, and paid advertising, which includes television and radio commercials, magazine and newspaper print, billboards and posters in major markets, and a variety of digital media. If the TLD is expanded to use by the general Internet public, Applicant and CSC will be able to incorporate the outreach and communication regarding the TLD into CSC’s current branding and marketing efforts to ensure that as many customers and users as possible understand the new resources available and how to interact with them to improve their consumer experience.

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

i. How will multiple applications for a particular domain name be resolved, for example, by auction or on a first-come⁄first-serve basis?

Members of the public will not be able to register domain names in the TLD. Applicant will tightly control registration, and initially only a limited number of designated personnel of Applicant and Applicant’s Affiliates will be able to register domain names after approval by CSC’s existing business and marketing decision-making channels. Therefore, there will not be multiple applications for a particular domain name.

ii. Explain any cost benefits for registrants you intend to implement (e.g., advantageous pricing, introductory discounts, bulk registration discounts).

Members of the public will not be able to register domain names in the TLD. Applicant will tightly control registration, and initially only a limited number of designated personnel of Applicant and Applicant’s Affiliates will be able to register domain names for purposes relating to Applicant after approval by CSC’s existing business and marketing decision-making channels. Therefore, because Applicant will not sell the domain names in the TLD, there are no cost benefits for registrants to implement.

iii. Note that the Registry Agreement requires that registrars be offered the option to obtain initial domain name registrations for periods of one to ten years at the discretion of the registrar, but no greater than ten years. Additionally, the Registry Agreement requires advance written notice of price increases. Do you intend to make contractual commitments to registrants regarding the magnitude of price escalation? If so, please describe your plans.

Members of the public will not be able to register domain names in the TLD. Applicant will tightly control registration, and initially only a limited number of designated personnel of Applicant and Applicant’s Affiliates will be able to register domain names for purposes relating to Applicant after approval by CSC’s existing business and marketing decision-making channels. Therefore, because Applicant will not sell the domain names in the TLD, contractual commitments to registrants regarding price escalation are not relevant to Applicant’s or CSC’s mission or goals for the TLD at this time.

Community-based Designation


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

No

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


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


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


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


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


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

Attachments are not displayed on this form.

Geographic Names


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

No

Protection of Geographic Names


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

As specified throughout this application, Applicant plans to operate the applied-for TLD as a closed registry and shall not permit any third party to register any second-level domain names within the TLD.  Applicant will thus primarily protect the abusive registration of geographic names at the second and other levels in the applied-for gTLD by only allowing Applicant to register and Applicant or its Affiliates (as defined in its registration policy) to use any domains throughout the life of the TLD.

Applicant has thoroughly reviewed Specification 5 of the Registry Agreement, the Government Advisory Committee’s (GAC) “Principles regarding New gTLDs”, and the .INFO methodology for reservation and release of country names. Accordingly, Applicant will, in connection with its registry services operator and registrar, initially reserve from registration by any party names with national or geographic significance at the second level and all other levels within the TLD during the TLD’s Sunrise Period and Trademark Claims Period.

The names with national or geographic significance (“geographic names”) that will be initially blocked are those specified in Specification 5 of the New gTLD Registry Agreement, namely:

- the short form (in English) of all country and territory names contained on the ISO 3166-1 list, as updated from time to time, including the European Union, which is exceptionally reserved on the ISO 3166-1 list, and its scope extended in August 1999 to any application needing to represent the name European Union;

- the United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardization of Geographical Names, Part III Names of Countries of the World; and

- the list of United Nations member states in 6 official United Nations languages prepared by the Working Group on Country Names of the United Nations Conference on the Standardization of Geographical Names.

After working with Applicant’s registry services provider to initially block the above-identified geographic names during any Sunrise Period and Trademark Claims Period, Applicant may allow the reservation of domain names identical to the above-identified geographic names by only Applicant. Thereafter, Applicant will ensure through internal guidelines or by contract that the geographic names will be used only by Applicant and⁄or its Affiliates for promoting, providing information about, and⁄or offering Applicant’s goods and services directly to the customers or potential customers from the relevant country or territory indicated by the domain name. At all times, Applicant will ensure through internal guidelines that all reasonable efforts will be made to reduce user confusion regarding the source or affiliation of the geographic domain name, and that security measures will be taken to protect confidential third-party information in accordance with that geographic area’s data and financial privacy laws.

Registry Services


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

1	CUSTOMARY REGISTRY SERVICES

As Alliance-One Services, Inc.’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 1 summarizes the technical and business components of those registry services, customarily offered by a registry operator (i.e., Verisign), that support this application. These services are currently operational and support both large and small Verisign-managed registries. Customary registry services are provided in the same manner as Verisign provides these services for its existing gTLDs.

Through these established registry services, Verisign has proven its ability to operate a reliable and low-risk registry that supports millions of transactions per day. Verisign is unaware of any potential security or stability concern related to any of these services.

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

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

1.1 Critical Operations of the Registry

i. Receipt of Data from Registrars Concerning Registration of Domain Names and Name Servers
See Item A in Figure 23 1 and Figure 23 2.

ii. Provision to Registrars Status Information Relating to the Zone Servers
Verisign is Alliance-One Services, Inc.’s selected provider of backend registry services. Verisign registry services provisions to registrars status information relating to zone servers for the TLD. The services also allow a domain name to be updated with clientHold, serverHold status, which removes the domain name server details from zone files. This ensures that DNS queries of the domain name are not resolved temporarily. When these hold statuses are removed, the name server details are written back to zone files and DNS queries are again resolved. Figure 23 3 describes the domain name status information and zone insertion indicator provided to registrars. The zone insertion indicator determines whether the name server details of the domain name exist in the zone file for a given domain name status. Verisign also has the capability to withdraw domain names from the zone file in near-real time by changing the domain name statuses upon request by customers, courts, or legal authorities as required.

iii. Dissemination of TLD Zone Files
See Item B in Figure 23 1 and Figure 23 2.

iv. Operation of the Registry Zone Servers
Verisign is Alliance-One Services, Inc.’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 Alliance-One Services, Inc.’s gTLD from a minimum of eight of its primary sites (two on the East Coast of the United States, two on the West Coast of the United States, two in Europe, and two in Asia) and expands resolution sites based on traffic volume and patterns. Further details of the geographic diversity of Verisign’s zone servers are provided in the response to Question 34, Geographic Diversity. Moreover, additional details of Verisign’s zone servers are provided in the response to Question 32, Architecture and the response to Question 35, DNS Service.

v. Dissemination of Contact and Other Information Concerning Domain Name Server Registrations
See Item C in Figure 23 1 and Figure 23 2.

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

Verisign, Alliance-One Services, Inc.’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 .CSC 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.

2.1 Inter-Registrar Transfer Policy (IRTP)
Technical Component: In compliance with the IRTP consensus policy, Verisign, Alliance-One Services, Inc.’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. Alliance-One Services, Inc.’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 Alliance-One Services, Inc. in a consulting capacity as needed.

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

2.2 Add Grace Period (AGP) Limits Policy

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

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

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

2.3 Registry Services Evaluation Policy (RSEP)

Technical Component: Verisign, Alliance-One Services, Inc.’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, Alliance-One Services, Inc.’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 .CSC TLD.

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

Verisign, Alliance-One Services, Inc.’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.

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

3.1 Two-Factor Authentication Service

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

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

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

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

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

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

Demonstration of Technical & Operational Capability


24. Shared Registration System (SRS) Performance

1	ROBUST PLAN FOR OPERATING A RELIABLE SRS

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

Verisign, Alliance-One Services, Inc.’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 .CSC 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 24 1 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 .CSC gTLD. The application servers store Alliance-One Services, Inc.’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.

- Scalability and Performance. Verisign, Alliance-One Services, Inc.’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 24 2 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 .CSC gTLD registry, this flexibility minimizes unplanned downtime and provides a more consistent end-user experience.

1.2 Representative Network Diagrams

Figure 24 3 provides a summary network diagram of Alliance-One Services, Inc.’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.


1.3 Number of Servers

As Alliance-One Services, Inc.’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 .CSC gTLD, Verisign uses a minimum of 100 dedicated servers per SRS site. These servers are virtualized to meet demand.

1.4 Description of Interconnectivity with Other Registry Systems
Figure 24 4 provides a technical overview of the Alliance-One Services, Inc.’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.

1.5 Frequency of Synchronization Between Servers
As Alliance-One Services, Inc.’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.

1.6 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.”

2 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 .CSC 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 Alliance-One Services, Inc. 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.

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

Verisign, the Alliance-One Services, Inc.’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 Alliance-One Services, Inc. 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 .CSC gTLD as described in this application, Verisign, Alliance-One Services, Inc.’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.

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

Section 1.2 (EPP) of Specification 6, Registry Interoperability and Continuity Specifications. Verisign, Alliance-One Services, Inc.’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, Alliance-One Services, Inc. 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 .CSC 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)

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

Verisign, Alliance-One Services, Inc.’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 25 1.

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.

1.1 EPP Interface with Registrars

Verisign, Alliance-One Services, Inc.’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⁄current-registrars⁄epp-sdk⁄index.html).

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

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

Verisign, Alliance-One Services, Inc.’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 .CSC 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 Alliance-One Services, Inc. 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.

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

Verisign, Alliance-One Services, Inc.’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 Alliance-One Services, Inc. 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 .CSC gTLD as described in this application, Verisign, Alliance-One Services, Inc.’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.

4 ABILITY TO COMPLY WITH RELEVANT RFCS

Verisign, Alliance-One Services, Inc.’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 .CSC gTLD, the Shared Registration System (SRS) complies with the following IETF EPP specifications, where the XML templates and XML schemas are defined in the following specifications:

- EPP RGP 3915 (http:⁄⁄www.apps.ietf.org⁄rfc⁄rfc3915.html): EPP Redemption Grace Period (RGP) Mapping specification for support of RGP statuses and support of Restore Request and Restore Report (authored by Verisign’s Scott Hollenbeck)
- EPP 5730 (http:⁄⁄tools.ietf.org⁄html⁄rfc5730): Base EPP specification (authored by Verisign’s Scott Hollenbeck)
- EPP Domain 5731 (http:⁄⁄tools.ietf.org⁄html⁄rfc5731): EPP Domain Name Mapping specification (authored by Verisign’s Scott Hollenbeck)
- EPP Host 5732 (http:⁄⁄tools.ietf.org⁄html⁄rfc5732): EPP Host Mapping specification (authored by Verisign’s Scott Hollenbeck)
- EPP Contact 5733 (http:⁄⁄tools.ietf.org⁄html⁄rfc5733): EPP Contact Mapping specification (authored by Verisign’s Scott Hollenbeck)
- EPP TCP 5734 (http:⁄⁄tools.ietf.org⁄html⁄rfc5734): EPP Transport over Transmission Control Protocol (TCP) specification (authored by Verisign’s Scott Hollenbeck)
- EPP DNSSEC 5910 (http:⁄⁄tools.ietf.org⁄html⁄rfc5910): EPP Domain Name System Security Extensions (DNSSEC) Mapping specification (authored by Verisign’s James Gould and Scott Hollenbeck)

5 PROPRIETARY EPP EXTENSIONS

Verisign, Alliance-One Services, Inc.’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⁄consolidate-mapping.txt): EPP mapping to support a Domain Sync operation for synchronizing domain name expiration dates
- NameStore Extension (http:⁄⁄www.verisigninc.com⁄assets⁄namestore-extension.pdf): EPP extension for routing with an EPP intelligent gateway to a pluggable set of backend products and services
- Low Balance Mapping (http:⁄⁄www.verisigninc.com⁄assets⁄low-balance-mapping.pdf): EPP mapping to support low balance poll messages that proactively notify registrars of a low balance (available credit) condition

As part of the 2006 implementation report to bring the EPP RFC documents from Proposed Standard status to Draft Standard status, an implementation test matrix was completed. Two independently developed EPP client implementations based on the RFCs were tested against the Verisign EPP server for the domain, host, and contact transactions. No compliance-related issues were identified during this test, providing evidence that these extensions comply with RFC 3735 guidelines and further demonstrating Verisign’s ability to design, test, and deploy an RFC-compliant EPP implementation.

5.1 EPP Templates and Schemas

The EPP XML schemas are formal descriptions of the EPP XML templates. They are used to express the set of rules to which the EPP templates must conform in order to be considered valid by the schema. The EPP schemas define the building blocks of the EPP templates, describing the format of the data and the different EPP commands’ request and response formats. The current EPP implementations managed by Verisign, Alliance-One Services, Inc.’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⁄idn-language-tag.pdf.
Schema: This schema describes the extension mapping for the IDN language tag. The mapping extends the EPP domain name mapping to provide additional features required for the provisioning of IDN domain name registrations.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

〈⁄schema〉

XML templates⁄schema for sync-1.0 (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⁄consolidate-mapping.txt.
Schema: This schema describes the extension mapping for the synchronization of domain name registration period expiration dates. This service is known as ʺConsoliDate.ʺ The mapping extends the EPP domain name mapping to provide features that allow a protocol client to end a domain name registration period on a specific month and day.

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

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

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

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

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

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

XML templates⁄schema for namestoreExt-1.1
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〉

6 PROPRIETARY EPP EXTENSION CONSISTENCY WITH REGISTRATION LIFECYCLE

Alliance-One Services, Inc.’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.

26. Whois

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

Verisign, Alliance-One Services, Inc.’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 .CSC 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.

1.1 High-Level Whois System Description

Like all other components of Alliance-One Services, Inc.’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 .CSC 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.CSC
• Click on the appropriate button (Domain, Registrar, or Name Server)
• Enter the applicable parameter:
o Domain name, including the TLD (e.g., EXAMPLE.TLD)
o Full name of the registrar, including punctuation (e.g., Example Registrar, Inc.)
o 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, Alliance-One Services, Inc.’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.

1.2 Relevant Network Diagrams

Figure ‎26 1 provides a summary network diagram of the Whois service provided by Verisign, Alliance-One Services, Inc.’s selected backend registry services provider. The figure details the configuration with one resolution⁄Whois site. For the .CSC 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.

1.3 IT and Infrastructure Resources

Figure ‎26 2 summarizes the IT and infrastructure resources that Verisign, Alliance-One Services, Inc.’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.

1.4 Description of Interconnectivity with Other Registry Systems

Figure ‎26 3 provides a technical overview of the registry system provided by Verisign, Alliance-One Services, Inc.’s selected backend registry services provider, and shows how the Whois service component fits into this larger system and interconnects with other system components.

1.5 Frequency of Synchronization Between Servers

Synchronization between the SRS and the geographically distributed Whois resolution sites occurs approximately every three minutes. Verisign, Alliance-One Services, Inc.’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.

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

Verisign, Alliance-One Services, Inc.’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 .CSC 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 Alliance-One Services, Inc. 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.

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

Verisign, Alliance-One Services, Inc.’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 Alliance-One Services, Inc. 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 .CSC gTLD as described in this application, Verisign, Alliance-One Services, Inc.’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.

4 COMPLIANCE WITH RELEVANT RFC

Alliance-One Services, Inc.’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⁄.

5 COMPLIANCE WITH SPECIFICATIONS 4 AND 10 OF REGISTRY AGREEMENT

In accordance with Specification 4, Verisign, Alliance-One Services, Inc.’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 ‎26 4 through Figure ‎26 6 provide the query and response format for domain name, registrar, and name server data objects.

5.1 Specification 10, RDDS Registry Performance Specifications

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

6 SEARCHABLE WHOIS

Verisign, Alliance-One Services, Inc.’s selected backend registry services provider, provides a searchable Whois service for the .CSC 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)
• Ability to perform exact match, at least, on the following fields: registrar ID, name server name, and name server’s IP address (only applies to IP addresses stored by the registry, i.e., glue records)
• Ability to perform Boolean search supporting, at least, the following logical operators to join a set of search criteria: AND, OR, NOT
• Search results that include domain names that match the selected search criteria

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


• All unauthenticated searches are returned as thin results.
• Registry system authentication is used to grant access to appropriate users for thick Whois data search results.
• Account access is granted by the Alliance-One Services, Inc.’s defined .CSC gTLD admin user.


Potential Forms of Abuse and Related Risk Mitigation. Leveraging its experience providing tiered access to Whois for the .name registry and interacting with ICANN, data protection authorities, and applicable industry groups, Verisign, Alliance-One Services, Inc.’s selected backend registry services provider, is knowledgeable of the likely data mining forms of abuse associated with a searchable Whois service. Figure ‎26 7 summarizes these potential forms of abuse and Verisign’s approach to mitigate the identified risk.

27. Registration Life Cycle

1	COMPLETE KNOWLEDGE AND UNDERSTANDING OF REGISTRATION LIFECYCLES AND STATES

Starting with domain name registration and continuing through domain name delete operations, Alliance-One Services, Inc.’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 27 1 and Figure 27 2 define the registration states comprising the registration lifecycle and explain the trigger points that cause state-to-state transitions. States are represented as green rectangles within Figure 27 1.

1.1 Registration Lifecycle of Create⁄Update⁄Delete

The following section details the create⁄update⁄delete processes and the related renewal process that Verisign, Alliance-One Services, Inc.’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 27-3 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 .CSC.
- 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).

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 27 4 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 .CSC.
- 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.

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

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

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

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

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

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

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

- Auth-Info
- Name servers
- Contacts (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 27 10.

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

1.2 Pending, Locked, Expired, and Transferred

Verisign, Alliance-One Services, Inc.’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

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

Verisign, Alliance-One Services, Inc.’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.

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

Alliance-One Services, Inc.’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.

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

The registration lifecycle described above applies to the .CSC gTLD as well as other TLDs managed by Verisign, Alliance-One Services, Inc.’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 .CSC 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.

3 COMPLIANCE WITH RELEVANT RFCs

Alliance-One Services, Inc.’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 .CSC database. Two identical second-level domain names cannot simultaneously exist in .CSC. 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.
o Registrant
o Administrative contact
o Technical contact
o Billing contact
- Domain Name Associations: Each domain name is associated with:
o A maximum of 13 hosts, which are created and managed independently according to RFC 5732
o An Auth-Info, which is used to authorize certain operations on the object
o Status(es), which are used to describe the domain name’s status in the registry
o A created date, updated date, and expiry date

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

Verisign, Alliance-One Services, Inc.’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 Alliance-One Services, Inc. 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 .CSC gTLD as described in this application, Verisign, Alliance-One Services, Inc.’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

Abuse within the TLD will not be tolerated.  Applicant will implement very strict policies and procedures to minimize abusive registrations and other activities that have a negative impact on Internet users.  

One of Applicant’s primary abuse prevention and mitigation strategies is to ensure that only Applicant registers and Applicant and⁄or its Affiliates (as defined in Applicant’s registration policy) use domain names in the TLD under strict guidelines as set by Applicant. In order to ensure that Applicant does not register abusive domain names, Applicant has appointed a single group of employees as authorized to register, acquire, and⁄or monitor domain names in the TLD.

As stated elsewhere, Applicant will not allow the registration of any domain names, except for those required by ICANN and for internal business or testing purposes, for likely one (1) to five (5) years while it conducts marketing and technical studies on how to best operate the TLD. For example, Applicant will initially register and use only two domain names, namely, [NIC.WHOIS.TLD] to provide access to the TLD’s Whois database and its abuse policy and contact.

Anti-Abuse Policy

Applicant will implement in its internal policies and its Registrar and Registration agreements that all registered domain names in the TLD will be subject to a Domain Name Anti-Abuse Policy (“Abuse Policy”).

The Abuse Policy will provide Applicant with broad power to suspend, cancel, or transfer domain names that violate the Abuse Policy. Applicant will publish the Abuse Policy on its home website at NIC.CSC and clearly provide Applicant’s Abuse Point of Contact (“Abuse Contact”) and its contact information. This information shall consist of, at a minimum, a valid e-mail address dedicated solely to the handling of abuse complaints, and a telephone number and mailing address for the Abuse Contact. Applicant will ensure that this information will be kept accurate and up to date and will be provided to ICANN if and when changes are made. In addition, with respect to inquiries from ICANN-Accredited registrars, Applicant’s registry services provider, Verisign, shall have an additional point of contact to handle requests by registrars related to abusive domain name practices.

Inquiries addressed to the Abuse Contact will be forwarded to the Domain Name Abuse Team, which consists of 3 lawyers, who will review with possible consultation with outside counsel (together, Applicant’s “Legal Team”) and if applicable remedy any Complaint regarding an alleged violation of the Abuse Policy as described in more detail below.

The Abuse Policy will state, at a minimum, that 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 any agreement Applicant has with any party; (5) to correct mistakes made by the Applicant, registry services provider, or any registrar in connection with a domain name registration; (6) during resolution of any dispute regarding the domain; and (7) if a registrant’s pre-authorization or payment fails.

The Abuse Policy will define the abusive use of domain names to include, but not be limited to, the following activities:

• Illegal or fraudulent actions: use of the Applicant’s or Registrarʹs services to violate the laws or regulations of any country, state, or other applicable jurisdiction, or in a manner that adversely affects the legal rights of any other person;

• Spam: use of electronic messaging systems from email addresses from domains in the TLD to send unsolicited bulk messages in violation of applicable laws. The term applies to e-mail spam and similar abuses such as instant messaging spam, mobile messaging spam, and the spamming of Web sites and Internet forums;

• Phishing: use of counterfeit Web pages within the TLD that are designed to trick recipients into divulging sensitive data such as usernames, passwords, or financial data;

• Pharming: redirecting of unknowing users to fraudulent Web sites or services, typically through DNS hijacking or poisoning;

• Willful distribution of malware: dissemination of software designed to infiltrate or damage a third-party computer system without the ownerʹs 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 Web sites 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 PIR;

• 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);

• 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);

• Non-intended Use: use of the domain name other than that which was stated during the registration, without a change of intended use accepted by Applicant;

• Cybersquatting: registration of a domain name confusingly similar to a third party’s name or trademark without any legitimate interest in the name and in bad faith;

• Domain Kiting⁄Tasting: registration of domain names to test their commercial viability before returning them during a Grace Period.

Domain Anti-Abuse Procedure

Applicant will provide a domain name anti-abuse procedure (“Abuse Procedure”) modeled after the Digital Millennium Copyright Act’s notice-and-takedown procedure.

At all times, Applicant will publish on its home website at NIC.CSC the Abuse Policy and Abuse Procedure and the contact information for the Abuse Contact. Inquiries addressed to the Abuse Contact will be addressed to and received by Applicant’s Legal Team who will review and if applicable remedy any Complaint regarding an alleged violation of the Abuse Policy.

Applicant’s Legal Team will first review the Complaint and give it a “quick look” to see if the Complaint reasonably falls within an abusive use as defined by the Abuse Policy. If not, Abuse Contact will write a timely correspondence to Complainant stating that the subject of the complaint clearly does not fall within one of the delineated abusive uses as defined by the Abuse Policy and that Applicant considers the matter closed.

If the quick look does not resolve the matter, Legal Team will timely give the Complaint a full review. If an abusive use is determined, the Abuse Contact will alert the registry services provider to immediately suspend the resolution of the domain name. Legal Team will then immediately notify the registrant of the suspension of the domain name, the nature of the complaint, and provide the registrant with the option to respond within a timely fashion or the domain name will be canceled.

If the registrant responds within a timely period, its response will be reviewed by Legal Team for further review. If Legal Team is satisfied by the registrant’s response that the use is not abusive, Legal Team will submit a timely request to the registry services provider to unsuspend the domain name. The Abuse Contact will then timely notify the Complainant that its complaint was ultimately denied and provide the reasons for the denial. If the registrant does not respond within a timely fashion, the Abuse Contact will notify the registry services provider to cancel the abusive domain name.

This Abuse Procedure will not prejudice either party’s election to pursue another dispute mechanism, such as URS or UDRP.

With the assistance of its back-end registry services provider, Applicant will meet its obligations under Section 2.8 of the Registry Agreement to take reasonable steps to investigate and respond to reports from law enforcement and governmental and quasi-governmental agencies of illegal conduct in connection with the use of its TLD. Accordingly, Applicant will timely respond to legitimate law enforcement inquiries. Any such response shall include, at a minimum, a timely acknowledgement of receipt of the request, questions or comments concerning the request, and an outline of the next steps to be taken by Applicant for a timely resolution of the request.

In the event such request involves any of the activities which can be validated by Applicant’s Legal Team and involves the type of activity set forth in the Abuse Policy, Abuse Contact will timely notify the registry services provider to either suspend or cancel the domain name. If Legal Team determines that it is not an abusive activity, Abuse Contact will timely provide the relevant law enforcement, governmental and⁄or quasi-governmental agency a compelling argument to keep the name in the zone.

Whois Accuracy

Applicant will provide WHOIS accessibility in a reliable, consistent, and predictable fashion in order to promote Whois accuracy.

Applicant will offer thick WHOIS services, in which all authoritative WHOIS data—including contact data—is maintained at the registry. Through Applicant’s registrar and registry services operators, Applicant will maintain timely, unrestricted, and public access to accurate and complete WHOIS information, including all data objects as specified in Specification 4. Moreover, prior to the release of any domain names, Applicant’s registrar will provide Applicant with an authorization code to verify eligible registrants, and Applicant will provide registrar with proper registrant contact information. Upon registration, registrar will verify the authorization code and contact information before the prospective registrant is allowed to proceed.

In order to further promote WHOIS accuracy, Applicant will offer a mechanism whereby third parties can submit complaints directly to the Applicant’s Registry Services Liaison (as opposed to ICANN or the sponsoring Registrar) about inaccurate or incomplete WHOIS data. Such information shall be forwarded to the registrar, who shall be required to address those complaints with their registrants. Within a reasonable time period after forwarding the complaint to the registrar, Applicant’s Registry Liaison will examine the current WHOIS data for names that were alleged to be inaccurate to determine if the information was corrected, the domain name was deleted, or there was some other disposition. If the registrar has failed to take any action, or it is clear that the registrant was either unwilling or unable to correct the inaccuracies, Applicant reserves the right to suspend the applicable domain name(s) until such time as the registrant is able to cure the deficiencies.

In addition, Applicant’s Legal Team will at least twice per year perform a manual review of a random sampling of domain names within the applied-for TLD to test the accuracy of the WHOIS information. Through this review, Legal Team will examine the WHOIS data for evidence of inaccurate or incomplete Whois information. In the event that such errors or missing information exists, it shall be forwarded to the registrar, who shall be required to address such deficiencies with their registrants. Within a reasonable time period, Legal Team will examine the current WHOIS data for names that were alleged to be inaccurate or incomplete to determine if the information was corrected, the domain name was deleted, or there was some other disposition. If the registrar has failed to take any action, or it is clear that the registrant was either unwilling or unable to correct the inaccuracies, Applicant reserves the right to suspend the applicable domain name(s) until such time as the Registrant is able to cure the deficiencies.

Abuse Prevention and Mitigation – Domain Name Access

All domain name registrants will have adequate controls to ensure proper access to domain functions.

In addition to the above, all domain name registrants in the applied-for TLD will be required to name at least two (2) unique points of contact who are authorized to request and⁄or approve update, transfer, and deletion requests. The points of contact will establish strong passwords with the registrar that must be authenticated before a point of contact will be allowed to process updates, transfer, and deletion requests. Once a process update, transfer, or deletion request is entered, the points of contact will automatically be notified when a domain has been updated, transferred, or deleted through an automated system run by Applicant’s registrar.

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

Resourcing Plans

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

Regular Monitoring of Registration Data for Accuracy and Completeness

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.
Registrar self certification.

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.

Multi-Factor Authentication

To ensure proper access to domain functions, 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.

2. Technical plan that is adequately resourced in the planned costs detailed in the financial section

Resource Planning Specific to Backend Registry Activities

Verisign, 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 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, 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, 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 .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 That Identify Malicious or Abusive Behavior

Verisign, Applicant’s selected backend registry services provider, provides the following service to 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 conducted by backend registry services provider. In the case of domain name abuse, Applicant will determine whether to take down the subject domain name. Verisign, Applicant’s selected backend registry services provider, will follow the following auditable processes to comply with the suspension request.

Verisign Suspension Notification. 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 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 Applicant with the following information:

• Threat domain name
• Registry incident number
• Verisign case number
• Error reason

Upon Applicant 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 Applicant 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
• Applicant abuse contact name and number, or registrar abuse contact name and number
• Suspension status

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

Applicant certifies that its anti-abuse plans will result in compliance with its contractual requirements under the Registry Agreement.

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

Scope⁄Scale Consistency

Applicant certifies that its anti-abuse plans are consistent with the technical, operational, and financial approach described in the application, and any commitments made to registrants.

Scope⁄Scale Consistency Specific to Backend Registry Activities

Verisign, 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 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

Use of domain names that infringe upon the legal rights of others in the TLD will not be tolerated and preventing abusive registrations is a core objective of Applicant.  The nature of such uses creates security and stability issues for the registry, registrars, and registrants, as well as for users of the Internet in general.  Primarily, Applicant will prevent abusive registrations by allowing only Applicant to register and Applicant and⁄or its Affiliates (as defined in Applicant’s Registration Policy) to use domain names in the registry under strict internal registration, anti-abuse and rights protection guidelines as defined in its Abuse Policy.  In order to identify and address the abusive use of registered names on an ongoing basis, Applicant promises to additionally incorporate and abide by the following Rights Protection Mechanisms and all other rights protection mechanisms as specified in Specification 7 of the Registry Agreement and as adopted by the ICANN Board of Directors as ICANN Consensus Policies.

Anti-Abuse Policy

Applicant will implement in its internal policies and its Registrar and Registration agreements that all registered domain names in the TLD will be subject to a Domain Name Anti-Abuse Policy (“Abuse Policy”).

The Abuse Policy will provide Applicant with broad power to suspend, cancel, or transfer domain names that violate the Abuse Policy. Applicant will publish the Abuse Policy on its home website at NIC.CSC and clearly provide Applicant’s Abuse Point of Contact (“Abuse Contact”) and its contact information. This information shall consist of, at a minimum, a valid e-mail address dedicated solely to the handling of abuse complaints, and a telephone number and mailing address for the Abuse Contact. Applicant will ensure that this information will be kept accurate and up to date and will be provided to ICANN if and when changes are made. In addition, with respect to inquiries from ICANN-Accredited registrars, Applicant’s registry services provider, Verisign, shall have an additional point of contact to handle requests by registrars related to abusive domain name practices.

Inquiries addressed to the Abuse Contact will be forwarded to Domain Name Abuse Team, which consists of 3 lawyers, who will review with possible consultation with outside counsel (together, Applicant’s “Legal Team”) and if applicable remedy any Complaint regarding an alleged violation of the Abuse Policy as described in more detail below.

The Abuse Policy will state, at a minimum, that 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 any agreement Applicant has with any party; (5) to correct mistakes made by the Applicant, registry services provider, or any registrar in connection with a domain name registration; (6) during resolution of any dispute regarding the domain; and (7) if a registrant’s pre-authorization or payment fails.

The Abuse Policy will define the abusive use of domain names to include, but not be limited to, the following activities:

• Illegal or fraudulent actions: use of the Applicant’s or Registrarʹs services to violate the laws or regulations of any country, state, or other applicable jurisdiction, or in a manner that adversely affects the legal rights of any other person;

• Spam: use of electronic messaging systems from email addresses from domains in the TLD to send unsolicited bulk messages in violation of applicable laws. The term applies to e-mail spam and similar abuses such as instant messaging spam, mobile messaging spam, and the spamming of Web sites and Internet forums;

• Phishing: use of counterfeit Web pages within the TLD that are designed to trick recipients into divulging sensitive data such as usernames, passwords, or financial data;

• Pharming: redirecting of unknowing users to fraudulent Web sites or services, typically through DNS hijacking or poisoning;

• Willful distribution of malware: dissemination of software designed to infiltrate or damage a third-party computer system without the ownerʹs 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 Web sites 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 PIR;

• 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);

• 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);

• Non-intended Use: use of the domain name other than that which was stated during the registration, without a change of intended use accepted by Applicant;

• Cybersquatting: registration of a domain name confusingly similar to a third party’s name or trademark without any legitimate interest in the name and in bad faith;

• Domain Kiting⁄Tasting: registration of domain names to test their commercial viability before returning them during a Grace Period.

Trademark Clearinghouse

The first mandatory rights protection mechanism (“RPM”) required to be implemented by each new gTLD Registry is support for, and interaction with, the Trademark Clearinghouse. The Trademark Clearinghouse is intended to serve as a central repository for information to be authenticated, stored, and disseminated pertaining to the rights of trademark holders. The data maintained in the clearinghouse will support and facilitate other RPMs, including the mandatory Sunrise Period and Trademark Claims service. Although many of the details of how the Trademark Clearinghouse will interact with each registry operator and registrars are still being developed by ICANN, Applicant is actively monitoring the developments of the Implementation Assistance Group (“IAG”) designed to assist ICANN staff in refining and finalizing the rules and procedures associated with the policies and technical requirements for the Trademark Clearinghouse. In addition, Applicant’s back-end registry services provider is actively participating in the IAG to ensure that the protections afforded by the Clearinghouse and associated RPMs are feasible and implementable.

Utilizing the Trademark Clearinghouse, all operators of new gTLDs must offer: (i) a Sunrise registration service for at least 30 days during the pre-launch phase giving eligible trademark owners an early opportunity to register second-level domains in new gTLDs; and (ii) a Trademark Claims service for at least the first 60 days that second-level registrations are open. The Trademark Claims service is intended to provide clear notice to a potential registrant of the rights of a trademark owner whose trademark is registered in the clearinghouse.

Sunrise Period

All domain names registered during the Sunrise Period will be subject to Applicant’s domain name registration policy, namely, that all registrants be Applicant. Applicant will offer a Sunrise Period of sixty (60) days for owners of trademarks listed in the Trademark Clearinghouse that also meet applicant’s domain name registration requirements to register domain names that consist of an identical match of their listed trademarks. Applicant’s Sunrise Validation Team, which consists of 3 lawyers, will receive and authenticate with possible consultation with outside counsel (together, Applicant’s “Legal Team”) all Sunrise Registrations.

Applicant’s registrar will ensure that all Sunrise Registrants meet sunrise eligibility requirements (SERs), which will be verified by Clearinghouse data. The proposed SERs include: (i) ownership of a mark that is (a) nationally or regionally registered and for which proof of use, such as a declaration and a single specimen of current use – was submitted to, and validated by, the Trademark Clearinghouse; or (b) that have been court-validated; or (c) that are specifically protected by a statute or treaty currently in effect and that was in effect on or before 26 June 2008, (ii) optional registry elected requirements re: international class of goods or services covered by registration; (iii) representation that all provided information is true and correct; and (iv) provision of data sufficient to document rights in the trademark.

Upon submission of all of the required information and documentation, registrar will forward the information to Applicant’s Legal Team for authentication. Legal Team will review the information and documentation and verify the trademark information and registration eligibility, and notify the potential registrant of any deficiencies. If a registrant does not cure any deficiencies and⁄or respond by the means listed within a timely matter, Applicant’s Registry Services Liaison will notify its registrar and the domain name will be released for registration.

Applicant will incorporate a Sunrise Dispute Resolution Policy (SDRP). The SRDP will allow challenges to Sunrise Registrations by third parties for a ten-day period after acceptance of the registration based on the following four grounds: (i) at time the challenged domain name was registered, the registrant did not hold a trademark registration of national effect (or regional effect) or the trademark had not been court-validated or protected by statute or treaty; (ii) the domain name is not identical to the mark on which the registrant based its Sunrise registration; (iii) the trademark registration on which the registrant based its Sunrise registration is not of national or regional effect or the trademark had not been court-validated or protected by statute or treaty; or (iv) the trademark registration on which the domain name registrant based its Sunrise registration did not issue on or before the effective date of the Registry Agreement and was not applied for on or before ICANN announced the applications received.

After receiving a Sunrise Complaint, Legal Team will review the Complaint to see if the Complaint reasonably asserts a legitimate challenge as defined by the SDRP. If not, Legal Team will timely send an email to the Complainant that the subject of the complaint clearly does not fall within one of the delineated grounds as defined by the SDRP and that Applicant considers the matter closed.

If the domain name is not found to have adequately met the SERs, Legal Team will alert the registrar and registry services provider to immediately suspend the resolution of the domain name. Thereafter, Legal Team will immediately notify the Sunrise Registrant of the suspension of the domain name, the nature of the complaint, and provide the registrant with the option to timely cure the SER deficiencies or the domain name will be canceled.

If the registrant timely responds, its response will be reviewed by Legal Team to determine if the SERs are met. If Legal Team is satisfied by the registrant’s response, Legal Team will timely submit a request to the registrar and the registry services provider to unsuspend the domain name. If registrant does not timely respond, Legal Team will then timely notify the Complainant that its complaint was ultimately denied and provide the reasons for the denial.

Trademark Claims Service

Applicant will offer a Trademark Claims Service during the first one hundred and twenty (120) days of general registration. The Trademark Claims Service will be monitored by Legal Team. Applicant’s registrar will be required to review all domain names requested to be registered during the Trademark Claims period to determine if they are an identical match of a trademark that has been filed with the Trademark Clearinghouse and they meet Applicant’s domain name registration requirements. A domain name will be considered an identical match when the domain name consists of the complete and identical textual elements of the mark, and includes domain names where (a) spaces contained within a mark that are either replaced by hyphens (and vice versa) or omitted; (b) certain special characters contained within a trademark are spelled out with appropriate words describing it (e.g., @ and &); and (c) punctuation or special characters contained within a mark that are unable to be used in a second-level domain name are either (i) omitted or (ii) replaced by spaces, hyphens or underscores. Domain names that are plural forms of a mark or that merely contain a mark will not qualify as an identical match.

If the registrar determines that a prospective domain name registration is identical to a mark registered in the Trademark Clearinghouse, the registrar will be required to ensure that a “Trademark Claims Notice” (“Notice”) in English is sent to the protective registrant of the domain name and blind copy Legal Team on all such correspondence. The Notice will provide the prospective registrant information regarding the trademark referenced in the Trademark Claims Notice to enhance understanding of the Trademark rights being claimed by the trademark holder. The Notice will be provided in real time without cost to the prospective registrant.

After sending the Notice, the registrar will be required to require that the prospective registrant specifically warrant within five (5) days that: (i) the prospective registrant has received notification that the mark(s) is included in the Clearinghouse; (ii) the prospective registrant has received and understood the notice; and (iii) to the best of the prospective registrant’s knowledge that the registration and use of the requested domain name will not infringe on the rights that are the subject of the notice. If the warranty satisfies these requirements, the registrar will be required to effectuate the registration and notify Legal Team.

After the effectuation of a registration that is identical to a mark listed in the Trademark Clearinghouse, the registrar will be required to then ensure that a clear notice to the trademark owner of the trademark consisting of the domain name that has been registered and will blind copy Legal Team confirming that it has done so. The trademark owner then has the option of filing a Complaint under the Uniform Domain Name Dispute Resolution Policy (UDRP) and the Uniform Rapid Suspension System (URS) against the domain name, as the Applicant will require in its domain name registration agreements that the registry, registrar, and registrant all submit to the Uniform Domain Name Dispute Resolution Policy (UDRP) and the Uniform Rapid Suspension (URS) system. Applicant will require its registrar and registry service operators to abide by decisions rendered under the UDRP and URS in a timely and ongoing basis.

Uniform Rapid Suspension System (URS)

Applicant will specify in its Registry-Registrar and Registration Agreements used in connection with the TLD that all parties will timely abide by all decisions made by panels in accordance with the Uniform Rapid Suspension System (URS). On Applicant’s NIC.CSC website, Applicant will designate a Rights Protection Contact (“Rights Contact”) that will receive all URS Complaints verified by the URS Provider and provide its contact information. This information shall consist of, at a minimum, a valid e-mail address dedicated solely to the handling of rights protection complaints, and a telephone number and mailing address for the Rights Contact. Applicant will ensure that this information will be kept accurate and up to date and will be provided to ICANN if and when changes are made.

Within 24 hours of receipt of the Notice of Complaint from the URS Provider, the Rights Contact shall notify its registry operator to “lock” the domain, meaning the registry shall restrict all changes to the registration data, including transfer and deletion of the domain names, but the name will continue to resolve. The Rights Contact will notify the URS Provider immediately upon locking the domain name (”Notice of Lock”).

Immediately upon receipt of a Determination in the Complainant’s favor, Rights Contact will notify the registry operator to suspend the domain name, which shall remain suspended for the balance of the registration period and will not resolve to the original web site. The nameservers shall be redirected to an informational web page provided by the URS Provider about the URS. The Whois for the domain name shall continue to display all of the information of the original Registrant except for the redirection of the nameservers. In addition, the Whois shall reflect that the domain name will not be able to be transferred, deleted or modified for the life of the registration. Finally, Applicant will be sure to abide by any timely requests by Complainant to extend the registration period for one additional year at commercial rates.

Immediately upon receipt of a Determination in registrant’s favor, Rights Contact will notify the registry operator to unlock the domain name.

Uniform Domain Name Dispute Resolution Policy (UDRP)

Applicant will specify in its Registry-Registrar and Registration Agreements used in connection with the TLD that all parties will timely abide by all decisions made by panels in accordance with the Uniform Domain Name Dispute Resolution Policy (UDRP). Applicant’s Rights Contact will receive all UDRP Complaints and decisions, temporarily lock any domain names as required, and will notify its registrar to timely cancel or transfer all registrations determined to by a UDRP panel to be infringing.

Trademark Post-Delegation Dispute Resolution Procedure (Trademark PDDRP)

Applicant will participate in all post-delegation procedures, including the Trademark Post-Delegation Dispute Resolution Procedure (Trademark PDDRP), and will timely abide by any Determinations of any PDDRP Provider after exhaustion of all appeals and⁄or times to appeal or other determination challenges.

Registry Restrictions Dispute Resolution Procedure (RRDRP)

Because the application is not community-based, Applicant is not required to participate in the RRDRP and will not be bound by any Determinations of a RRDRP Provider.

Proven Registrars

Applicant intends that only Applicant will be permitted to register domain names in the TLD for its own exclusive use. Hence, Applicant is exempt from the Registry Operator Code of Conduct (“ROCC”) as detailed in Specification 9 of the Registry Agreement with ICANN. Thus, as Applicant is not required to grant access to the TLD to all registrars, and in order to reduce abusive registrations and other activities that affect the legal rights of others, Applicant will only contract with one ICANN-accredited registrar that has proven capable of providing adequate defenses against abusive registrations and superior response capabilities. The registrar, according to the Registry-Registrar agreement, will not be able to register any domain names, thus eliminating the possibility of front-running. The Registrar will also agree not to submit fake renewal notices. Any evidence of abusive behavior on the part of the Registrar will be promptly reported to ICANN Compliance.

Pre-Authorization and Authentication

Prior to the release of any domain names, Applicant will designate that only designated employees will be authorized to register domain names within the TLD under strict domain name registration guidelines. Also, Applicant’s registrar will provide Applicant with an authorization code to provide when registering domain names, and Applicant’s authorized employees will provide registrar with authorized registrant contact information to verify upon the attempted registration of any domain names. Upon registration, registrar will verify the authorization code and contact information before the prospective registrant is allowed to proceed.

A variety of automated and manual procedures will be utilized for verification by the registrar as specified below:

• Applicant’s registrar’s automated authentication process will authenticate that the prospective registrant has provided an authorization code as created by registrar;

• Applicant’s registrar’s automated authentication process will authenticate that the registrant’s email is from Applicant based on a list of pre-approved email extensions from authorized related companies;

• If authenticated, the authentication process will send a unique HTML link to the registrant’s email of record;

• If the automatic verification process does not provide verification, the request will be referred to Applicant’s Registry Services Liaison, which will attempt to verify the registrant manually based on the pre-approved list of Applicant or Related Companies;

• After pre-approval, Registrant must represent and warrant - in both the registration agreement and again as part of the WHOIS verification process - that neither the registration of the desired domain name, nor the manner in which the registration will be used, infringes the legal rights of third parties;

• Registrant must sign and provide a statement declaring that they will use the domain name for the promotion of, providing public awareness of, and⁄or offering Applicant’s goods and services.

In addition, Applicant’s Legal Team will at least twice per year perform a manual review of a random sampling of domain names within the applied-for TLD to test the accuracy and authenticity of the WHOIS information. Through this review, Legal Team will examine the WHOIS data for evidence of inaccurate or incomplete Whois information. In the event that such errors or missing information exists, it shall be forwarded to the registrar, who shall be required to address such deficiencies with their registrants. Within a reasonable time period, Legal Team will examine the current WHOIS data for names that were alleged to be inaccurate or incomplete to determine if the information was corrected, the domain name was deleted, or there was some other disposition. If the registrar has failed to take any action, or it is clear that the registrant was either unwilling or unable to correct the inaccuracies, Applicant reserves the right to suspend the applicable domain name(s) until such time as the Registrant is able to cure the deficiencies.

Thick Whois

Applicant will include a thick WHOIS database as required in Specification 4 of the Registry agreement. A thick WHOIS provides numerous advantages including a centralized location of registrant information, the ability to more easily manage and control the accuracy of data, and a consistent user experience.

Grace Period

Applicant will not allow a grace period for any domain name during the life of the TLD. [Get more information from registrar and registrations].

Takedown Procedure

Applicant will provide a Rights Protection Takedown Procedure (“Takedown Procedure”) modeled after the Digital Millennium Copyright Act’s notice-and-takedown procedure.

At all times, Applicant will publish on its home website at NIC.CSC contact information for receiving rights protection complaints (Complaints) from rightsholders. At all times, Applicant will publish on its website at NIC.CSC the Takedown Procedure and the contact information for the Rights Contact.

Inquiries addressed to the Rights Contact will be forwarded to Applicant’s Legal Team who will remedy or deny any Complaint regarding an alleged violation of the rights of the Complainant. During the review of any Complaint, Legal Team will first give the Complaint a “quick look” to see if the Complaint reasonably alleges the infringement of any legal right. If not, the Rights Contact will write a timely correspondence to Complainant stating that the subject of the complaint clearly does not violate its rights.

If the quick look does not resolve the matter, Legal Team will timely give the Complaint a full review. If a rights infringement is determined, the Rights Contact will alert the registry services provider to immediately suspend the resolution of the domain name. Legal Team will then immediately notify the registrant of the suspension of the domain name, the nature of the complaint, and provide the registrant with the option to respond or take down the infringing content within a timely fashion or the domain name will be canceled.

If the registrant responds within a timely period, its response will be reviewed by Legal Team for further review. If Legal Team is satisfied by the registrant’s response that no rights have been infringed, Legal Team will submit a timely request to the registry services provider to unsuspend the domain name. The Rights Contact will then timely notify the Complainant that its complaint was ultimately denied and provide the reasons for the denial. If the registrant does not respond within a timely fashion, the Rights Contact will notify the registry services provider to cancel the abusive domain name.

This Takedown Procedure will not prejudice either party’s election to pursue another dispute mechanism, such as URS or UDRP.

With the assistance of its back-end registry services provider, Applicant will meet its obligations under Section 2.8 of the Registry Agreement to take reasonable steps to investigate and respond to reports from law enforcement and governmental and quasi-governmental agencies of illegal conduct in connection with the use of its TLD. Applicant will accordingly timely respond to legitimate law enforcement inquiries. Any such response shall include, at a minimum, an acknowledgement of receipt of the request, questions, or comments concerning the request, and an outline of the next steps to be taken by Applicant for a timely resolution of the request.

In the event such request involves any infringing activity which can be validated by Applicant’s Legal Team, Rights Contact will timely notify the registry services provider to either suspend the domain name until the infringing activity is cured or cancel the domain name. If Legal Team determines that it is not an infringing activity, Rights Contact will timely provide the relevant law enforcement, governmental and⁄or quasi-governmental agency a compelling argument to keep the name in the zone.

Additional Measures Specific to Rights Protection. Applicant 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: Applicant 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: Applicant 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, Applicant’s selected backend registry services provider, uses two-factor authentication to augment security protocols for telephone, email, and chat communications.

• 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 Applicant’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 TLD is DNSSEC-enabled as part of Verisign’s core backend registry services.

Resource Planning Specific to Backend Registry Activities

Verisign, 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 Applicant 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 TLD as described in this application, Verisign, 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 .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.

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

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

Alliance-One Services, Inc.’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 .CSC 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.

1.1 Security Policy and Procedures for the Proposed Registry

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

Independent Assessment and Periodic Independent Assessment Reports. To help ensure effective security controls are in place, Alliance-One Services, Inc., 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 ‎30A 1 lists a subset of the audits that Verisign conducts. For each audit program or certification listed in Figure ‎30A 1, 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.

Augmented Security Levels or Capabilities. See Section 5 of this response.

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

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

Verisign is Alliance-One Services, Inc.’s selected backend registry services provider. For the .CSC gTLD, no unique security measures or commitments must be made by Verisign or Alliance-One Services, Inc. to any registrant.

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

No unique security measures are necessary to implement the .CSC gTLD. As defined in Section 1 of this response, Verisign, Alliance-One Services, Inc.’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)

As defined in Section 1 of this response, Verisign, Alliance-One Services, Inc.’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)




© Internet Corporation For Assigned Names and Numbers.