Application number: 1-1009-97005 for Web.com Group, Inc.

Web.com Group, Inc.

12808 Gran Bay Parkway, West
Jacksonville FL 32258
US

00 904 680 6600

00 904 880 0350

http:⁄⁄www.web.com

Mr. Robert Conant Wiegand

Senior Vice President

+00 904 680 6958

bwiegand@web.com

Mr. Matthew Patrick McClure

Chief Legal Officer

00 904 680 6997

mmclure@web.com

Corporation

General Corporation Law of the State of Delaware

Not Available

NASDAQ

Anton J. Levy
Director
David L. Brown
Chairman of the Board
Deborah H. Quazzo
Director
Hugh M. Durden
Director
Phillip J. Facchina
Director
Robert S. McCoy
Director
Timothy I. Maudlin
Director

David L. Brown
CEO & President
Jason M. Teichman
EVP and Chief Marketing Officer
Kevin M. Carney
EVP and Chief Financial Officer
Matthew P. McClure
Chief Legal Officer & Secretary
Roseann Duran
EVP and Chief People Officer

NWS Holdings
Not Applicable

web

Not Available

Web.com Group, Inc. (ʺWeb.comʺ) has taken a number of steps, including consulting with Verisign, our registry services provider to ensure that there are no known operational or rendering problems concerning the .web gTLD string.
Many software applications conduct software validity checks. Applications like web browsers and desktop software will validate the use of URLs either by a validation of the known gTLDs and⁄or the length of the string. The gTLDs delegated during the 2004 round experienced universal acceptance issues that for the most part are resolved today.
Upon delegation of .web, Web.com intends to conduct thorough integration testing with all major software applications. Further, Web.com intends to assist customers of the .web gTLD as issues arise. Web.com understands that these items cannot be remedied alone, but Web.com will collaborate with software vendors about issues as they are discovered to ensure seamless adoption.

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

Web.com Group, Inc (“Web.com”) has been in the business of helping our customers establish their online presence for over 15 years. Following our acquisition of Register.com in July 2010 and the subsequent acquisition of Network Solutions, LLC, the oldest ICANN accredited registrar, in October 2011, we have become one of the largest domain name registrars in the world with approximately 3 million customers. Web.com offers a variety of TLDs and a full suite of domain-name services, including registration, management, renewal, expiration protection and privacy services. 

The creation of a .web gTLD will help to fulfill ICANNʹs mission of providing more competition in the online marketplace and Web.com is the perfect candidate for operating .web given its experience, global reach, and brand recognition.

Why .web?

Web.com knows from years of experience that the .com gTLD has played a revolutionary role in the advancement of global commerce and culture. In addition, the .com gTLD has had a powerful and democratizing impact, providing avenues for anyone to participate in online discourse and a growing market. There are, however, a finite number of useful second-level domains that can be applied for in .com, as ICANN knows and understands. Often other gTLDs, such as .org, .info, .biz and others either are unavailable or are not a good fit for a potential second-level domain.

In looking to expand the gTLD landscape beyond the existing robustness of gTLD offerings, an easy-to-remember and intuitively logical gTLD such as .web is a relevant addition. Consumers will instantly understand that a .web domain is an Internet website thereby ensuring quick adoption by users. Due to its ubiquitous nature, .web will compete directly with all gTLDs, both existing ones and others to be approved by ICANN. It has universal appeal to anyone looking to operate on the World Wide Web. Not only will .web introduce a new and previously unavailable range of domain choices to businesses and individuals around the world but it could also serve as a platform for a number of innovative domain-based services.

The .web gTLD will help customers launch and leverage their presence on the Internet. As a leading global provider of online marketing services to small businesses, Web.com recognizes that finding a relevant and memorable domain name can be challenging. Since many keywords and descriptive phrases associated with existing TLDs have already been registered, it is often difficult to pinpoint a domain name which contains an acceptable number of characters. Consequently, prospective registrants are many times unable to secure a unique and adequate name. 

The availability of .web domains will spark competition across all industries engaging customers online by providing more opportunities for registrants to secure easily found domains. Consumer choice will increase, and in doing so, online operators will seek ways to differentiate themselves from their competition with proactive steps to build consumer trust and confidence.

Introducing .web as a gTLD choice also will inject additional inventory into the domain name marketplace. As such, it will increase competition within the Internet registry space, as well as provide avenues for increased registrar competition. 

Why Web.com?

As the sole owner of the Web.com® Trademark--issued by the U.S. Patent and Trademark Office-- Web.com seeks to be the sole registry operator for the .web gTLD. Historically, Web.com has offered and will continue to provide pre-registration service for the .web gTLD through www.register.web.com. We remain committed to promoting .web as a new gTLD and to expanding the competitive landscape that permeates the Internet.

Founded in 1997 as Atlantic Teleservices, Web.com has evolved to become a leading provider of Internet services for small- to medium-sized businesses (“SMBs”). Web.com is the parent company of two global domain name registrars, and further meets the Internet needs of consumers and businesses throughout their lifecycle with affordable value-added services. These services include domain-name registration; website design; search engine optimization; search engine marketing; social media and mobile products; local sales leads; ecommerce solutions; and call center services. 

Headquartered in Jacksonville, FL, USA, Web.com is a publicly traded company (Nasdaq: WWWW) serving nearly three million customers, with more than 1,700 global employees in fourteen locations in North America, South America and the United Kingdom. In recognition of its rapid progress, Web.com has appeared on Deloitte’s Technology Fast 500™ list in each of the past two years. 

One of our primary corporate goals is to provide a broad range of online services and products that enable SMBs to establish, maintain, promote, and optimize their web presence. By providing a comprehensive and best-in-class suite of services, we are able to deliver solutions that enable small and medium-sized businesses to compete and succeed online. Customers can choose to purchase ‘a la carte’ solutions for specific issues, or subscribe to bundled products that meet a variety of needs. 

Web.com brings a wealth of experience in providing a seamless process for customers from the first point of registration through the growth of their Internet properties. Following our acquisition of Register.com in July 2010 and the subsequent acquisition of Network Solutions in October 2011, we have become one of the largest domain name registrars in the world. Web.com offers a variety of TLDs and a full suite of domain-name services, including registration, management, renewal, expiration protection and privacy services. Web.com is also a prominent player in the Internet community through participation in numerous working groups and organizations including the Certificate Authentication Board, Internet Corporation for Assigned Names and Numbers (ICANN) and the Internet standards development community. 

Additionally, since the .web gTLD mirrors the Web.com brand, trademarks, and the character string associated with our corporate website address (www.web.com), we believe that Web.com should be the sole operator and administrator of the .web gTLD. The issuance of the .web gTLD to anyone other than Web.com would infringe on the trademark rights in Web.com and be confusingly similar to domains currently in use by Web.com such as www.register.web.com and www.dot.web.com. 

18(b). How proposed gTLD will benefit registrants, Internet users, and others.

The .web gTLD will benefit registrants, Internet users, and others in a number of ways:
• Increase the domain-name extension inventory: An expanding global population results in more Internet users, coupled with increasing demand for domain name choices. The .web gTLD provides alternatives in every possible imagining of a website, from ecommerce to promotion of free expression.

• Increased availability of generic word domain names. For the first time in decades, generic names that have been locked down by registrants in existing gTLDs will be available in a new and easy-to-remember gTLD, which increases competition and benefits Internet users.

• Increase online innovation: New online properties with the .web gTLD will spur competitors to innovate in ways that will empower consumers, enabling communication instantaneously with others in their own communities and worldwide, at a low cost relative to traditional forms of media. The Internetʹs unique attributes create new opportunities to collaborate, exchange ideas, and promote scientific, cultural, and economic progress. These opportunities will increase when .web is introduced by ICANN and implemented and operated by Web.com.

Web.com is committed to providing best-in-class service to customers by maintaining our position as an industry leader. Our goal is to enable online users to expand their web presence and we are committed to offering a greater choice in top level domain extensions.

18(b)(i) What is the goal of your proposed TLD in terms of areas of specialty, service levels, of reputation?

Many gTLDs introduced by ICANN will, by their nature, appeal only to certain segments of the online population, whether those communities are industries, ethnicities, or other collections of like-minded individuals and organizations. We are hopeful that the .web gTLD will have the same popularity as that of .com.

Web.com has the scalability and processes required to meet the challenges anticipated with the .web gTLD. Today we manage over 8 million domain names across hundreds of TLDs. We are committed to servicing and⁄or providing domain-name resolution services that adhere to industry standards. Following our existing standards of industry benchmark performance, we will continuously monitor and proactively defend the .web infrastructure and associated services in order to provide reliable services for each registrant in areas of specialty, service levels, and reputation:

• Specialty: As the first domain-name ICANN-accredited registrar, Web.com’s Network Solutions subsidiary brings an unprecedented 25 years of domain industry experience to the community as a whole. The .web gTLD will be the baseline by which customers can incorporate new generation web-based technologies, enabling their web presence to be a highly efficient and effective communication mechanism. The experience and trust associated with Web.com will help ensure that outcome.

• Service Levels: Web.com has a long history of succeeding in its mission of providing world-class domain registration services. Our longstanding commitment to the highest service levels will be replicated with .web. Furthermore, we will meet or exceed the service levels mandated within the Registry Agreement enforced by ICANN as it pertains, but not limited, to the registration and resolution of the .web gTLD zone. Web.com is pleased to be working with Verisign, one of the leading Internet infrastructure companies, to launch .web. Verisignʹs unmatched performance in the operation of existing TLDs will ensure a high degree of service, stability and reliability.

• Reputation: Given our success over the course of the last 15 years, we are confident that Web.com will continue to serve customers with the best in class service as it pertains to the .web gTLD. Given the proactive safeguards we incorporate, and will continue to incorporate within the .web gTLD, we believe potential customers will register a .web gTLD in order to be associated with a secure, reliable and scalable gTLD. At Web.com, we believe that a website is only as good as the services and support behind it. With the .web gTLD, we have the opportunity to bring this same level of commitment to a gTLD. 

18(b)(ii) What do you anticipate your proposed TLD will add to the current space, in terms of competition, differentiation, or innovation?

As stated in 18(a) above, the .web gTLD will have a dramatic impact by increasing competition, providing more differentiation for customers and consumers, while driving innovation.

• Competition: The addition of a .web gTLD will increase competition across all vertical online platforms. Registrars will compete to offer .web and meet the high demand for .web second-level TLDs. Vendors in the online marketplace will seek to expand their existing footprint or pioneer new products and services with a fresh .web website. The universal appeal of a .web URL will provide competition to every TLD, both broad-based existing ones--such as .com, .org, .biz and .info--as well as others that will be approved by ICANN, whether broad-based or narrowly targeted. Internet users will benefit from the dramatically accelerated competitive environment resulting from ICANNʹs adoption of .web operated by Web.com.

• Differentiation: The .web gTLD will quickly become as ubiquitous as .com. The .web gTLD will be the most versatile gTLD on the World Wide Web. A brand name company might choose .com; a non-profit .org; a start-up .biz; a resource site .info; and so on. But every one of those organizationsʹ sites would be perfectly compatible with a .web second-level domain. More narrow gTLDs will provide differentiation in certain niches and markets; .web will do so in every conceivable area on the Internet, from commerce to information to community-building. The introduction of generics under a new gTLD also will provide differentiated approaches to reaching Internet users.

• Innovation: There is little room for continued innovation by .com registrants seeking to compete with and differentiate themselves from other .com registrants. That is not a negative reflection on .com, but rather the fact that there are a finite number of short and memorable second-level domains. With many keywords and descriptive phrases already registered, incentives to innovate decrease with each year. A land rush of .web addresses will reverse that decline and drive new innovation in web delivery and customer service.

18(b)(iii) What goals does your proposed TLD have in terms of user experience?

Web.com will provide rewarding user experiences on two levels:

• Registrants: Web.com will incorporate the ability to allow various segments of the market to take advantage of registering the desired .web domain name. This includes providing the IP community with the ability to secure the .web domains affiliated or associated with their brands during a proposed Sunrise period, prior to making registrations publicly available to all. This registrant service is a natural extension of decades of experience on the part of Web.com and its holdings. Web.com may also enable registrants who have already purchased domains in other gTLDs the ability to register those domains in the .web gTLD. For registrants who are looking to improve their domain name or looking to purchase a new one, having .web will open up a new swath of choices in a gTLD that is new, fresh and directly tied to their goals of establishing their web presence. Upon enabling registrations to the general public, Web.com will incorporate a Go to Market Launch plan that will focus on ease of use, perspective registrant outreach program, and proactive communication associated with turn-key customer service. We intend to maintain our leading position that includes the lowest churn rates in the industry, which will be critical to the rollout of .web and its long-term success as a vibrant gTLD.

• Internet users: For users of .web gTLD websites, our enhanced efforts to prevent abusive behavior to protect the rights of others will result in a user experience that is more stable and secure than what they currently experience in other gTLDs. We fully recognize that eliminating abusive and fraudulent behavior is a difficult challenge but it is one that we will stress as we develop our plans to launch .web. Web.com plans to vigorously enforce all provisions we have outlined in the responses to Questions 28 and 29 to ensure a positive experience for all users of the .web gTLD.

18(b)(iv) Provide a complete description of the applicantʹs intended registration policies in support of the goals listed above.

Web.com takes its responsibilities in the operation of the .web gTLD very seriously. We have implemented a series of measures that, when taken together, will ensure that registrants have the ability to register names of their choice while ensuring that policies are in place to prevent and mitigate abusive behavior as well as protect the rights of others.

These registration policies include:

• An Acceptable Use Policy (AUP) that clearly defines what is considered abuse and what registrants may and may not do with their .web domain names

• A name selection policy that ensures compliance with ICANN mandated restrictions on second level domains

• Support for Uniform Rapid Suspension (URS) and Uniform Domain-Name Dispute-Resolution Policy (UDRP) to mitigate trademark infringement

The gTLD will be launched in multiple phases, ensuring a stable, secure, and controlled introduction:

• Sunrise A: This initial phase will allow the trademark community the ability to secure the .web domains associated with their brands for a 60-day period - double the ICANN minimum.

• Possible Sunrise B: We are also considering a second phase which might be available for previously registered names in other gTLDs. 

• Landrush: Following the Sunrise phases, this phase will allow domain registrants to register domains at a premium price point. Multiple submissions will be auctioned, with the auction provider to be named at a later date. 

• General Availability: This final phase will be open to the general public. Domains may be registered on a first-come⁄first-serve basis.


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

Web.com respects the privacy of its customers and the visitors and users of its websites. The .web gTLD will be governed by a strict Privacy Policy to ensure the privacy of information for registrants as well as users. Web.com is an industry leader in providing transparent and rigorous policies on how sensitive information will be used, as well as preventing unauthorized access to information through vigilant use of the latest technological innovations. We will continue our commitment to privacy for our customers and website users by publicly posting our privacy policies on the registry website. Web.com will ensure compliance with all laws and regulations that govern privacy issues. 

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

Web.com enables regular dialogue with its registrants by establishing and maintaining clear and secure channels of communication. Web.com has every incentive to ensure that potential and existing .web registrants understand privacy and security measures to protect their information and to assist in their adherence to the AUP in their efforts to protect Internet users. 

No other registry is better equipped to deal with the communication challenges inherent in the rollout and maintenance of a gTLD with the appeal and anticipated popularity of .web.

To ensure the success of the .web launch, the company will undertake a global marketing and advertising campaign to create customer awareness and interest in the features and benefits of the .web gTLD.

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

As stated earlier, we take our responsibilities in this area very seriously. To demonstrate our commitment to make the .web gTLD more resistant to abusive behavior than other gTLDs that currently exist, Web.com has explored various mechanisms to help prevent abusive registrations. We were particularly impressed with the set of 31 Proposed Security, Stability and Resiliency Requirements for Financial TLDs that were developed by the Security Standards Working Group (SSWG) under the guidance of the financial services industry. Following their recommendation that all potential applicants look at these standards for their own TLDs, Web.com has completed a thorough review to determine which ones might enhance the .web gTLD experience. While not all of the proposed standards are applicable to the .web gTLD, we will endeavor to implement several of them to aid in our efforts to prevent and mitigate abusive registrations. In addition to the mechanisms described in 18 (b)(iv), we will undertake the following efforts:

• An Acceptable Use policy that clearly defines what is considered abuse and what registrants may and may not do with their domain names
• A seasoned abuse mitigation team that has years of experience in dealing with these issues
• Technological measures for removal of orphan glue records
• Efforts and measures to promote accurate and complete ‘Whois’
• Requirements for .web accredited registrars to enact measures in support of these efforts
• Extended Sunrise services
• Extended trademark claims service
• Name Selection Policy
• Acceptable Use Policy
• Support for URS and UDRP
• PDDRP
• Rapid takedown or suspension where necessary
• Anti-Abuse Process 
• Enhanced Authentication
• Malware Code Identification
• DNSSEC signing service
• Biannual‘WHOIS’ Verification 
• Participation in anti-abuse community activities

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

Web.com will launch the .web gTLD in the following phases:

• Sunrise A: This initial phase will allow the trademark community the ability to secure the .web domains associated with their brands for a 60-day period. 

• Possible Sunrise B: This second phase could be available for previously registered names in other gTLDs.

• Landrush: Following the Sunrise phases, Landrush will allow registrants to register domains at a premium price point. Multiple submissions for the same domain name will be resolved through auction, with an auction provider to be named at a later date. 

• General Availability: This final phase will be open to the general public. Domains may be registered on a first-come⁄first-serve basis. 

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

