Application number: 1-1109-26787 for Go Daddy East, LLC

Go Daddy East, LLC

14455 N. Hayden Road
Suite #219
Scottsdale Arizona 85260
US

+1 480 505 8800

+1 480 505 8865

http:⁄⁄www.godaddy.com

Mr. James Michael Bladel

Director of Policy Development

+1 480 505 8800

+1 480 505 8865

tas@godaddy.com

Mr. Timothy Ruiz

Vice President of Policy Planning

+1 480 505 8800

+1 480 505 8865

tim@godaddy.com

Limited Liability Company

Delaware, USA

Not Available

Go Daddy Operating Company, LLC, a limited liability company formed under the laws of the State of Delaware, USA.

The applying entity is not a joint venture.

Adam Herbert Clammer
Director
Antony Y. Ling
Director
Charles J Robel
Director
Gregory Mondre
Director
Herald Yun Chen
Director
Richard Herrick Kimball
Director
Robert R. Parsons
Director
Warren Adelman
Director & CEO

Christine Jones
Secretary
Michael Zimmerman
Chief Financial Officer
Warren Adelman
Chief Executive Officer

Go Daddy Operating Company, LLC
Not Applicable

casa

Not Available

This application is not for an IDN string.

CASA will be used specifically for Spanish-speaking customers and users that want to target the Spanish-speaking market. CASA will be a generic TLD that will be open to any user, but focused on three main positioning messages. These areas of focus are: the ʺReal Estate Marketʺ, ʺEverything for the Homeʺ and a general ʺPersonal Spaceʺ focus. The word ʺcasaʺ translates to English as ʺhomeʺ so the gTLD will focus on various ʺhomeʺ related targets. Weʹll want the use of the gTLD to be wide open and available to anyone, yet keep the logical ʺhomeʺ message for users. 
 
From a ʺReal Estate Marketʺ perspective CASA will support Spanish-speaking realtors, lessors or owner-sellers and their online needs in their efforts of selling or renting homes. The CASA gTLD can also provide a reliable and trusted space for those Spanish-speaking home buyers or renters to look for information on homes for sale or rent, realtors, lessors and owner-sellers. CASA Registrars will make it easy for Spanish-speaking home sellers or lessors to use their listings to create a website instantly through development tools, such as Go Daddyʹs InstantPage® product. In addition, we will support CASA Registrars so they may offer month-to-month registrations as an optional service to registrars. Why pay for a year if the domain name will not be needed for a year?
 
As an “Everything for the Homeʺ target, CASA will target fashion, decor, recipes, coupons, remodeling, and do-it-yourself (DIY) content for Spanish-speaking buyers and visitors. Buyers of the CASA gTLD will have a place to sell the ʺEverything for the Homeʺ as well as share content, tips, tricks, newsletters, etc. as it relates to content and business specific to ʺEverything for the Home.ʺ 
 
And as a general interest gTLD, CASA will leverage the meaning of ʺhomeʺ as a ʺPersonal Space.ʺ For Spanish-speaking customers, we would position CASA as their ʺPersonal Spaceʺ on the Internet. CASA will be the place for individuals to share information, businesses to provide ʺAbout Usʺ details and the perfect location for individuals that are Home Based businesses to share who they are as an individual as well as a business owner. No matter how technology changes, or what you do online, you will always have your CASA on the Internet. 

The CASA gTLD will benefit the Spanish-speaking home marketing registrants by fulfilling the following goals: 

Real Estate Focus: 

1. Providing a unique marketing tool to Spanish-speaking sellers or lessors of homes;

2. Spanish-speaking realtors, home sellers or lessors, and property managers may use the gTLD to market themselves as trusted providers to Spanish-speaking customers;

3. Registrars can offer aligned products that are a simple and straight-forward implementation of a website that ties to a property listing;
3.a. For example, realtors could list a home in the Multiple Listing Service® (MLS®) database, as they do today, buy a domain name for a select period of time (monthly, recurring⁄auto-renewable) and then populate their website with data about the home to gain added exposure for the property;
3.b. Pictures can be uploaded, and seller or rental information, maps, and detailed information of the property will be instantly available;

4. The registrar may offer monthly billing options, which will be available, to establish short-term, reduced-cost domain name(s) and⁄or website(s);

5. External marketing campaigns would utilize multiple direct marketing venues to target all realtors, sellers, home owners, lessors and property managers interested in marketing homes to the Spanish-speaking public.

Everything for the Home, Personal Space and Real Estate Focus:

1. Like Go Daddy, registrars will be required ⁄ encouraged to provide specialized and trusted customer and sales team support in the Spanish language, specifically to assist the Spanish-speaking registrant;

2. Registrars will also be encouraged to offer other online services that will assist the registrants with getting online with their CASA domain name, such as the 50+ other products that will be provided via GoDaddy.com to help build specialized sites to address and benefit the specific needs of interested users;

3. As a registry, Go Daddy would allow registrars the ability to offer private registrations to the registrants, which will protect the registrantʹs contact information.

CASA users will be Spanish-speaking customers, who will benefit by having:

1. A trusted place to find a reliable Spanish-speaking realtor, home seller or home lessor, or sites that are focused on ʺEverything for the Homeʺ or a virtual ʺhomeʺ space online for personal or business use; 

2. Real Estate focus: 
2.a. Detailed information on home sales or rentals made available via full and complete websites based on targeted home listings;
2.b. Easy access to detailed information about homes, provided to users in their native language;

3. Registrars will also be encouraged to offer other online services that will assist the registrants with getting online with their CASA domain name, such as the 50+ other products that will be provided via GoDaddy.com to help build specialized sites to address and benefit the specific needs of interested users;

4. A reliable and trusted place to go for Spanish-speaking content as it relates to ʺEverything for the Homeʺ or your virtual ʺPersonal Spaceʺ on the web. 

Go Daddy does not anticipate any significant social costs beyond the potential desire by some entities or individuals to engage in defensive registration of their trademark strings. The operating rules covering this are detailed in Go Daddyʹs response to Question 28, and consist generally of the following practices. As a registry, Go Daddy would not directly provide abuse services to registrants of non-GoDaddy registrars, but will reserve the right to intervene in abuse situations where the registrar was slow or failed to act. As a registrar all abuse involving domain names registered with or through Go Daddy or Go Daddyʹs affiliates may be reported to abuse@godaddy.com, or via Go Daddyʹs existing 24x7 abuse hotline at 1-480-624-2505. Go Daddy has a long-standing policy of investigating every complaint received, responding appropriately, and taking necessary action to mitigate the reported abuse.

1. Multiple applications for the same domain name will be resolved on a first come⁄first serve basis.

2. Cost benefits will result from the fact that initial costs will be kept to a minimum for a CASA domain name (less than $3.00 per month). 

3. Cost benefits will result from an efficient, inexpensive, targeted marketing tool that will provide increased exposure to home buyers or renters.

4. Go Daddy would commit to no price increases during the first 2 years of a 10 year agreement. During years 3-10 Go Daddy would commit to no more than three (3) price increases of not more than 7% per increase. In all cases Go Daddy would provide 90 days notice prior to the new price becoming effective. At this time, Go Daddyʹs financial projections do not incorporate any such increases, but Go Daddy would agree to limit Go Daddyʹs price increase plan to no more than stated above, if any at all.

No

Not Available

No

Go Daddy anticipates that geographic names will be a significant component of the gTLD use case, in particular for establishing an online presence for location-specific real estate properties. Therefore, there will be no restrictions on geographic names at the second (or higher) level. 

Go Daddy will consider objections from governments that believe a second-level (or higher level, if offered by Go Daddy) registration infringes on a protected geographic name. Protected geographic names include strings in the “ISO 3166-1 alpha 3” country list, and the “Country Name Conventional Short Form List,” both listed in English ASCII. 

An appropriate representative (for example, the agency or ministry responsible for managing telecommunication or Internet affairs) or the Government Advisory Committee (GAC) member associated with the country or territory shall send notification of objection. Go Daddy may then, in its sole discretion, take action against the registration, up to and including suspension, deletion, and blocking future registration.

Go Daddy will provide a Shared Registration System (SRS). This system will provide the interfaces for the registrations of domain names and name servers. (Please see: (1) response to question 24 for more details on the SRS; and (2) the architecture diagrams in response to question 32.)

Go Daddy will maintain an extremely robust Domain Name System (DNS). Modeled on GoDaddy.comʹs current DNS, which is the largest DNS on the Internet. GoDaddy.com’s DNS handles more than 37 million zones and on average more than 9 billion queries per day. The SRS will feed data real-time into the DNS and will also facilitate and provide the infrastructure for the authorization and dissemination of related zone files. Go Daddy’s DNS will comply with relevant RFCs published by the Internet Engineering Task Force (IETF) and will be updated as needed to support 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, 4343, and 5966. (For more details on Go Daddy’s DNS, please see: (1) the response to question 35; and (2) the architecture diagrams in response to question 32.)

The technical and business components of Go Daddy’s Registry Services will consist of multiple redundant data centers and backup systems, which follow standard industry practices, and are described as follows: 

A. An Extensible Provisioning Protocol (EPP) protocol compliant gateway, supported by a Web-based registrar portal, enabling receipt of data from registrars concerning registration of domain names and name servers. Go Daddy’s EPP will be compliant with relevant Requests for Comments (RFCs) published by the Internet Engineering Task Force (IETF), which will be updated as needed to support all successor standards, modifications or additions relating to the provisioning and management of domain names using the EPP in conformance with RFCs 5910, 5730, 5731, 5732, 5733 and 5734. (Detailed specifically in the response to Question 25.)

B. Go Daddy will use a standard secure File Transfer Protocol (FTP) solution for dissemination of both TLD zone files and reports. Authentication and authorization (granted⁄suspended⁄ expired⁄deleted) will be controlled by the Go Daddy SRS. 

C. The SRS will also support and feed into the Registration Data Directory Service (RDDS) (WHOIS Database Services). Go Daddy’s RDDS will be composed of three services: (1) a WHOIS service available through port 43; (2) a Web-based service providing free public query-based access; and (3) a Web-based service providing registrars query-based access. All three services access the same data store that will be updated in near real time. The complete RDDS will be deployed in multiple datacenters to provide higher levels of redundancy and stability. (Detailed specifically in the response to Question 26.)

D. Initially, no Internationalized Domain Name support will be offered.

E. Domain Name System Security Extensions (DNSSEC) will be offered. TLD zone files will be signed, implementing DNSSEC. The DNSSEC offering will comply with RFCs 4033, 4034, 4035, 4509 and will be updated as needed to support all their successor standards, modifications or additions relating to DNSSEC, and will follow the best practices described in RFC 4641 and its successor standards. (Detailed specifically in the response to Question 43.)

Supporting services provided will be: an operational test and evaluation environment (OT&E); domain release systems and associated billing and reporting systems; and data escrow services.

The Shared Registration System (SRS) will consist of an Extensible Provisioning Protocol (EPP) compliant gateway, a Web-based registrar portal, an operational test and evaluation environment (OT&E), domain release systems and associated billing and reporting systems. The SRS will manage the master data that supports a Domain Name System (DNS) and DNS Security Extensions (DNSSEC), Registration Data Directory Service (RDDS) (WHOIS Database Services), and Data Escrow services. (See Attachment 1 to the answer to Question 32 for a representative network diagram.)

DNS 

Although the Registryʹs DNS will be on separate hardware from GoDaddy.com’s existing DNS, its architecture will be based on GoDaddy.com’s existing DNS infrastructure. The current system is the largest on the Internet, authoritative for over 37 million zones, and handles, on average, 9 billion DNS queries per day. Due to high levels of redundancy and monitoring, the existing system maintains 100% uptime, and the same is expected of the Registry DNS. One server cluster will be the active “master,” and the other will be in “hot-spare” mode; constantly replicated and in-sync, ready to take over master duties if the active master fails. (See Go Daddy’s answers to Question 35 for detail.)

Go Daddy’s DNS will comply with relevant existing RFCs and those published in the future by the Internet Engineering Task Force (IETF) including all successor standards, modifications or additions thereto relating to the DNS and name server operations including, without limitation, RFCs 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 4343, and 5966.

Go Daddy’s DNSSEC will comply with RFCs 4033, 4034, 4035, 4509 and their successors, and follow the best practices described in RFC 4641 and its successors. If Go Daddy implements Hashed Authenticated Denial of Existence for DNS Security Extensions, it will comply with RFC 5155 and its successors. Go Daddy will accept public-key material from child domain names in a secure manner according to industry best practices. Go Daddy will also publish on its website the DNSSEC Practice Statements (DPS) describing critical security controls and procedures for key material storage, access and usage for its own keys and secure acceptance of registrants’ public-key material. Go Daddy will publish its DPS following the format described in “DPS-framework” (currently in draft format, see http:⁄⁄tools.ietf.org⁄html⁄draft-ietf-dnsop-dnssec-dps-framework) within 180 days after the “DPS-framework” becomes an RFC.

EPP GATEWAY