Web.com, like ICANN, has every incentive to see the .web gTLD become a ubiquitous online presence, serving Internet users globally and spurring online innovation. As such, we will institute necessary incentives to encourage rapid rollout and growing adoption of the .web gTLD, with policies to be developed and adopted in the future as necessary.

18(c)(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.

Web.com intends to price its domains competitively to maximize sales, while at the same time ensuring profitable, secure, and sustainable operations. It is premature to elaborate on specific policies at this stage in the process, but we intend to be responsive to market demands and share ICANNʹs desire to ensure a rapid spread and adoption of .web. Web.com will fully comply with all necessary and recommended notification requirements in the event that price increases are necessary.

No

Not Available

No

In order to comply with ICANN requirements and GAC recommendations regarding the protection of geographic names, Web.com Group, Inc. (ʺWeb.comʺ) has developed and will implement the following measures to protect geographical names at the second and all other levels in the .web gTLD: 

1. Rules for Reserving Geographical Names

Web.com will comply with Specification 5 ʺSchedule of Reserved Names at the Second Level in gTLD Registriesʺ Section 5 titled ʺCountry and Territory Names.ʺ The country and territory names contained in the following internationally recognized lists shall be initially reserved at the second level and at all other levels within the .web gTLD at which the Web.com provides for registrations:

 a. 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; 
 b. 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
 c. 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.

2. Incorporation of GAC recommendation regarding second level geographic domains

Web.com will review and seriously consider suggestions from global government entities, public authorities and the IGOʹs regarding additional names with national or geographic significant at the second level. 

Web.com will consider any claims of abuse, including abuse of names with national or geographic significance as serious offenses. The Abuse Prevention and Mitigation Procedures for the .web gTLD will ensure that governments, public authorities or IGOʹs have the ability to raise cases of concern.

3. Rules for registration and employment of geographical names.

If a decision is made by Web.com to release names reserved in Section 1 above, Web.com will follow the policy and procedures outlined in Specification 5 of the Registry agreement and will work effectively to reach agreement with the applicable government(s), provided, further, that Web.com may also propose release of these reservations, subject to review by ICANN’s Governmental Advisory Committee and approval by ICANN.

1 CUSTOMARY REGISTRY SERVICES

Please note; all figures, tables and diagrams referenced in the following response can be found in attachment titled “Attachment dot web Q23.”

As Web.com Group, Inc.ʹs (ʺWeb.comʺ) 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 Web.com’s selected provider of backend registry services. Verisign registry services provisions to registrars status information relating to zone servers for the gTLD. 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 Web.com’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 plans to operate Web.com’s .web 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 expand 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, Web.com’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 .web 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, Web.com’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. Web.com’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 Web.com in a consulting capacity as needed. 

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

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 Web.com to assess registration fees upon registrars that have exceeded the AGP thresholds stipulated in the AGP Limits Policy. Further, Web.com accepts and evaluates all exemption requests received from registrars and determines whether the exemption request meets the exemption criteria. Web.com maintains all AGP Limits Policy exemption request activity so that this material may be included within Web.com’s Monthly Registry Operator Report to ICANN.

Registrars that exceed the limits established by the policy may submit exemption requests to Web.com for consideration. Web.com’s compliance office reviews these exemption requests in accordance with the AGP Limits Policy and renders a decision. Upon request, Web.com 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, Web.com 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 taken by the operator. 

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, Web.com’s backend registry services provider, has had experience with this policy since its implementation in April 2009 and is available to support Web.com in a consulting capacity as needed. 

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

2.3 Registry Services Evaluation Policy (RSEP)
Technical Component: Verisign, Web.com’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, Web.com’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 .web gTLD.

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

Web.com plans to implement a Premium Name Service as part of launch plans for the .web gTLD. Work is still proceeding on this effort but it will be modeled after similar offerings during recent TLD launches and the reserved Premium Domain Name list will comply with all necessary ICANN regulations related to such efforts. This list will be authoritative and these names will not be available during Sunrise A&B or Landrush.

Verisign, Web.com’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. 

Web.com 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 .web gTLD.

1 ROBUST PLAN FOR OPERATING A RELIABLE SRS

Please note; all figures, tables and diagrams referenced in the following response can be found in attachment titled “Attachment dot web Q24.”

1.1 High-Level Shared Registration System (SRS) System Description
Verisign, Web.com Group, Inc.ʹs (ʺWeb.comʺ) 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 .web 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 .web gTLD. The application servers store Web.com’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, Web.com’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 the .web gTLD. 

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 .web 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 Web.com’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 Web.com’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 .web 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 Web.com’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 Web.com’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 .web 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 Web.com 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, Web.com’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 Web.com 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 .web gTLD as described in this application, Verisign, Web.com’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 the .web 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, Web.com’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, Web.com 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 .web 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

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

Please note; all figures, tables and diagrams referenced in the following response can be found in the attachment titled “Attachment dot web Q25.” All EPP schemas can be found in the attachment titled “Attachment dot web Q25 EPP schemas.”

Verisign, Web.com Group, Inc.ʹs (ʺWeb.comʺ) 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, Web.com’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, Web.com’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 .web 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 the .web gTLD. Verisign’s pricing for the backend registry services it provides to Web.com 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, Web.com’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 Web.com 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 .web gTLD as described in this application, Verisign, Web.com’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 the .web 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 the .web 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 ABILITY TO COMPLY WITH RELEVANT RFCS 
Verisign, Web.com’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 .web gTLD. 

For the .web 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, Web.com’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, Web.com’s selected backend registry services provider, use these EPP templates and schemas, as will the .web gTLD. For each proprietary XML template⁄schema Verisign provides a reference to the applicable template and includes the schema. These schema can be found in the attachment titled “dot web Q25 EPP Schemas.”

6 PROPRIETARY EPP EXTENSION CONSISTENCY WITH REGISTRATION LIFECYCLE 
Web.com’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. 

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

Please note; all figures, tables and diagrams referenced in the following response can be found in the attachment titled “Attachment dot web Q26.”

Verisign, Web.com Group, Inc.ʹs (ʺWeb.comʺ) 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 .web 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 Web.com’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 .web gTLD will use 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 .web gTLD registry as it is Verisign’s experience that when DNS data is updated in near real time, so should Whois data be updated to reflect the registration specifics of those domain names.

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

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

Verisign currently operates both thin and thick Whois systems. 

Verisign commits to implementing a RESTful Whois service upon finalization of agreements with the IETF (Internet Engineering Task Force).

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

• For domain name: whois EXAMPLE.TLD
• For registrar: whois ʺregistrar Example Registrar, Inc.ʺ
• For name server: whois ʺNS1.EXAMPLE.TLDʺ or whois ʺname server (IP address)ʺ

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

• Go to http:⁄⁄whois.nic.〈TLD〉
• Click on the appropriate button (Domain, Registrar, or Name Server)
• Enter the applicable parameter:
 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, Web.com’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, Web.com’s selected backend registry services provider. The figure details the configuration with one resolution⁄Whois site. For the .web 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, Web.com’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, Web.com’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, Web.com’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, Web.com’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 .web 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 Web.com 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, Web.com’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 Web.com 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 .web gTLD as described in this application, Verisign, Web.com’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 the .web 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 the .web 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
Web.com’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, Web.com’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.web 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, Web.com’s selected backend registry services provider, provides a searchable Whois service for the .web 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 Web.com defined .web 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, Web.com’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. 

1 COMPLETE KNOWLEDGE AND UNDERSTANDING OF REGISTRATION LIFECYCLES AND STATES

Please note; all figures, tables and diagrams referenced in the following response can be found in the attachment titled “Attachment dot web Q27.”
Starting with domain name registration and continuing through domain name delete operations, Web.com Group, Inc.ʹs (ʺWeb.comʺ) 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, Web.com’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 .web.
• 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 .web.
• 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, Web.com’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, Web.com’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
Web.com’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 .web gTLD as well as other TLDs managed by Verisign, Web.com’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 .web 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
Web.com’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 .web database. Two identical second-level domain names cannot simultaneously exist in .web. Further, a second-level domain name cannot be created if it conflicts with a reserved domain name.
• Point of Contact Associations: The domain name is associated with the following points of contact. Contacts are created and managed independently according to RFC 5733. 
• Registrant
• Administrative contact
• Technical contact
• Billing contact
• Domain Name Associations: Each domain name is associated with:
• A maximum of 13 hosts, which are created and managed independently according to RFC 5732
• An Auth-Info, which is used to authorize certain operations on the object
• Status(es), which are used to describe the domain name’s status in the registry
• A created date, updated date, and expiry date

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

Verisign, Web.com’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 the .web gTLD’s initial implementation and ongoing maintenance. Verisign’s pricing for the backend registry services it provides to Web.com 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 .web gTLD as described in this application, Verisign, Web.com’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 the .web 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 the .web 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.

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

Please note; all figures, tables and diagrams referenced in the following response can be found in the attachment titled “Attachment dot web Q28.”

Web.com Group, Inc (ʺWeb.comʺ) has been in the business of helping our near 3 million customers establish their online presences for over 15 years. As such, we have a rich history of understanding the importance of abuse prevention and mitigation as a core objective. We are active participants in a variety of industry and government efforts to prevent domain name abuse and are constantly updating our operating procedures to ensure our customers are as protected from this type of activity as they can be.

The .web gTLD will help customers launch and leverage their presence on the World Wide Web. As a leading global provider of online marketing services to small businesses, Web.com recognizes that finding a relevant and memorable domain name can be challenging. Since many keywords and descriptive phrases associated with existing gTLDs have already been registered, it is difficult to pinpoint a domain name which contains a limited number of characters. Consequently, prospective registrants are often unable to secure a unique name. Regularly, in the .com space amongst others, this is because of exploitative or abusive registrations. In the forthcoming .web namespace, we will endeavor to the utmost of our ability to prevent this pattern from repeating. 

One of the most important reasons our customers choose Web.com is because of our reputation for great products and exceptional customer service. The .web gTLD is a natural extension of our business. It is a place where we can help customers be successful on the web. At Web.com, we believe that a website is only as good as the services and support behind it. With the .web gTLD, we have the chance to bring this same commitment to service and support to a gTLD. For companies and consumers who stake their reputation on a .web domain name, having a gTLD that is trusted and secure is critical.

Unfortunately, some of the current gTLDs are not operated in a manner that instills this level of confidence. Web.com hopes to make the .web gTLD different. In launching the .web gTLD we have put together a tapestry of efforts that seek to prevent and successfully mitigate domain name abuse, making the web a more accessible and friendly place for small and medium sized businesses as well as consumers. These efforts include:

• An acceptable use policy that clearly defines what is considered abuse and what registrants may and may not do with their domain names
• A seasoned abuse mitigation team that has years of experience in dealing with these issues
• Technological Measures for Removal of Orphan Glue Records
• Efforts and measures to promote accurate and complete Whois
• Requirements for .web accredited registrars to enact measures in support of these efforts

The fight against abusive behavior is not static and Web.com is committed to ensuring that our efforts are constantly evolving to meet the ever changing landscape of threats.

1.1 .web Abuse Prevention and Mitigation Implementation Plan 

Preventing domain name abuse in the .web gTLD is of critical importance to registrants, consumers and Web.com. To demonstrate our commitment to make the .web gTLD more resistant to abusive behavior than just about any other gTLD that currently exists, Web.com has explored various mechanisms to help prevent abusive registrations. We were particularly impressed with the set of 31 Proposed Security, Stability and Resiliency Requirements for Financial TLDs that were developed by the Security Standards Working Group (SSWG) under the guidance of the financial services industry. Following their recommendation that all potential applicants look at these standards for their own TLDs, Web.com has completed a thorough review to determine which might enhance the .web gTLD experience. While not all of the proposed standards are applicable to the .web gTLD, we will endeavor to implement several of them to aid in our efforts to prevent and mitigate abusive registrations.

Web.com has developed and will look to deploy a customized approach that seeks to minimize the potential for abusive registrations and mitigate them as soon as possible should they occur. Registrants, Registrars and the Registry will all play a role in this endeavor. Having all three levels of the .web gTLD ecosystem participate in these measures will help ensure a comprehensive approach to these critical objectives. Web.com has designed the following procedure to prevent and mitigate abusive registrations:

Acceptable Use Policy - Web.com has developed a draft Acceptable Use Policy (AUP) which can be found in ʺAttachment dot web Q28.ʺ This AUP clearly defines what is considered abuse and what type of behavior is expressly prohibited in conjunction with the use of a .web domain name. Web.com will require, through the Registry Registrar Agreement (RRA), that this AUP be included in the registration agreement used by all .web gTLD accredited registrars. This registration agreement must be accepted by a registrant prior to them being able to register a name in the .web gTLD. 

Annual Certification of Registrar compliance with Registry-Registrar Agreement. The self-certification program consists, in part, of evaluations applied equally to all operational .web gTLD accredited registrars and conducted from time to time throughout the year. Process steps are as follows:

• Web.com 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, Web.com sends the registrar an automated email confirming that the form was successfully submitted.
• Web.com reviews the submitted form to ensure the certifications are compliant.
• Web.com 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 Web.com 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, Web.com sends the registrar a Breach Notice and gives the registrar 30 days to cure the breach.
• If the registrar does not cure the breach, Web.com terminates the Registry-Registrar Agreement (RRA). 

The .web gTLD registry will provide and maintain a primary point of contact for abuse complaints. We will display the contact information for the Abuse Mitigation Team, which serves as the primary point of contact for reporting abuse within the .web gTLD, on the .web gTLD website.

Each .web gTLD accredited registrar will provide and maintain a primary point of contact for abuse complaints. The registrar must provide and maintain valid primary contact information for reporting abuse in the .web gTLD on their website. This will be required as part of the .web gTLD RRA.

Web.com will explicitly define for Registrars what constitutes abusive behavior including but not limited to, malicious, negligent, and reckless behavior. The definition of abusive behavior will be contained in the AUP that Registrars will be required to include as part of the Registration Agreement. This will be required as part of the .web gTLD RRA.

Registrar must notify Registry Operator immediately regarding any investigation or compliance action including the nature of the investigation or compliance action by ICANN or any outside party (e.g., law enforcement, etc.), along with the TLD impacted. This will be required as part of the .web gTLD RRA.

Development of an Abuse Prevention and Mitigation Working Group. To give the Web.com team alternate perspectives about handling incidents of abuse and ways to mitigate them, we will form an Abuse Prevention and Mitigation Working Group. This team will not only be comprised of a cross functional group of Web.com professionals but also look to involve representatives from law enforcement, our customer base and outside experts. The group would meet regularly to discuss the latest trends in domain name abuse and the most effective way to prevent and remedy them. 

1.2 Policies for Handling Complaints Regarding Abuse

Web.com will staff a Single Point of Contact (SPoC) Abuse team to address abuse and malicious use requests. The role of the abuse team is to monitor registry services and review complaints entered online by end users, customers, and⁄or Law Enforcement. The complaints will be managed in accordance with the applicable Acceptable Use Policy (AUP) and Terms of Service (TOS) which shall allow the Abuse team discretion to suspend a domain instantly or send the complaint through the appropriate escalation channel for complaint resolution. 

Complaints shall be received via email at abuse@registry.web as will be prominently provided on the .web website (http:⁄⁄registry.web). Registrar access to .web’s Abuse Team will be provided via a hotline number, email address and additional personnel for filing direct requests. Complaints may be submitted 24x7 and each request path requires the submitter to provide personal contact information. .web will acknowledge the complaint within one (1) business day and will provide the requestor acceptance and⁄or resolution within three (3) business days depending on severity and complexity of the complaint. 

Web.com views domain name abuse as a serious matter that produces direct harm to Internet users and .web customers. As such, .web will handle each abuse complaint as a direct threat and intends to resolve each validated complaint with a sense of urgency. Our Abuse Policies recognize many forms of abuse related to the registrations and use of domain names. Abuses and their respective mitigation strategy listed here is not an exhaustive list, but is meant to highlight general process and procedure by which .web will manage the most common forms of abuse. The .web Abuse Team collaborates and participates with industry experts and forums to understand the latest forms of abuse in an attempt to protect customers of our services and Internet users where possible.

DRAFT ABUSE REMEDY PROCESS

Listed here is the proposed process for dealing with the major forms of domain abuse:

1. Customer or end user submits abuse complaint to abuse@registry.web;
2. Abuse Coordinator receives request and acknowledges receipt of complaint;
3. Abuse Coordinator analyzes request to determine the abuse type to be addressed and references the .web knowledgebase for detailed procedures;
4. Abuse Coordinator assigns a severity rating based on complaint type;
5. Abuse Coordinator resolves the complaint based on the following decision tree:
 a. Is the request a court ordered seizure and transfer?
 i. Yes – See section 28.1.1
 ii. No - next step
 b. Does the request reflect a potential DDOS Attack?
 i. Yes – See section 28.1.2
 ii. No - next step
 c. Is the request a phishing complaint?
 i. Yes – See section 28.1.3
 ii. No - next step
 d. Is the complaint a notice of a trademark infringement?
 i. Yes – See section 28.1.4
 ii. No - next step
 e. Is the request a possible hijacking case or a transfer dispute?
 i. Yes – See section 28.1.5
 ii. No - next step
 f. Is the request an email service abuse?
 i. Yes – See section 28.1.6
 ii. No - next step
 g. Does the complaint refer to abusive or offensive content hosted on a .web domain?
 i. Yes – See section 28.1.7
 ii. No - next step
 h. For all other abuses not defined:
 i. Escalate request to Abuse Manager for guidance and resolution

28.1.1 Court Ordered Seizure and Transfer

Definition: Law enforcement via a court of legal jurisdiction orders that domain be seized due to illegal activity of applicable law.

Service Level: One (1) business day

Procedure:

• Abuse Coordinator contacts the legal jurisdiction to request signed copies of the court order;
• Upon receipt of court order, Abuse Coordinator confirms request with the Abuse Situation Manager;
• If the request is determined to be valid, Abuse Coordinator will submit a request to the Registry Support team to have the domain pushed to the requested registrar as directed by the applicable judicial entity;
• If the request is determined to be invalid or documents submitted are in question, the Abuse Coordinator will contact the legal jurisdiction requesting the appropriate documentation or to provide reasoning as to why the request cannot be fulfilled.

28.1.2 DOS or DDOS Attack

Definition: A denial-of-service attack (DoS attack) or distributed denial-of-service attack (DDoS attack) is an attempt to make a computer or network resource unavailable to its intended users.

Service Level: One (1) business day

Procedure: 
• Abuse Coordinator will confirm the DDOS attack with the Abuse Manager;
• If the complaint is confirmed as a DDOS attack:
 o Abuse Coordinator will escalate the request to the respective Registrar Support Team;
 o If not , Abuse Coordinator will respond to the complainant as unable to confirm and request additional information or close the complaint;
• Registrar Support team will suspend the domain registration until further notice.

28.1.3 Phishing

Definition: Phishing is a website fraudulently presenting itself as a trusted site (often a bank) in order to deceive Internet users into divulging sensitive information (e.g. online banking credentials, email passwords).

Service Level: One (1) business day

Procedure:
• Abuse Coordinator will confirm the phishing scam with the Abuse Manager;
• If the complaint is confirmed as a legitimate phishing event;
 o Abuse Coordinator will escalate the request to the Registry Support Team;
 o If not , Abuse Coordinator will respond to the complainant as unable to confirm and request additional information or close the complaint;
• Registry Support Team will immediately suspend the domain;
• Abuse Manager will investigate the Phish event and determine the intent of the domain registrant, the Registry Support team seize and⁄or delete the domain from the zone.

28.1.4 Cybersquatting ⁄ Trademark Infringement

Definition: Cybersquatting is the deliberate and bad-faith registration and use of a name that is a registered brand or mark of an unrelated entity, often for the purpose of profiting (typically, though not exclusively, through pay-per-click advertisements).

Service Level: Three (3) business days

Procedure: 
• If request appears to be an initial complaint on a possible infringement, Abuse Coordinator will direct complainant to the UDRP⁄WIPO process;
• If not , if the request of transfer is from a .web registrar, Abuse Coordinator will work with the Registrar to ensure the domain in question is transferred appropriately. 


28.1.5 Transfer Disputes ⁄ Hijacking

Definition: Domain hijacking or domain theft is the act of changing the registration of a domain name without the permission of its original registrant.

Service Level: Three (3) business days

Procedure: 
• Abuse Coordinator will confirm the OFAC request with the Abuse Manager;
• Abuse Coordinator will escalate request to and Registrar shall internal policies and procedures to investigate the transfer.

28.1.6 Email Service Abuse

Definition: An illegitimate use of email systems to distribute abusive content or in a manner that violates the Acceptable Use Policy. Examples of this abuse are Un-Solicited Commercial Email (UCE⁄SPAM).

Service Level: Three (3) business days

Procedure: 
• Abuse Coordinator will validate the complaint for UCE⁄SPAM elements and collaborate with the Complainant to acquire the examples of the offensive material;
• If Abuse Coordinator deems the offensive material to violate Acceptable Use Policy and is deemed to be offensive material, Abuse Coordinator will escalate the request to the Registry Support team for suspension;
• Registry Support team will immediately suspend the domain;
• If a .web customer is found to be unknowingly sending UCE, Customer shall be allotted the opportunity to correct the situation and assurances must be received by offender to ensure against future occurrences.

28.1.7 Web Hosting Abuse

Definition: Content or material hosted on a website that that is deemed to be offensive or against the .web Acceptable Use Policy. Material that is deemed offensive by registrar⁄host shall result in a Warning, then Suspension if material is not removed and possible seizure or termination of services.

Service Level: Three (3) business days

Procedure: 
• Abuse Coordinator will validate the information in the complaint to confirm that the hosting package is being used in a way that is not compliant with the .web Acceptable Use Policy. Some examples may include the following:
 o Documents, videos, pictures, music files, software etc. is not associated with the function or serving up of website;
 o Content being stored is not accessible from the Website;
 o An open FTP server;
 o Storage being used as a hard drive⁄backup; or
 o Space Manager usage exceeds 2GB of storage on the UNIX hosting platform only.
• If one or more of the above is confirmed and validated, the Abuse Coordinator or Technical Services will notify the Customer that they are in violation of the .web AUP and⁄or Terms of Service;
• An email will be sent immediately to the Registrant, Admin and Technical contact on file to advise of the violation. The email should instruct the Customer to take the appropriate action within 24 hours to remove the offending content or they may be subjected to a suspension of services;
• During Business Hours, the Abuse Coordinator will contact the Customer via phone in addition to sending the email to inform the Registrant, Admin or Technical contacts of the offending violation. The Technical Services agents will follow the same process for After Hours handling;
• If no response is received within 24 hours, a second phone and email attempt will be made to reach the Registrant, Admin and Technical contact;
• If the offending party does not respond by the end of the second business day, action will be taken to remove the offending content that is causing server degradation;
• Technical Support team will suspend the Hosting services;
• The Registry Support team will place the domain on Registrar hold to de-resolve the name;
• If the offending party responds and agrees to remove the offending content within the 24 hour time frame, the Abuse Coordinator or Technical Services agent must confirm the material has been removed, and note the appropriate remediation within the CRM system;
• If the offending party responds and agrees to remove the offending content after the service suspension, the Registry Support team may remove the suspension and allow customer to remove the content. Support will confirm the offending material has been removed, and note the appropriate CRM systems;
• If the offending party requests that .web remove the offending material, the Abuse Coordinator agent must call the Customer and obtain confirmation to remove the content on behalf of the Customer. The Abuse Coordinator will also obtain written confirmation from the Customer via the Registrant, Administrative or Technical Contacts that are listed. The confirmation should be noted in the appropriate CRM system;
• If there is no response from the offending party after 7 Days, the Abuse Coordinator will submit a request to delete the offending content from the servers to the Abuse Manager for approval to delete the content;
• Prior to deleting the content, an email will be sent to the appropriate internal Legal point of contact to advise of the issue and obtain approval to delete the content.

1.3 Proposed Measures for Removal of Orphan Glue Records

Although orphan glue records often support correct and ordinary operation of the Domain Name System (DNS), registry operators will be required to remove orphan glue records (as defined at http:⁄⁄www.icann.org⁄en⁄committees⁄security⁄sac048.pdf) when provided with evidence in written form that such records are present in connection with malicious conduct. Web.com’s selected backend registry services provider’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, Web.comʹs chosen backend registry services provider, performs the following checks before removing a domain or name server: 

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

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

Zone-file impact:
• If the parent domain references the child name server AND if other domains in the zone also reference it AND if the parent domain name is assigned a serverHold status, then the parent domain goes out of the zone but the name server glue record does not. 
• If no domains reference a name server, then the zone file removes the glue record.

1.4 Resourcing Plans

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

1.5 Measures to Promote Whois Accuracy

Web.com supports efforts to improve the accuracy and completeness of Whois records. To that end, we will seek to implement a series of measures that require registrars and registrants to help us in this pursuit. This includes a Whois reminder process at the registry level, regular scans of the Whois data to search for blank or incomplete data and economic incentives for registrars who achieve 100% complete and accurate Whois data for those names they have registered. 

Regular Monitoring of Registration Data for Accuracy and Completeness

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. 

Bi-Annual Whois Verification by Registrars. As will be required in the Registry-Registrar Agreement, all .web accredited registrars will be required to verify Whois data for each record they have registered in the TLD twice a year. Verification can take place via email, phone or any other methods as long as there is a proactive action by the registrant to confirm the accuracy of the Whois data associated with the domain name. Web.com will randomly audit Whois records to ensure compliance and accuracy. As part of the .web gTLD Abuse reporting system, users can report missing or incomplete Whois data via the registry website.

Quarterly Scan of the Zone file for incomplete Registrant Data. On a quarterly basis, Web.com will do a scan of all Whois records in the .web gTLD to find any blank fields or missing registration data. Upon completion of the scan, registrars will be sent a report detailing which domain names are missing data. As part of their responsibilities in the RAA to work towards 100% accuracy of Whois data, registrars must then alert registrants that there is data missing in their Whois record and remind them of their responsibility contained in the registration agreement that they must comply with ICANN requirements for complete and accurate Whois data.

Economic incentives for Registrars to achieve 100% Whois Accuracy

Web.com will offer Market Development Funds (MDF) to those registrars who can demonstrate via a third party audit that the .web gTLD names registered with them have 100% complete and accurate Whois data. 

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

Web.com defines Malicious and Abusive behavior based on the following but not limited definitions: 

Phishing is a criminal activity employing tactics to defraud and defame Internet users via sensitive information with the intent to steal or expose credentials, money or identities. A phishing attack begins with a spoofed email posing as a trustworthy electronic correspondence that contains hijacked brand names i.e. (financial institutions, credit card companies, e-commerce sites). The language of a phishing email is misleading and persuasive by generating either fear and⁄or excitement to ultimately lure the recipient to a fraudulent website. It is paramount for both the phishing email and website to appear credible in order for the attack to influence the recipient. As with the spoofed email, phishers aim to make the associated phishing website appear credible. The legitimate target website is mirrored to make the fraudulent site look professionally designed. Fake third-party security endorsements, spoofed address bars, and spoofed padlock icons falsely lend credibility to fraudulent sites as well. The persuasive inflammatory language of the email combined with a legitimate looking website is used to convince recipients to disclose sensitive information such as passwords, usernames, credit card numbers, social security numbers, account numbers, and mother’s maiden name. 

Malware is malicious software that was intentionally developed to infiltrate or damage a computer, mobile device, software and⁄or operating infrastructure or website without the consent of the owner or authorized party. This includes, amongst others, Viruses, Trojan horses, and worms.
 
Domain Name or Domain Theft is the act of changing the registration of a domain name without the permission of its original registrant.
Section 1.2 outlines the Web.com Policies and Procedures for Handling Complaints Regarding Abuse as defined above. 

As pertains to Web.com performance metrics and service level requirements for resolution, we adhere to a 12 hour timeframe to address and potentially rectify the issue as it pertains to all forms of abuse and fraud. Once a notification is received via email, call center or fax, the Web.com Customer Service centers immediately create a support ticket in order to monitor and track the issue through resolution. If notifications are received during normal business hours (8am – 11pm EST. (Monday – Friday) and 8am – 6pm EST (Saturday & Sunday) the majority of issues are resolved in less than a 4 hour period. 


1.7 Controls to Ensure Proper Access to Domain Functions

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

Web.com is a leading provider of Internet services for small to medium-sized businesses (SMBs). Web.com is the parent company of two global domain name registrars and further meets the Internet needs of SMBs throughout their lifecycle with affordable value added services that including domain name registration, website design, search engine optimization, search engine marketing, social media and mobile products, local sales leads, eCommerce solutions and call center services. Headquartered in Jacksonville, FL, USA, Web.com is NASDAQ traded company serving nearly three million customers with more than 1,700 global employees in fourteen locations in North America, South America and the United Kingdom.

Our business is helping people establish, maintain, promote, and optimize their web presence. Web.com intentionally chose Verisign as our registry services provider because of their unsurpassed track record in operating some of the worldʹs most complex and critical top level domains. Verisignʹs support for the .web gTLD will help ensure its success

The .web gTLD will be fully supported by a cross function team of Web.com professionals. Numbers and types of employees will vary for each function but Web.com projects it will use the following personnel to support the resource planning requirements:
 
• Quality Assurance Engineer: 0.5 FTE
• System Administrator: 1 FTE
• Database Administrator: 0.5 FTE
• Technical Project Manager: 0.5 FTE
• Marketing Director: 1 FTE
• Sales Manager: 1 FTE
• Legal Counsel: 1 FTE
• Finance⁄Accounting: 1 FTE
• Customer Service: 2 FTEs

Resource Planning Specific to Backend Registry Activities

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

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

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

3.1 Start-Up Anti-Abuse Policies and Procedures

Verisign, Web.com’s selected backend registry services provider, provides the following domain name abuse prevention services, which Web.com incorporates into its full-service registry operations. These services are available at the time of domain name registration.

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

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

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

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

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

Two components comprise the Registry Lock Service:

• Web.com and⁄or its registrars provides Verisign, the provider of backend registry services, with a list of the domain names to be placed on the server status codes. During the term of the service agreement, the registrar can add domain names to be placed on the server status codes and⁄or remove domain names currently placed on the server status codes. Verisign then manually authenticates that the registrar submitting the list of domain names is the registrar of record for such domain names.
• If Web.com and⁄or its registrars requires changes (including updates, deletes, and transfers) to a domain name placed on a server status code, Verisign follows a secure, authenticated process to perform the change. This process includes a request from a Web.com-authorized representative for Verisign to remove the specific registry status code, validation of the authorized individual by Verisign, removal of the specified server status code, registrar completion of the desired change, and a request from the Web.com-authorized individual to reinstate the server status code on the domain name. This process is designed to complement automated transaction processing through the Shared Registration System (SRS) by using independent authentication by trusted registry experts. 

Web.com intends to charge registrars based on the market value of the Registry Lock Service. A tiered pricing model is expected, with each tier having an annual fee based on per domain name⁄host and the number of domain names and hosts to be placed on Registry Lock server status code(s). 

3.2 Ongoing Anti-Abuse Policies and Procedures

3.2.1 Policies and Procedures That Identify Malicious or Abusive Behavior
Verisign, Web.com’s selected backend registry services provider, provides the following service to Web.com for incorporation into its full-service registry operations.

Malware scanning service. Registrants are often unknowing victims of malware exploits. Verisign has developed proprietary code to help identify malware in the zones it manages, which in turn helps registrars by identifying malicious code hidden in their domain names. 

Verisign’s malware scanning service helps prevent websites from infecting other websites by scanning web pages for embedded malicious content that will infect visitors’ websites. Verisign’s malware scanning technology uses a combination of in-depth malware behavioral analysis, anti-virus results, detailed malware patterns, and network analysis to discover known exploits for the particular scanned zone. If malware is detected, the service sends the registrar a report that contains the number of malicious domains found and details about malicious content within its TLD zones. Reports with remediation instructions are provided to help registrars and registrants eliminate the identified malware from the registrant’s website. 

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

Suspension processes. 

In the case of domain name abuse, Web.com will determine whether to take down the subject domain name. Verisign, Web.com’s selected backend registry services provider, will follow the following auditable processes to comply with the suspension request.

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

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

Registrar Notification. Once Verisign has performed the domain name suspension, and upon Web.com request, Verisign notifies the registrar of the suspension. Registrar notification includes the following information:

• Threat domain name
• Registry incident number 
• Verisign case number 
• Classification of type of domain name abuse
• Evidence of abuse
• Anti-abuse contact name and number
• Suspension status
• Date⁄time of domain name suspension

Registrant Notification. Once Verisign has performed the domain name suspension, and upon Web.com request, Verisign notifies the registrant of the suspension. Registrant notification includes the following information:

• Threat domain name
• Registry incident number 
• Verisign case number 
• Classification of type of domain name abuse
• Evidence of abuse
• Registrar anti-abuse contact name and number

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

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

Web.com is fully committed to improving the completeness and accuracy of Whois data and to preventing and mitigating domain name abuse in the .web gTLD. We strongly believe the efforts that we have outlined will go a long way in this critical area and most certainly meet the requirements as outlined by ICANN.

The fight against domain names abuse is not a static fight. The tactics used by malicious parties are constantly evolving and web.com is committed to evolving our systems to address these ongoing threats not because ICANN says we have to but simply because it is what our customers have come to expect from Web.com. 

The .web gTLD is an extension of our current business. At Web.com, we believe that a website is only as good as the services and support behind it. With the .web gTLD, we have the chance to bring this same commitment to service and support to a gTLD. For companies and consumers who stake their reputation on a .web domain name, having a gTLD that is trusted and secure is critical.

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

Scope⁄Scale Consistency

As one of the first domain registrars, Web.com and its subsidiaries have seen the Internet grow exponentially across three decades. Web.com has grown to a point where it now serves approximately 3 million customers, comprising over 8 million domain names under management. As our customer base grew and the number of domains we managed with it, we expanded our operations to meet customer needs. We anticipate doing exactly the same as .web proliferates. Our systems are highly developed and continually tested and audited, and will scale as we scale. The commitments we will seek to make to prevent domain name abuse will expand to meet the anticipated growth of the .web gTLD. We invest tens of millions each year in upgrading infrastructure and developing new business processes to meet the growth and needs of our customer base, and consider doing so of paramount importance. 

After 15 years of developing in this way, Web.com is a leading provider of Internet services for small- to medium-sized businesses (SMBs). Web.com is the parent company of two global domain name registrars, and further meets the Internet needs of consumers and businesses throughout their lifecycle with affordable value-added services. Those services include domain name registration; website design; search engine optimization; search engine marketing; social media and mobile products; local sales leads; eCommerce solutions; and call center services. 

Headquartered in Jacksonville, FL, USA, Web.com is a publicly traded company (Nasdaq: WWWW), with more than 1,700 global employees in fourteen locations in North America, South America and the United Kingdom. Web.com brings a wealth of experience in providing a seamless process for customers from the first point of registration through the growth of their Internet properties.

Indeed, following our acquisition of Register.com in July 2010 and the subsequent acquisition of Network Solutions, LLC, in October 2011, we have become one of the largest domain name registrars in the world. Web.com offers a variety of gTLDs and a full suite of domain name services, including registration, management, renewal, expiration protection and privacy services. 

It is clear, therefore, that managing the potentially enormous growth of the .web namespace will be a challenge, but a challenge to which we are more than equal.

Scope⁄Scale Consistency Specific to Backend Registry Activities

Verisign, Web.com’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 .web 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 Web.com 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.

1 MECHANISMS DESIGNED TO PREVENT ABUSIVE REGISTRATIONS

Web.com Group, Inc (“Web.com”) has been in the business of helping our nearly 3 million customers establish their online presence for over 15 years. Through our recent acquisition of Network Solutions, the oldest ICANN accredited registrar, with over 25 years of experience, we have a long history of understanding the importance of rights protection. This is a core objective not only from our own personal perspective as the holder of various trademarks including web.com®, but also on behalf of our customers who have their own trademarks. 

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

We understand the importance of Trademark holders to manage and protect their brands. In order to demonstrate our commitment to ensure the .web gTLD will accommodate the Intellectual Property community, Web.com has analyzed various additional mechanisms to help prevent abusive registrations. We were particularly impressed with the set of 31 Proposed Security, Stability and Resiliency Requirements for Financial gTLDs that were developed by the Security Standards Working Group (SSWG) under the guidance of the financial services industry. Following their recommendation that all potential applicants look at these standards for their own gTLDs, Web.com completed a thorough review to determine which standards may enhance the .web gTLD experience. While not all of the proposed standards are applicable to the .web gTLD, we will strive to implement several of these standards to ensure trademark owners will be able to take advantage of the additional protection beyond the minimums set forth by ICANN. 

Web.com has developed and will deploy a customized approach that seeks to minimize the potential for abusive registrations and incorporate a proactive mitigation process if a situation were to arise. Registrants, Registrars and the Registry will be contributing participants in this endeavor. Having all three participating entities of the .web gTLD ecosystem take part in these measures will ensure a comprehensive approach to these critical objectives. 
Web.com has designed the following procedures to help protect the rights of trademark owners:

• Extended Sunrise Services
• Extended Trademark Claims Service
• Name Selection Policy
• Acceptable Use Policy
• Name Allocation Policy
• URS and UDRP
• PDDRP and RRDRP
• Rapid Takedown or Suspension
• Anti-Abuse Process 
• Malware Code Identification
• DNSSEC Signing Service
• Biannual WHOIS Verification 
• Participation in Anti-abuse Community Activities

As described in this response, Web.com will implement a Sunrise period and Trademark Claims service with respect to the registration of domain names within the .web gTLD. Certain aspects of the Sunrise period and⁄or Trademark Claims service may be administered on behalf of Web.com by Web.com approved registrars or by authorized subcontractors of Web.com, such as its selected backend registry services provider, Verisign. 

Sunrise Periods. As it pertains to the launch of the .web gTLD, Web.com is currently planning on holding two different sunrise periods. Sunrise A will enable those participants that wish to register trademarks in the .web gTLD. A second sunrise period, Sunrise B, will be held for those who wish to reserve a domain name already registered in another gTLD. A more detailed explanation of each Sunrise Period follows.

Sunrise A

As set forth in the ICANN Applicant Guidebook, the Sunrise service pre-registration procedure for domain names must last for at least 30 days prior to the launch of the general registration of domain names in the gTLD. 

To ensure that trademark owners have ample time to participate in the midst of the possible launch of several other gTLDs, Web.com is planning on extending the sunrise to 60 days, 30 days longer than the ICANN mandated minimum. 

During the Sunrise period, holders of marks that have been previously validated by the Trademark Clearinghouse receive notice of domain names that are an identical match (as defined in the ICANN Applicant Guidebook) to their mark(s). Such notice is in accordance with ICANN’s requirements and is provided by Web.com either directly or through Web.com-approved registrars. 

Web.com requires all registrants, either directly or through Web.com-approved registrars, who are in good-standing with ICANN, to i) affirm that said registrants meet the Sunrise Eligibility Requirements (SER) and ii) submit to the Sunrise Dispute Resolution Policy (SDRP) consistent with Section 6 of the Trademark Clearinghouse model. At a minimum Web.com recognizes and honors all word marks for which a proof of use was submitted and validated by the Trademark Clearinghouse. 

During the Sunrise period, Web.com and⁄or Web.com-approved registrars, as applicable, are responsible for determining whether each domain name is eligible to be registered (including in accordance with the SERs).

Sunrise B

During a potential Sunrise B, registrants of domain names in other gTLDs may be able to file an application through a .web gTLD accredited registrar to register their existing domain name in the .web gTLD. Proof of registration of the domain name will be verified at the time of application. This sunrise period will last 30 days and at the end of the registration period, if there are no identical matches to any other applied for strings, the domain name will be registered to the appropriate applicant. If there are competing applications for the same domain name, qualified applicants will proceed to a closed auction to resolve the conflict.

Trademark Claims Service. As provided by the Trademark Clearinghouse model set forth in the January 11, 2012 version of the ICANN Applicant Guidebook, all new gTLDs will be required to provide a Trademark Claims service for a minimum of 60 days after the launch of the general registration of domain names in the gTLD (Trademark Claims period). 

Similar to our voluntarily extending the sunrise period to accommodate the needs of trademark owners, Web.com is planning on extending the trademark claims services to 120 days, double the ICANN mandated minimum. As the processes for how the trademark clearinghouse, including technical and financial specifics of how the program will work, are not finalized as of the filing of this application, Web.com reserves the right to revisit the length of the Trademark Claims Service. 