Go Daddy’s EPP gateway will provide a connection-oriented EPP service. The EPP gateway will support synchronous mode connection: the client must receive a response to a command before sending another. Registry-defined connection limits will be configurable but limited equally for all registrars. Each connection will have a configurable inactivity timeout and lifetime timeout. Metrics will be captured for all transactions to allow for equal access and SRS stability. The EPP servers will be protected by firewalls. The actual IP of the servers will be hidden through a virtual IP from the load balancer. Registrars will be required to register their IP subnets with Go Daddy to be allowed access through the firewall. The server will perform mutual authentication on connections which will require a valid Secure Sockets Layer (SSL) certificate. The certificate must be signed from a trusted certificate authority. (See Go Daddy’s answers to Question 25 for detail.)

WEB-BASED REGISTRAR PORTAL

The registrar portal will provide the same functionality as the EPP gateway through a convenient Web interface. The registrar will be able to create and manage user sub accounts. These accounts will be configurable with independent access roles.

OPERATIONAL TEST & EVALUATION ENVIRONMENT

An isolated OT&E environment will be available for registrar testing prior to production operations. This environment will allow registrars to develop and test their client software systems with no risk to production systems. 

SRS ARCHITECTURE

For the SRS to achieve and exceed the performance and reliability requirements as set forth in the Service Level Agreement Matrix (Registry Agreement, Specification 10), Go Daddy systems will be compartmentalized into functional areas. These individual areas will be comprised of hardware load balanced clusters of N+1 servers. Individual servers will be added or removed from the component cluster without negatively impacting normal activities or performance of the system component. The complete SRS will be deployed in each data center to provide active⁄passive redundancy. For any component server cluster, there will never be less than 2 servers, but there will be as many servers as necessary to meet Specification 10. 

SRS DEVELOPMENT

The SRS will be a high volume On-line Transaction Processing (OLTP) system with a SQL server back end. The SRS will communicate with the database using stored procedures. Data-intensive business logic will be performed in the data tier while non data-intensive logic will be performed in the application tier. The SQL server will have a read-only mirror used for reporting.

SRS releases (“builds”) will be constructed from source control, and then deployed to the development environment for initial developer testing. Once developer testing is complete, the applications will be promoted to the test environment for formal Quality Assurance testing.

SRS SERVER BUILDS

All server builds will follow a standard build checklist. The checklist will manage the flow from server request to deployment. The checklist will include the following steps: inbound⁄outbound firewall access setup, inbound⁄outbound network access, security software setup, vulnerability scans, internal⁄external monitor setup, SRS software setup, disaster recovery plan, data backup plan, security scans, and QA testing.

SRS TESTING

Before each deployment, verification and validation tests will be executed against every build of the SRS. Testing will be performed throughout the development cycle in the form of unit testing, component testing, integration testing, and system testing. These tests will cover the following basic areas, which include EPP correctness, performance, reliability and security. In addition to the tests performed by automation, the QA staff also will perform exploratory testing.

1. EPP correctness: Data-driven known inputs will be used to generate and verify expected outputs.

2. Performance: Performance testing of the SRS will include resource usage, throughput, stimulus-response time, and queue lengths detailing the average or maximum number of tasks waiting to be serviced by selected resources. Some typical resources that will be monitored include network bandwidth, CPU cycles, disk space, disk access operations, and memory usage. The goal of this testing will be to identify potential performance bottlenecks and enable performance comparisons with historical build data.

3. Reliability: Stress or load testing will be used to test the whole system rather than the software alone. In these tests, the SRS will be exercised at and beyond the specified limits. Typical stress will include resource exhaustion, bursts of activities, and sustained high loads.

4. Security: The security testing of the SRS will include identifying and removing any software flaws that may potentially lead to security violations, and validating the effectiveness of security measures. The SRS will be scanned by tools such as Nessus by Tenable Network Security®. In addition, simulated security attacks will be performed by our QA staff to attempt to find vulnerabilities.

SRS MAINTENANCE

Any future protocol changes made to enhance functionality will be documented in Internet-Draft format as described in RFC 3735 and provided to ICANN prior to development. For all other changes including system enhancements, Go Daddyʹs Change Approval Board will internally assess hardware maintenance and routine software patching. Approved changes will be entered as a project in Go Daddy’s Change Management system. Once the project has been approved for deployment, the deployment will be scheduled. The change will first be scheduled and deployed to the OT&E environment. Only successful OT&E environment deployments will be promoted to the production SRS environment. All efforts will be taken to minimize the impact of deployments by scheduling for low traffic times as defined by historical data. Registrars will be notified in advance of any scheduled maintenance periods. The notice will contain detailed information on the change being deployed, maintenance window and systems that will be affected.

SRS OPERATIONS

Go Daddy’s operations staff will continuously monitor the SRS network, SRS servers and SRS health. These teams will be supported by 24⁄7 personnel. The system will provide metrics to aid in future upgrade decisions and detection of any potential failures. 

RESOURCING PLAN

Resourcing will come from current staff throughout the parent organization: Software Development, Network Operations, IT, Security Operations, and Business Continuity Departments. Go Daddy will incorporate all new gTLDs added to the Go Daddy registry into existing workflows to obtain immediate workability. Go Daddy has anticipated additional headcount in the coming year for all affected departments. See the headcount estimate in the ʺCASH OUTFLOWSʺ section in Go Daddyʹs answer to Question 46.

Go Daddy will implement the Extensible Provisioning Protocol (EPP) in conformance with the Proposed Standard and Informational RFCs 5730, 5731, 5732, 5733, 5734, 5910, 3915 and 3735 (where applicable) published by the Internet Engineering Task Force (IETF). 

Note: XML tags begin with ʺ〈 ʺ so that they show up when printed via the TAS Application Preview.

TRANSPORT & SECURITY

Registry-defined connection limits will be configurable but limited equally for all registrars. Each connection will have a configurable inactivity timeout and lifetime timeout. Metrics will be captured for all transactions to allow for equal access and SRS stability.

Go Daddy’s EPP gateway will use system port 700 for mapping EPP onto Transmission Control Protocol (TCP). The EPP servers will be protected by firewalls. The actual IP of the servers will be hidden through a virtual IP from the load balancer. Registrars will be required to register their IP subnets with Go Daddy to allow access through the firewalls. The client (registrar) and server (SRS) will perform a mutual authentication during the connection handshake where both sides pass valid SSL certificates to each other to establish the link. The certificate will be required to be signed from a trusted certificate authority.

The system will support EPP on SSL3.0 and Transport Layer Security (TLS) protocols over standard TCP⁄Internet Protocol (IP) sockets. Go Daddy will use TLS 1.0, which is compliant with RFC 2246.

Go Daddy’s EPP gateway will provide a connection-oriented EPP service. Upon the establishment of a connection (client and server SSL⁄TLS handshake) the EPP Gateway server will send a greeting message to the client. Sending a “hello” command will also generate a greeting message back to the client.

Go Daddy’s EPP gateway will support synchronous mode (no pipelining): a response to a command must be received by the client before sending another. Go Daddy has elected this mode to allow greater flexibility in the number of objects sent in an individual request.

TEST ENVIRONMENT

An isolated Operational Test & Evaluation (OT&E) environment will be available for registrar testing prior to production operations, allowing registrars to develop and test their client software systems with no risk to production systems. 

REGISTRAR CREDENTIALS

OT&E credentials will be provided to participating registrars. Once OT&E certification has been successfully completed, registrars will be provided Production credentials. ICANN Testing Registrar accounts will be set up by default per gTLD pursuant to the Registry Agreement.

SESSION MANAGEMENT

To start an EPP Gateway session, the client will send a “login” command using valid credentials. An EPP Gateway session will be closed by sending a “logout” command or simply by closing the TCP connection. After an initial greeting, clients will always be able to query the Gateway by sending a “hello” command.

TIME ZONE

Go Daddy’s EPP gateway will return the date and time in Coordinated Universal Time (UTC), as specified by the EPP standard, RFC 5731, Section 2.4. Registry operations will be performed based on this time.

SUPPORTED LANGUAGES

Four languages will be supported by Go Daddy’s EPP gateway: English, French, German and Spanish. Registrars will be able to make the selection at login, which is compliant with RFC 5730, Section 2.9.1.1.

SUPPORTED EPP COMMANDS

In order to communicate using EPP, Go Daddy will support the following core set of actions: 

1. Greeting: hello

2. Session Management: login and logout

3. Query: check, info, poll, and domain transfer

4. Transformation: create, update, renew, transfer and delete

EPP VALIDATION

Extensible Markup Language (XML) schemas are a means of exactly describing the possible content of an XML document. As such, Go Daddy will refer to the schema definitions that describe EPP’s syntax. Registrars will be expected to send a valid XML document in order to communicate with Go Daddy’s SRS. Go Daddy’s EPP gateway will perform a schema validation as the first step of the handling of the XML document, using a validating XML parser. Invalid documents will generate an error message from the validation object that will be returned to the registrar. 

It will be required that all EPP XML instances begin with a 4-byte header (in Network order⁄Big Endian format) indicating the total message size (including the 4 bytes), followed by 〈 ?xml?〉 declaration using a recognized character set (UTF-8 or UTF-16) with an XML version of 1.0. All EPP commands will be enclosed within an 〈 epp〉〈 ⁄epp〉.

EPP PROTOCOL & OBJECT MAPPINGS

EPP Namespaces⁄Schemas which will be used within Go Daddy’s EPP gateway:

* Namespace - urn:ietf:params:xml:ns:epp-1.0 (RFC5730) 
Schema - epp-1.0.xsd 
* Namespace - urn:ietf:params:xml:ns:eppcom-1.0 (RFC5730)
Schema - eppcom-1.0.xsd 
* Namespace - urn:ietf:params:xml:ns:domain-1.0 (RFC5731)
Schema - domain-1.0.xsd 
* Namespace - urn:ietf:params:xml:ns:host-1.0 (RFC5732)
Schema - host-1.0.xsd 
* Namespace - urn:ietf:params:xml:ns:contact-1.0 (RFC5733)
Schema - contact-1.0.xsd
* Namespace - urn:ietf:params:xml:ns:secDNS-1.1 (RFC5910)
Schema – secDNS-1.1.xsd
* Namespace - urn:ietf:params:xml:ns:rgp-1.0 (RFC3915)
Schema - rgp-1.0.xsd

RESOURCING PLAN

Resourcing will come from current staff throughout the parent organization: Software Development, Network Operations, IT, Security Operations, and Business Continuity Departments. Go Daddy will incorporate all new gTLDs added to the Go Daddy registry into existing workflows to obtain immediate workability. Go Daddy has anticipated additional headcount in the coming year for all affected departments. See the headcount estimate in the ʺCASH OUTFLOWSʺ section in Go Daddyʹs answer to Question 46. 

Go Daddy’s Registration Data Directory Service (RDDS) (WHOIS Database Services) will be composed of three services: a WHOIS service available through port 43, a Web-based service providing free public query-based access, and a Web-based service providing registrars query-based access. The services access the same data store, which will be updated in near real time. 

To achieve and exceed the performance and reliability requirements as set forth in the Service Level Agreement Matrix (Registry Agreement, Specification 10), Go Daddy systems will be compartmentalized into functional areas. These individual areas will be comprised of hardware load-balanced clusters of N+1 servers. For any component server cluster, there will never be less than 2 servers, but there will be as many servers as necessary to meet Specification 10. Individual servers will be added or removed from the component cluster without negatively impacting normal activities or performance of the system component. The complete RDDS system will be deployed in each data center to provide active⁄passive redundancy. (See Attachment 1 to the answer to Question 32 for a representative network diagram.)

PORT 43 WHOIS SERVICE

Go Daddy will provide a transaction-oriented WHOIS service based on Transmission Control Protocol (TCP), which is compliant with RFC 3912. The service will listen on port 43 for incoming requests from WHOIS clients. All requests will be required to be terminated with Carriage Return Line Feed (CRLF) (\r\n). The service will close the TCP connection after the response is sent to a client.

DOMAIN NAME DATA (SPECIFICATION 4.1.4)

To determine information regarding a specific domain in the Go Daddy WHOIS database, for example, ʺDOMAIN EXAMPLEDOMAIN.GTLDʺ, a user would submit the domain name and the response returned would include, but may not be limited to:

1. Domain ID;

2. Domain data (i.e., last update, expiration date, creation date);

3. Sponsoring Registrar information (IANA ID, name, WHOIS server);

4. Domain Status(es);

5. Name server(s);

6. Contact data;

7. Last update of WHOIS database;

8. DNSSEC information.

REGISTRAR DATA (SPECIFICATION 4.1.5)

To determine information regarding a registrar in the Go Daddy WHOIS database, a user would submit the registrar name and the response returned would include, but may not be limited to:

1. Registrar information (name, create date, last updated date, address);

2. Contact information;

3. WHOIS server;

4. Last update of WHOIS database.

NAMESERVER DATA (SPECIFICATION 4.1.6)

To determine information regarding a host (nameserver) in the Go Daddy WHOIS database, a user would submit the host name or IP address and the response returned would include, but may not be limited to:

1. List of host name(s) or IP address(es); 

2. Sponsoring registrar;

3. WHOIS server.

CONTACT DATA

In addition to the Specification 4 requirements, Go Daddy will provide a contact data lookup on its WHOIS database for the gTLD. Response to a contact-based query would include, but may not be limited to:

1. Contact data (i.e., name, address, geographic location, phone and fax number(s), email address(es));

2. Sponsoring registrar;

3. Status(es) (last update date, creation date);

4. WHOIS server;

5. Last update of WHOIS database.

PUBLIC WHOIS SERVICE

The public Web-based WHOIS service will have the same functionality as the port 43 service with the addition of limited wildcard searches for Domain, Registrar and Name-server data. The system will be protected from abuse by the use of CAPTCHA and configurable IP-based WHOIS quotas.

REGISTRAR WHOIS SERVICE

The registrar Web-based WHOIS service will have the same functionality as the public WHOIS service with the addition of an expanded set of wildcard searches. The system will provide unlimited access to authenticated users through the registrar portal website. 

All three systems will be designed to provide metrics that will aid in future upgrade decisions, which include the detection of any potential failures, and the detection of any abuses of the system. The systems will be capable of limiting access if the terms of use are violated. 

RESOURCING PLAN

Resourcing will come from current staff throughout the parent organization: Software Development, Network Operations, IT, Security Operations, and Business Continuity Departments. Go Daddy will incorporate all new gTLDs added to the Go Daddy registry into existing workflows to obtain immediate workability. Go Daddy has anticipated additional headcount in the coming year for all affected departments. See the headcount estimate in the ʺCASH OUTFLOWSʺ section in Go Daddyʹs answer to Question 46.

Go Daddy will use standard lifecycle definitions found in the Extensible Provisioning Protocol Requests for Comments (RFCs).

A diagram of Go Daddy’s registration lifecycle is attached, as Attachment 1 to Question 27.

In outlining Go Daddy’s registration life cycle in this answer, states and intervening steps, including time elements, can be described as follows:

1. Active Status. Initial registration with Go Daddy will follow these rules: (a) registration may be for 1 month to 10 years; (b) the domain name must be unique; (c) the name may only contain letters, numbers or a hyphen (a hyphen cannot be used as the 1st, 3rd and 4th, or last character of the name); (d) the name must not be more than 63 characters; and (e) the domain may have 0-13 nameservers, though at least 2 nameservers must be defined for the domain to be placed in the zone.

The following modifications or updates will be made during active status: (a) renewal; (b) transfer; (c) deletion; (d) change of administrative contact, billing contact, technical contact, registrant; or (e) change of nameserver(s). 

A domain will be transferable from one registrar to another, except during the first 60 days following the registration or within 60 days following a transfer.

There will be a 5-day “Add Grace Period” after initial registration or transfer allowed during which deletion will result in immediate removal without a redemption period. Registrars will receive a partial credit for domains deleted during this period and will incur additional costs if more than 10% of their total monthly registrations are deleted during this period.

2. Auto-renew Status. This TLD will auto-renew upon expiration and will include a 30-day “Auto-renew Grace Period.” If an explicit delete is issued during the Auto-renew Grace Period the domain will be placed into Redemption Status and the Registrar will be refunded for the renewal.

The following modifications or updates will be able to be made during the auto-renew grace period: (a) renewal; (b) deletion; (c) transfer; (d) change of administrative contact, billing contact, technical contact, registrant; or (e) change of nameserver(s).

3. Redemption Status. Redemption status will begin if the domain has been deleted prior to expiration or when the domain has been explicitly deleted during the Auto-renew Grace Period. The redemption period will be 15 days. The domain will be re-delegated to a default redemption web page. The domain may be able to be restored during a 15-day redemption period upon payment of a redemption fee.

The following modifications or updates will be able to be made during redemption status upon payment of an additional fee: (a) renewal; or (b) transfer.

4. Deleted Status. When a domain name is deleted from active status or during the auto-renew grace period, it will enter the redemption period, (unless it is deleted within five days from initial registration). Once a domain passes the redemption period, it will be permanently deleted from the Registry. No changes will be allowed at this point, except that the domain name would be available for new registration.

RENEWAL

Renewal will extend the registration period by changing the expiration date. The following rules will apply to renewals: (a) a domain may be renewed at any time during its lifecycle (active, or during redemption); (b) a renewal period will not exceed the maximum term allowed; and (c) a 5-day Renewal Grace Period will ensue upon renewal of a domain name. Domains deleted during the Renewal Grace Period will go immediately into redemption status.

TRANSFER

Transfer of a domain will be allowed between registrars. The following rules will apply to transfers: (a) transfer will not be permitted during the first 60 days following initial registration or a previous transfer; (b) a valid authorization (authinfo) code will be required for all transfers; (c) only unrestricted domain names will be allowed to be transferred; and (d) valid transfer requests will result in the domain remaining in a pending status for up to 5 days (the Transfer Pending Period). While pending, the losing registrar may approve (Ack) or deny (Nack) the transfer request. If the losing registrar takes no action during the 5-day pending period, the transfer will automatically be approved.

Domain names deleted during a transfer will go into redemption status.

RESOURCING PLAN

Resourcing will come from current staff throughout the parent organization: Software Development, Network Operations, IT, Security Operations, and Business Continuity Departments. Go Daddy will incorporate all new gTLDs added to the Go Daddy registry into existing workflows to obtain immediate workability. Go Daddy has anticipated additional headcount in the coming year for all affected departments. See the headcount estimate in the ʺCASH OUTFLOWSʺ section in Go Daddyʹs answer to Question 46.

All abuse involving domain names registered with or through Go Daddy may be reported to abuse@godaddy.com, or via Go Daddy’s 24x7 Abuse hotline at 1-480-624-2505. Go Daddy companies have a long-standing policy of investigating every complaint Go Daddy receives (already hundreds of thousands per year) and responding appropriately and taking necessary action to mitigate the reported abuse. Go Daddy will abide by its contractual obligations to registrants, resellers, registries and other registrars to set requirements and procedures, as detailed herein, to handle all types of abuse.

Go Daddy defines abuse as:

1. Misuse of the TLD or domain name infrastructure, which may include but is not limited to: (a) domain name hijacking; (b) fast flux DNS (rapidly changing the Domain Name Service (DNS) so that it can’t be taken down by the host provider; (c) intellectual property infringement (trademark); (d) invalid WHOIS information; or (e) mining of WHOIS data.

2. Violation of the acceptable use policies of the registry and⁄or registrar, which may include but is not limited to, use of a domain name in association with spam, phishing, illegal content, hacking, malware, illegal pharmacies, child abuse content, intellectual property (trademark or copyright).

POLICIES FOR HANDLING COMPLAINTS REGARDING ABUSE 

Go Daddy’s Abuse and Domain Services teams will have a robust library of public policies and internal procedures for investigating and responding to abuse complaints. Every Go Daddy action will get logged via an internal activity-reporting tool that is used to compile metrics. These reports will be used to identify trends and areas of focus.

Go Daddy’s policies for handling complaints regarding abuse will include:

1. Immediately responding to claims regarding domain name abuse, such as hijacking (Go Daddy will provide a 24⁄7 hijacking hotline).

2. Encouraging registrars to communicate and work together to coordinate the recovery of domain names. Go Daddy will reserve formal and⁄or lengthy processes for incidents requiring escalation, using: (a) the Inter-Registrar Transfer Policy (IRTP); (b) the Transfer Dispute Resolution Policy (TDRP); and (c) the Transfer Undo Request Forms (TURF), a document which has been jointly adopted by select registrars for handling hijacking.

3. Promoting awareness of hijacking risks and providing information to customers about how to prevent hijackings, including the presentation of relevant information in online help articles and through customer service representatives.

4. Rapid response to Form of Authorization (FOA) requests.

5. Requiring registrars to adopt “undo” measures and to investigate the possibility of returning a hijacked name before it transfers to another registrar.

6. Sharing Go Daddy’s best practices with registrars to help successfully ward off potential hijackings. For example, Go Daddy hosts an annual Registrar Summit, bringing registries and registrars together to discuss domain name, abuse, and legal issues.

7. Educating registrars on how they can use the IRTP and the TDRP to guide them through hijacking events.

8. Requiring registrars to alert both registrants and administrative contacts when information changes on a domain name. 

9. Requiring registrars to invoke a lock if the registrant’s first name, last name, and⁄or the company name information are changed on a domain name, preventing the name from transferring for 60 days.

10. Proactively monitoring Go Daddy’s DNS for excessive changes to domain names by imposing limitations on “Time to live” (TTL) values to discourage fast flux abuse. 

11. Referring customers with intellectual property disputes to the Uniform Domain Name Dispute Resolution Policy (UDRP); and facilitating and abiding by those proceedings. 

The removal of orphan glue records is not an existing abuse mitigation process at Go Daddy. However, Go Daddy would work with Go Daddy’s DNS and internal-tools teams to develop an interface that would allow Go Daddy to quickly identify any glue records for a given domain, and give the Abuse team the ability to remove reported orphaned glue records when Go Daddy receives such a report from the above mentioned abuse@godaddy.com email address, or from the general dns@jomax.net email address.

Resourcing will come from current staff throughout the parent organization. Go Daddy will incorporate all new gTLDs added to the Go Daddy registry into Go Daddy’s existing workflow to obtain immediate workability. Go Daddy will commit to maintaining sufficiently staffed departments to effectively deal with abuse issues as described in this document. Go Daddy anticipates additional headcount in the coming year in both its Abuse and Domain Services departments to allow for complaint volume increase, and for the potential need to communicate with multiple registrars regarding the gTLD.

WHOIS ABUSE

Go Daddy will support measures that help promote and maintain WHOIS accuracy. Go Daddy companies have proven experience in addressing complex WHOIS accuracy issues and has developed standard operating procedures, including quick response time on all claims and consistency in remedial action when the WHOIS is not verified or updated, the Registry will utilize the same SOPs.

Go Daddy will be committed to maintaining the highest level of WHOIS accuracy that is technically and economically achievable. Go Daddy will establish Invalid WHOIS investigation procedures that will mirror those used throughout the Go Daddy companies, which recently received positive attention from ICANN due to their practicality, exceptional promotion of WHOIS accuracy, and compliance and facilitation with the following policies:

1. ICANN’s Registrar Advisory Concerning WHOIS Data Accuracy

2. ICANN’s WDPRS (WHOIS Data Problem Report) 

3. ICANN’s WDRP (WHOIS Data Reminder Policy)

In addition to the existing consensus policies, Go Daddy will have both proactive and reactive approaches in place that will exceed its legal obligations to maintain WHOIS accuracy.

The following proactive measures would be taken before the name was activated in the DNS:

1. Go Daddy would continue to educate registrars and end-users regarding WHOIS accuracy and consequences. As part of the registration processes, customers must agree to maintain valid WHOIS contact information. Go Daddy will provide instruction through Help articles and through customer service regarding updating WHOIS contact information and keeping that information up to date. In the Help articles, for instance, Go Daddy will emphasize the importance of valid contact information to prevent domain name loss and unauthorized transfers and changes to domain names. Likewise, Go Daddy will provide simple and accessible forms on its site that allow third parties to complain of invalid WHOIS information. Go Daddy will also have a specialized 24⁄7 team that helps customers and third party complainants understand the WHOIS accuracy process. Go Daddy will require registrars to provide the same level of education to customers as well as the same easily-accessible forms on their sites.

2. Go Daddy will develop a standardized format for registration data for the gTLD and will provide the format to registrars. Go Daddy will require that registrars submit data compliant with Go Daddy’s standardized format. The format will include the fields that are currently required in the WHOIS database.

Go Daddy will investigate each abuse complaint based on its own merit. Go Daddy will then apply the most appropriate established procedure developed by the Go Daddy companies over the past 10 years of successful abuse mitigation efforts.

 The following reactive measures would be used to investigate each abuse complaint after a name is activated in the Domain Name System (DNS):

1. Go Daddy will require that all accredited registrars notify Go Daddy upon receipt of an Invalid WHOIS claim from ICANN, and copy Go Daddy on their response to ICANN. Additionally, Go Daddy would reserve the right to take action on the claim if it appeared that the registrar’s actions were insufficient or inappropriate.

2. Go Daddy will inspect data upon submission and ensure that it conforms to the proper format. Go Daddy will periodically inspect random samplings of WHOIS data for active registrations. Go Daddy will then examine those samples for inaccuracies and report inaccuracies to registrars, requiring them to take action.

3. Go Daddy will quickly and efficiently respond to requests from verified law enforcement officers to suspend websites or services that are officially declared to be part of an investigation. These issues will be handled on an escalated basis and answered within a matter of 2-3 hours on average. Go Daddy will have similar service level requirements for first response and investigation of general abuse complaints. Go Daddy aims for a 6-24 hour response time depending on the severity of the type of abuse being reported.

4. Issues likely to have higher urgency will be triaged by Go Daddy’s Abuse department staff and handled on an expedited basis. High priority issues will include, but are not limited to, child abuse⁄exploitation, phishing, malware, hacking, and other issues that negatively impact multiple customers⁄users, or where there is a clear threat of the imminent danger of such. 

CONTROLS TO ENSURE PROPER ACCESS TO DOMAIN FUNCTIONS

Go Daddy will have measures in place that require Go Daddy’s customers to select strong passwords. Passwords determined to be too weak (by automated process) will not be permitted to be created in many of Go Daddy’s product and application environments. 

Customers who contact Go Daddyʹs telephonic support department will be required to provide 2-factor authentication information, such as a PIN and the last six digits of their on-file credit card number, to process certain sensitive operations. 

Go Daddy will also use Port 43 WHOIS access to discourage WHOIS data mining. See the response to Question 26, herein. 

In order for a transfer of a domain name to take effect, validation will be required in a response to a notification email.

Go Daddy has an experienced staff that is trained in handling intellectual property matters and is invested in helping trademark owners protect their brands. Go Daddy responds to and assists thousands of trademark holders in protecting their brands and consumers by enforcing Go Daddy’s Trademark and⁄or Copyright Policy (http:⁄⁄www.godaddy.com⁄agreements⁄showdoc.aspx?pageid=TRADMARK_COPY). Go Daddy removes content that contains reported infringements. Go Daddy also assists in takedown of infringing domain names that: (a) appear at Go Daddy Auctions; (b) use Go Daddy’s Premium Domain service; or (c) resolve to a parked page. In 2011, Go Daddy processed almost 1,000 suspensions for trademark claims, over 200 takedowns of parked pages, and over 600 removals of domain names from Go Daddy’s auction and Premium Domain name services. 

Go Daddy abides by its contractual obligations to registrants, resellers, registries and other registrars to set requirements and procedures, as detailed herein, to handle all types of abuse.

In Go Daddy’s role as a registry, Go Daddy would:

1. Use Go Daddy’s expertise in handling requests from trademark holders. Go Daddy is currently poised to over-deliver when it comes to protecting brand holders. There is currently no trademark equivalent of the Digital Millennium Copyright Act (DMCA) (http:⁄⁄www.copyright.gov⁄legislation⁄dmca.pdf) that rewards web hosting providers with a safe harbor for complying with a notice and takedown regime for web hosting providers and other Internet service providers. Nevertheless, Go Daddy serves as a leader in the web hosting industry by establishing a trademark claims process with notice and takedown even though not required or rewarded by law. 

2. Require registrars to have a reporting system for trademark abuse on sites they host.

3. If Go Daddy was not satisfied with the way a registrar handles trademark abuse on sites they host, Go Daddy would maintain the right to take action.

Go Daddy follows the Uniform Domain Name Dispute Resolution Policy (UDRP) for domain disputes. Go Daddy’s customers are required to agree to the UDRP upon registration of their domain names. Likewise, Go Daddy consistently refers to the UDRP at all customer service levels in any cases of domain dispute. 

Go Daddy will also adhere to the Trademark Post-Delegation Dispute Resolution Procedure (PDDRP) and the Registration Restriction Dispute Resolution Procedure (RRDRP) as adopted by ICANN. 

In Go Daddy’s role as a registry, with respect to the UDRP, PDDRP, RRDRP, or other mandated ICANN policies, Go Daddy would:

1. Enforce directions given by an arbitration forum. 

2. Require registrars to promptly implement decisions within the timeframe prescribed by the arbitration forum (usually 10 days).

3. Communicate expeditiously with the corresponding registrar if Go Daddy receives a filed decision or complaint that needs to be implemented, so that the decision will be universally implemented and the registrar(s) may update their records.

4. Agree to abide by, implement, and adhere to any remedies ICANN imposes (which may include any reasonable remedy, including the termination of the Registry Agreement pursuant to Section 4.3(e) of the Registry Agreement) following a determination by any PDDRP or RRDRP panel, in accordance with Specification 7.

Go Daddy does not have actual experience using the Uniform Rapid Suspension (URS) system (as it is a new mechanism in the industry), but Go Daddy is supportive of and familiar with the URS system, and will implement it as required. 

In Go Daddy’s role as a registry, with respect to the URS, Go Daddy would:

1. Implement the URS with the procedures outlined by ICANN.

2. Draw from Go Daddy’s experienced staff to maintain and⁄or improve the implementation of the URS policy. 

3. Use Go Daddy’s understanding of existing policies against abusive registrations to help administer URS mechanisms that are similar in nature. 

4. Implement decisions rendered by the URS or other administrative bodies with the same adeptness that Go Daddy manages UDRP disputes.

5. If need be, provide additional human resources to handle the initial implementation of the URS system, and to handle any unforeseen issues or to help with continual maintenance and improvements of the system.

In previous TLD launches, Go Daddy has had the opportunity to observe, facilitate, and learn from the methods used by registries to help trademark holders secure registrations. In Go Daddy’s role as a registry, with respect to TLD launches, Go Daddy would:

1. Use Go Daddy’s experience to help trademark holders secure domain name registrations. 

2. Recognize that TLD launches may include preceding or subsequent phases for other classes of applicants or registrants, such as governments.

3. Execute the TLD launch in distinct phases, including a pre-registration (e.g. “Sunrise”) period of not less than 45 calendar days, during which: (a) brand holders (or their authorized representatives) can submit applications for their strings in the TLD; (b) Go Daddy may engage an independent third-party service provider to validate brand applications; and (c) Go Daddy will verify brand applications against those listed in the Trademark Clearing House (TMCH).

4. Observe a “quiet period” of no less than 10 days before each TLD launch phase commences.

Because Go Daddy already has fully-staffed and functioning 24x7 Abuse and Domain Services departments, Go Daddy will incorporate all new gTLDs added to the Go Daddy registry into Go Daddy’s existing workflow to obtain immediate workability. Go Daddy anticipates additional headcount in the coming year in both its Abuse and Domain Services departments to allow for complaint volume increase, and for the potential need to communicate with multiple registrars regarding the gTLD. 

Go Daddy’s existing funding, Shared Registration System, database capabilities, security policy, WHOIS system, Domain Name System (DNS), early adoption of Domain Name System Security Extensions (DNSSEC), automatic domain name locking system, and other network systems, which are described in this application, all contribute to the ability of Go Daddy’s Abuse and Domain Services Teams to mitigate and prevent abuse.

In addition, Go Daddy’s long-standing reputation for protecting the rights of registrants has discouraged misuse of the DNS. For example, recent Anti Phishing Working Group (APWG) reports have shown that, in comparison to the number (market share) of domain names registered with Go Daddy, the percentage of malicious domain names registered with Go Daddy is comparatively quite low.

SECURITY ASSESSMENT REPORTS

Annually, the company submits to three external assessments of its security processes. 

1. The company’s SSL issuance service complies with WebTrust for Certificate Authorities and WebTrust Extended Validation criteria.

2. The company receives a Service Organization Control (SOC) 2⁄ 3 report relating to Statement on Standards for Attest Engagements (SSAE) No. 16 attesting to the security of its hosting operations.

3. The company complies with Payment Card Industry Data Security Standard (PCI-DSS) with respect to processing payments from its customers, and its Quick Shopping Cart product.

See Attachments 5-9 to the response to Question 30 (b) for details. 

AUGMENTED SECURITY LEVELS

In addition to the requirements outlined in the Security Assessment Reports section, the company has also implemented security practices in accordance with:

1. ISO⁄IEC 27002, located at http:⁄⁄www.iso.org⁄iso⁄catalogue_detail?csnumber=50297 

2. Open Web Application Security Project (OWASP), located at https:⁄⁄www.owasp.org⁄index.php⁄Main_Page 

3. Computer Security Incident Response Team, located at http:⁄⁄www.csirt.org⁄

LOGICAL SECURITY PROCESSES & SOLUTIONS

The company has a dedicated security department made up of over 30 security professionals who report to the Chief Information Security Officer (CISO) and has twenty-four (24) hour per day, seven (7) day per week coverage to monitor the environment and respond to incidents. Each of the security personnel possess at least 4 years of security experience and are required to obtain their CISSP certification. The department is further broken into various specialty teams that ensure the overall security of the company. These teams include security operations, penetration testing, forensics, engineering, and research. The company also has a privacy committee made up of individuals from four different departments, including Security, Networking, Development, and eCommerce. They are responsible for review and approval of changes to security-sensitive environments, and the information security policy.

ROLES AND RESPONSIBILITIES

Roles and responsibilities for the information security department and teams responsible for implementing security are defined to enforce appropriate segregation of duties with respect to implementing and monitoring security. All individuals responsible for implementing and monitoring security, as well as individuals who are granted access to security-sensitive information are required to pass annual background and credit checks.

SECURITY POLICIES

The company’s security policies document details requirements for users and system administrators, and specifically cites ISO⁄IEC 27002, WebTrust for Certificate Authorities, and PCI-DSS, where applicable, for each policy. The document is posted on the company’s intranet site. Employees review and acknowledge the policies on hire and at least annually. See Attachment 1 to the response to Question # 30(b).

The company’s software development lifecycle document (SDLC) also contains specific guidance with respect to secure coding techniques required for software developed internally. See Attachment 2 to the response to Question # 30(b).

In addition to the security policies, the security department also maintains an operations guide and an incident response procedure. The operations guide details the daily monitoring and reporting responsibilities of the security operations staff. The incident response document is tested at least annually. See Attachment 3 to the response to Question # 30 (b) in relation to the SOC Operations Guide. See Attachment 4 to the response to Question # 30 (b) in relation to the CSIRT document.

SECURITY POLICIES VERSION 3.14

The security policy is broken into eleven (11) sections, topically addressing the security organization, asset management, integration with human resource policies, physical and environmental security, communications management, operations management, access control, software development, incident management, business continuity management and compliance.

Logical access control is enforced using a combination of hardware, software and procedures. Examples include, but are not limited to, firewalls, addressing, account management, security awareness exercises, security devices and physical security.

SOFTWARE DEVELOPMENT LIFECYCLE (SDLC) VERSION 1.18

The SDLC outlines the separation of test and production environments, provides guidelines for secure coding, outlines approvals and the change process, and details industry standards and best practices that should be used throughout the development lifecycle. See Attachment 2 to the response to Question 30(b) for details. 

Pursuant to compliance standards and industry best practices, any development changes are implemented in the test environment, tested by Quality Assurance (QA), approved by the appropriate members of management, and deployed into production. Prior to implementation of any changes, a rollback plan is conceived which outlines the details for removing the change from the production environment. Post implementation testing is also required, during which time QA verifies the functionality of software in the production environment. 

The SDLC also outlines additional business approvals which help safeguard company information and availability. For example, additional approvals are required anytime there will be a system change which involves any financial or accounting information. A privacy committee is required to review and approve the Software Architecture Specification (SAS) for any such changes prior to implementation into the production environment. Furthermore, all high risk and high impact changes also have an additional level of approval, which must approve the change prior to deployment into the production environment.

The SDLC reaffirms the company’s subscription to the Open Web Application Security Project (OWASP - http:⁄⁄www.owasp.org) principles and best practices and mandates that all developers and QA are familiar with the OWASP site. Additional OWASP training materials are listed for employee reference. Additionally, Developers and QA who support protected systems are required to pass courses on the topic of programming for security.

COMPUTER SECURITY INCIDENT RESPONSE TEAM (CSIRT)

The CSIRT procedures are broken into seven sections that address the roles and responsibilities of the CSIRT. Its main purpose is to address the process for managing incidents as they arise and to delegate responsibility for the different members of the CSIRT. The seven sections are as follows: Document Description, Team Composition and Contact Information, Charter, Services, CSIRT Flow Chart, Attachment 1 (External Incident Report Form), and Attachment 2 (Major Incident Report Form). See Attachment 4 to the response to Question 30(b) for details. 

SECURITY OPERATIONS CENTER (SOC) OPERATIONS GUIDE 

The operations guide includes procedures for daily, monthly, quarterly and annual tasks performed by the Security Operations Center (SOC). In summary, the guide provides definitions of daily security reports, vulnerability scanning requirements, and required drills. See Attachment 3 to the response to Question 30(b) for details.

RELATIONSHIPS WITH OTHER SECTIONS OF THE APPLICATION

This overview is consistent with the technical, operational and financial approach outlined in answers provided to Questions # 22-29, 31-43 and 45-50. It encompasses commitments made to registrants in Go Daddy’s Privacy Policy, located at http:⁄⁄www.godaddy.com⁄agreements⁄ShowDoc.aspx?pageid=privacy and Go Daddy’s Universal Terms of Service and other service agreements, located at http:⁄⁄www.godaddy.com⁄legal-agreements.aspx?ci=46445&otab=2. Go Daddy will provide the same level of contractual commitments to registrants of the gTLD. As outlined in the Security Organization section above, an adequate level of resources are on hand, and additional resources may be committed if needed. The company’s current security, as outlined in this section, is commensurate with the nature of the applied-for gTLD string.