During the Trademark Claims period, in accordance with ICANN’s requirements, Web.com or the Web.com-approved registrar will send a Trademark Claims Notice to any prospective registrant of a domain name that is an identical match (as defined in the ICANN Applicant Guidebook) to any mark that is validated in the Trademark Clearinghouse. The Trademark Claims Notice will include links to the Trademark Claims as listed in the Trademark Clearinghouse and will be provided at no cost.

Prior to registration of said domain name, Web.com or the Web.com-approved registrar will require each prospective registrant to provide the warranties dictated in the Trademark Clearinghouse model set forth in the ICANN Applicant Guidebook. Those warranties will include receipt and understanding of the Trademark Claims Notice and confirmation that registration and use of said domain name will not infringe on the trademark rights of the mark holders listed. Without receipt of said warranties, Web.com or the Web.com-approved registrar will not have the ability to process the domain name registration.

Following the registration of a domain name, the Web.com-approved registrar will provide a notice of domain name registration to the holders of marks that have been previously validated by the Trademark Clearinghouse and are an identical match. This notice will be as dictated by ICANN. At a minimum Web.com will recognize, honor and adhere to all word marks validated by the Trademark Clearinghouse. 

Adoption of Certain SSWG Elevated Security Standards

As referenced earlier in this question, Web.com will work to implement the following elevated security standards in the .web gTLD:

Name Selection Policy

The .web gTLD will enforce a name selection policy that ensures that all names registered in the gTLD will be in compliance with ICANN mandated technical standards. These include restrictions on 2 character names, tagged names, and reserved names for Registry Operations. All names must also be in compliance with all applicable RFCs governing the composition of domain names. In addition, registrations of Country, Geographical and Territory Names will only be allowed in compliance with the restrictions as outlined in the answer to Question 22.

Name Allocation Policy

As described above, Web.com plans on implementing an extended Sunrise A period for Trademark Holders and a Sunrise B Period for domain name holders. In addition, our current plans call for incorporating a Landrush Period during which applicants can secure preferred .web domains, followed by a General Availability. With the exception of the Sunrise B Period, all registrations will occur on a first come first served basis. Web.com reserves the right to adjust this allocation Policy as it works through implementation details.

Acceptable Use Policy

Web.com has developed a draft the Registry Operator Acceptable Use Policy (AUP) which is further described in our response to Question 28. This AUP clearly defines what type of behavior is expressly prohibited in conjunction with the use of a .web domain name. Web.com will require, through the Registry Registrar Agreement (RRA), that this AUP be included in the registration agreement used by all .web gTLD accredited registrars. This registration agreement must be agreed upon by a registrant prior to them being able to register a name in the .web gTLD.
 
2 MECHANISMS DESIGNED TO IDENTIFY AND ADDRESS THE ABUSIVE USE OF REGISTERED NAMES ON AN ONGOING BASIS

In addition to the Sunrise and Trademark Claims services described in Section 1 of this response, Web.com will implement and adhere to RPMs post-launch as mandated by ICANN, and confirm that registrars accredited for the .web gTLD are in compliance with these mechanisms. Certain aspects of these post-launch RPMs may be administered on behalf of Web.com by Web.com-approved registrars or by approved subcontractors of Web.com, such as its selected backend registry services provider, Verisign. 

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

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

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

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

• URS: As provided in the Applicant Guidebook, all registries are required to implement the URS. Similar to the UDRP, a complainant files its objection with a URS provider. The URS provider conducts an administrative review for compliance with filing requirements. If the complaint passes review, the URS provider notifies the registry operator and locks the domain. A domain lock means that the registry restricts all changes to the registration data, but the name will continue to resolve. After the domain is locked, the complaint is served to the domain name registrant, who has an opportunity to respond accordingly. If the complainant is successful, the registry operator is informed and the domain name is suspended for the balance of the registration period; the domain name will not resolve to the original source, but to an informational approved web page provided by the URS provider. If the complainant is not successful, the URS is terminated and full control of the domain name registration is returned to the domain name registrant. Similar to the existing UDRP, Web.com and entities operating on its behalf adhere to decisions rendered by the URS providers.

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

Additional Measures Specific to Rights Protection. Web.com provides additional measures against abusive registrations. These measures will assist with mitigation of, but are not limited to, the following activities: 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: Web.com 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 gTLD registry. These orders may be issued when abusive content, such as but not limited to child pornography, counterfeit goods or illegal pharmaceuticals, is associated with the domain name.
• Anti-Abuse Process: Web.com 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, Web.com’s selected backend registry services provider, uses two-factor authentication to enhance security protocols for telephone, email, and chat communications.
• Registry Lock: Verisign’s Registry Lock service allows registrants to lock a domain name at the authoritative registry level to protect against both unintended and malicious changes, deletions, and transfers. Only Verisign, as Web.com’s backend registry services provider, can release the lock; thus all other entities that normally are permitted to update Shared Registration System (SRS) records are prevented from doing so. This lock is released only after the authorized registrar makes the request to unlock.
• Malware Code Identification: This safeguard reduces opportunities for abusive behaviors that use registered domain names in the gTLD. Registrants are often unknowing victims of malware exploits. As Web.com’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 and phishing 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 .web gTLD is DNSSEC-enabled as part of Verisign’s core backend registry services. 
• Biannual Whois Verification As detailed in our response to Question 28, all .web gTLD accredited registrars will be required as part of their RRA with Web.com to perform a Whois confirmation process twice a year. By asking registrants to confirm this information every 6 months, the .web gTLD should have a higher level of accurate Whois information for registered names in the event there is a case of trademark infringement by a non authorized registrant. Having accurate Whois information is critical to solving these issues in a timely manner.
• Participation in Anti-abuse Community Activities. Since our founding in 1997, Web.com has been an active participant and leader in multiple organizations, symposia, forums and other efforts that focus on the prevention of domain name abuse, including trademark infringement. Specifically, we are an active member of the Certificate Authentication Board, ICANN, the Internet standards development community, and we participate in SSAC. We find this participation extremely helpful in staying abreast of the latest changes and challenges in this field. Participation in these efforts also allows us to not only share our best practices with the rest of the anti-abuse community, but to learn from what others have been doing and incorporate it into how we operate our business. As mentioned earlier in this question, Web.com will be incorporating some of the SSWG enhanced security standards which is proof that community led efforts can produce significant results. 

3. RESOURCING PLANS

Resource Planning

Web.com is a leading provider of Internet services for small to medium-sized businesses (SMBs). Web.com is the parent company of two global domain name registrars and further meets the Internet needs of consumers and businesses throughout their lifecycle with affordable value added services that including domain name registration, website design, search engine optimization, search engine marketing, social media and mobile products, local sales leads, eCommerce solutions and call center services. Headquartered in Jacksonville, FL, USA, Web.com is NASDAQ traded company serving nearly three million customers with more than 1,700 global employees in fourteen locations in North America, South America and the United Kingdom.

Our business is helping people establish, maintain, promote, and optimize their web presence. Web.com intentionally chose Verisign as our registry services provider because of their unsurpassed track record in operating some of the worldʹs most complex and critical top level domains. Verisignʹs support for the .web gTLD will help ensure its success

The .web gTLD will be fully supported by a cross function team of Web.com professionals. Numbers and types of employees will vary for each function but Web.com projects it will use the following personnel to support the resource planning requirements;

• Quality Assurance Engineer: 0.5 FTE
• System Administrator: 1 FTE
• Database Administrator: 0.5 FTE
• Technical Project Manager: 0.5 FTE
• Marketing Director: 1 FTE
• Sales Manager: 1 FTE
• Legal Counsel: 1 FTE
• Finance⁄Accounting: 1 FTE
• Customer Service: 2 FTEs

Resource Planning Specific to Backend Registry Activities

Verisign, Web.com’s selected backend registry services provider, is the most 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 modifies these staffing models to account for new tools, standards and policy implementations and process innovations. These models enable Verisign to continually allocate the appropriate 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 will extend to Web.com 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 at 100 percent of the time for more than 13 years for .com, which exceeds the current several level agreements, proving Verisign’s ability to align personnel resource growth to the scale increases of Verisign’s gTLD 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 .web gTLD as described in this application, Verisign, Web.com’s selected backend registry services provider, scales, as needed, the size of each technical area now supporting its portfolio of gTLDs. Consistent with its resource modeling, Verisign frequently 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 and skilled candidates. These candidates are then interviewed by the lead of the relevant technical area. By scaling one common team across all its gTLDs instead of creating a new entity to manage only this proposed gTLD, Verisign realizes significant economies of scale and ensures its gTLD best practices are followed consistently. This consistent demonstration 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 gTLDs (i.e., .com). Moreover, by augmenting existing teams, Verisign ensures new employees are provided the opportunity to be trained and mentored by existing senior staff. This coaching and mentoring minimizes start-up learning curves and helps ensure that new staff members properly execute their duties.

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

Please note; all figures, tables and diagrams referenced in the following response can be found in attachment titled “Attachment dot web Q30A.”

Web.com Group, Inc. (ʺWeb.comʺ) 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 .web gTLD 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, Web.com, 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 CAPABILITIES ARE CONSISTENT WITH THE OVERALL BUSINESS APPROACH AND PLANNED SIZE OF THE REGISTRY

Verisign, Web.com’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 .web 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 Web.com 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 ADEQUATELY RESOURCED IN THE PLANNED COSTS DETAILED IN THE FINANCIAL SECTION

Resource Planning
Web.com is a leading provider of Internet services for small to medium-sized businesses (SMBs). Web.com is the parent company of two global domain name registrars and further meets the Internet needs of consumers and businesses throughout their lifecycle with affordable value added services that including domain name registration, website design, search engine optimization, search engine marketing, social media and mobile products, local sales leads, eCommerce solutions and call center services. Headquartered in Jacksonville, FL, USA, Web.com is NASDAQ traded company serving nearly three million customers with more than 1,700 global employees in fourteen locations in North America, South America and the United Kingdom.

Our business is helping people establish, maintain, promote, and optimize their web presence. Web.com intentionally chose Verisign as our registry services provider because of their unsurpassed track record in operating some of the worldʹs most complex and critical top level domains. Verisignʹs support for the .web gTLD will help ensure its success.

The .web gTLD will be fully supported by a cross function team of Web.com professionals. Numbers and types of employees will vary for each function but Web.com projects it will use the following personnel to support the resource planning requirements:

• Quality Assurance Engineer: 0.5 FTE
• System Administrator: 1 FTE
• Database Administrator: 0.5 FTE
• Technical Project Manager: 0.5 FTE
• Marketing Director: 1 FTE
• Sales Manager: 1 FTE
• Legal Counsel: 1 FTE
• Finance⁄Accounting: 1 FTE
• Customer Service: 2 FTEs

Resource Planning Specific to Backend Registry Activities
Verisign, Web.com’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 Web.com fully accounts for cost related to this infrastructure, which is provided as “Total Critical Registry Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46 financial projections response. 

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

Verisign projects it will use the following personnel role, which is described in Section 5 of the response to Question 31, Technical Overview of Proposed Registry, to support its security policy:

• Information Security Engineers: 11

To implement and manage the .web gTLD as described in this application, Verisign, Web.com’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 the .web 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 the .web 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 SECURITY MEASURES ARE CONSISTENT WITH ANY COMMITMENTS MADE TO REGISTRANTS REGARDING SECURITY LEVELS

Verisign is Web.com’s selected backend registry services provider. For the .web gTLD, no unique security measures or commitments must be made by Verisign or Web.com to any registrant.

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

No unique security measures are necessary to implement the .web gTLD. As defined in Section 1 of this response, Verisign, Web.com’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)