Application number: 1-1678-4292 for Charleston Road Registry Inc.

Charleston Road Registry Inc.

1600 Amphitheatre Parkway
Mountain View 94043
US

16502530000

1 650 253 0001

Ms. Sarah Falvey

Senior Policy Analyst

1 202 346 1230

tas-contact8@google.com

Chris Iannuccilli

Director of Marketing

1 650 253 2903

chrisiann@google.com

Corporation

State of Delaware (General Corporations Code)

Not Available

Google Inc.

Katherine Stevens
Director

Donald S. Harrison
Assistant Secretary
James Marocco
CFO and Treasurer
Katherine Stevens
CEO, President, and Secretary

Google Inc.
Not Applicable

mba

Not Available

While the string for which CRR is applying, .mba, is not an IDN and, therefore, does not contain characters which require mixed right-to-left or left-to-right functionalities, CRR has nonetheless familiarized itself with the requirements and components of the IDNA protocol by reviewing the relevant RFCs and the relevant background information found on the ICANN IDN Wiki. CRR has also tested the .mba string for rendering issues; none were found.

18.a. Mission⁄Purpose of the Proposed gTLD

Charleston Road Registry is an American company, wholly owned by Google, which was established to provide registry services to the Internet public. Google is an American multinational public corporation and global technology leader focused on improving the ways its hundreds of millions of users connect with information. Since its formation, Google has been developing technology that can improve upon existing ways of doing business on the Internet. Google provides a variety of services and tools for Internet users and advertisers of all sizes, from simple search features and local ads to enterprise-scale business applications and global advertising solutions. These tools make it easier for people to make use of the world’s information and enable entrepreneurs and publishers around the world to grow their businesses.

In line with Google’s general mission, Charleston Road Registry’s mission is to help make information universally accessible and useful by extending the utility of the DNS while enhancing the performance, security, and stability of the Internet for users worldwide. Charleston Road Registry aspires to create unique web spaces where users can learn about products, services, and information in a targeted manner and in ways never before seen on the Internet. Its business objective is to manage Google’s gTLD portfolio and Google’s registry operator business. As discussed further in the responses to questions 23 and 31, Charleston Road Registry intends to outsource all critical registry functions to Google Registry Services.

The proposed gTLD will provide the marketplace with direct association to the term, ʺmba,ʺ an acronym for the ʺMasters in Business Administrationʺ degree. The mission of this gTLD, .mba, is to provide a dedicated domain space for MBA-related content offered by for institutions that award MBA degrees and entities that provide MBA-related content, products or services. This mission will enhance consumer choice by providing new availability in the second-level domain space for MBA program institutions and MBA-related product and service providers, creating new layers of organization on the Internet, and signaling the kind of content available in the domain.

The proposed gTLD will also provide Charleston Road Registry with the means to meet its business objectives.

18.b. Benefits to Registrants, Internet Users, and Others

18.b.i.1. Specialty

The goal of the proposed gTLD is to create a new Internet environment that provides registrants with the opportunity to associate with a meaningful term. 

Charleston Road Registry, as the registry operator, will define the specialized meaning of the term and, based on this definition, will identify criteria for registrants to operate in the proposed gTLD. Only entities that meet these criteria will be entitled to register for a domain in the gTLD. Specialization, therefore, arises from the Charleston Road Registry definition of a term, as well as through market dynamics as entities align their offering(s) with the term. This specialization will be maintained through intermittent audits to ensure the relevancy of content in the proposed gTLD to the defined meaning of the gTLD.

The specialization goal of the proposed gTLD is to create a new Internet environment that provides registrants with the opportunity to associate with the term ʺmbaʺ and to provide content or offerings related to MBA education within that dedicated domain space. This specialization introduces a new domain name hierarchy with the express purpose of being a destination for MBA-related content.

18.b.i.2. Service Levels

Through its association with Google, Charleston Road Registry is uniquely positioned to enable and support the proposed gTLD by providing its service reliability and speed of delivery as a part of its services. Google brings unique expertise and a proven record of excellence in infrastructure operations: Google now runs the largest DNS system in the world, has industry-leading uptime on its services, such as web search, and offers enterprise services on which governments and businesses depend.

Google is known for its high level of quality and speed, and Charleston Road Registry’s service level goal for the proposed gTLD is to extend that high level of quality, speed, and service to registrars. Indeed, two of Google’s core principles are “focus on the user and all else will follow” and “fast is better than slow.”

Charleston Road Registry is committed to using the most technologically advanced, secure, and reliable registry services for all of the domain names in the gTLD so as to not compromise the service levels, security, and stability of the gTLD to users across the globe.

Charleston Road Registry will provide both Engineering and Customer Service support to registrars. All registrars will also have the same level of access to Charleston Road Registry resources to resolve disputes and technical and⁄or administrative customer service issues. 

Charleston Road Registry will provide all registrars with 24-hours-a-day, 7-days-a-week Customer Support in the form of telephone, email, and⁄or web chat for technical and non-technical issues relating to the operation of the gTLD system. Charleston Road Registry will provide all registrars with the same level of access to customer support via telephone, email, and Charleston Road Registryʹs website; email and web-based interactions will be the primary method of provisioning customer service support to registrars.

18.b.i.3. Reputation

Google has a proven record of providing high-quality, secure online services. Charleston Road Registry seeks to enhance Google’s reputation for excellence, superior quality, and high level of security and become known as an exemplary domain name services provider. When registrants assess opportunities in the marketplace to obtain a name, they will have confidence in Charleston Road Registry’s ability to meet ongoing needs as the registry operator for the proposed gTLD. When Internet users visit a domain name in the proposed gTLD environment, they will be able to reliably expect and experience the high level of security and quality on which Google’s reputation has been built.

The registry will be structured in such a way that Charleston Road Registry will enable registrars to register and oversee second-level domain names in the proposed gTLD; that registrars develop and deploy a reasonable process for ensuring that those domain names are used for gTLD-relevant purposes as specified in the registry-registrar agreement; that the WHOIS is thick and reliable; and that the registry is responsive to legal rights owners (if applicable) who may have complaints about potentially abusive registrations.

Charleston Road Registry plans to develop and publish eligibility criteria for all registrants in the proposed gTLD and will work with its registrars to execute the eligibility verification process. This process will imbue additional meaning to all second-level domains in the gTLD and enhance the gTLD’s reputation by establishing an authoritative community of content providers. When Internet users visit a website in the proposed gTLD environment, they will be able to reliably expect content relevant to the proposed gTLD.

In addition, Charleston Road Registry’s operation of the new gTLD will provide the opportunity for registrars and registrants to build and⁄or bolster their unique brands and brand reputation in association with the proposed gTLD.

18.b.ii.1. Competition

Charleston Road Registry supports the advancement of registry operators as a whole and the diffusion of gTLDs amongst diverse stakeholders to generate increased competition for the benefit of the Internet public. Increased competition will result in more competitive prices for consumers, generate efficiencies and increase productivity in enterprises, and spur innovation in the gTLD space.

The proposed gTLD, .mba, will provide a new mechanism whereby organizations, educational institutions, and registrants can offer individuals products and services related to the MBA degree. As an alternative to existing second-level domains, Charleston Road Registry anticipates that the .mba gTLD will increase competition among registrars. Charleston Road Registry also anticipates the .mba gTLD will help grow the volume of MBA-related content providers and educational institutions on the Internet, thereby increasing competition among all such providers.

Managing this namespace will allow Charleston Road Registry to provide to registrars and registrants the high level of technical operations quality and service for which Google is known, which in turn will incent other existing and new gTLDs to improve the quality of their offerings.

Charleston Road Registry will facilitate a fair and equitable registrar process, providing open access to any registrar who meets ICANN accreditation guidelines and fully complying with the Registry Operator Code of Conduct. Charleston Road Registry is committed to treating all registrars equitably and will not offer preferential treatment to Google in its capacity as registrar.

18.b.ii.2. Differentiation

Charleston Road Registry believes in the commercial viability of alternatives to existing gTLDs such as .com and .net. 

The proposed gTLD will provide the marketplace with an authoritative space for registrants to deliver content, imparting brand differentiation not currently available in the current gTLD space. It also delivers value to the Internet public by defining the meaning of the gTLD term, providing for the verification of registrants who will offer content in the proposed gTLD environment, and encouraging a specific use. These activities differentiate the proposed gTLD space in a new and meaningful way.

The .mba gTLD will provide a new mechanism whereby businesses and individuals can differentiate their content by signifying that their offerings are relevant to the MBA degree. This signification is not currently available in the gTLD space.

In addition, given its association with Google, Charleston Road Registry offers a unique value proposition to registrars and registrants resulting from the strength of Google’s trusted brand, technical leadership, and support for free speech on the Internet. Registrars will have the opportunity to leverage this brand in devising their own market positions.

18.b.ii.3. Innovation

The proposed gTLD will foster innovation by creating a new space for the categorization and classification of online content. It will therein provide a mechanism by which registrars and registrants can better brand and manage their online presence by associating it with the .mba namespace. This namespace delivers value to the public through the provision of new and differentiated content, goods, and services to Internet users.

The proposed gTLD, .mba, will promote innovation among registrars by providing for the sale of a second-level domain in a gTLD that will attract a specific segment of registrants, MBA-related content and service providers and educational institutions. This provides registrars with the opportunity to create and offer tailored new content that benefits registrants and⁄or improves user experience in association with the registration of a second-level domain in the .mba gTLD. In addition, the concentration of MBA-related content providers and educational institutions in the .mba gTLD space will likely invite user comparison among second-level domain sites, encouraging second-level domain registrant offering innovation as a point of differentiation.

Charleston Road Registry considers the proposed gTLD to be a platform for innovation with existing and future Google products and services. Charleston Road Registry, therefore, may incorporate these new offerings into future registry service options (subject to the ICANN approval process), infusing new ideas into the gTLD for the betterment of the public.

Google consistently aims to improve upon technologies that connect people with information, as demonstrated by a proven record of innovation and iteration. Charleston Road Registry strives to offer its constituents this same level of continuous development in advancing its management and operation of the gTLD, engendering benefits to registrars, registrants, and end users.

18.b.iii. User Experience

Charleston Road Registry will strive to provide the highest level of user experience through operational stability, security, and performance to serve the interest of registrants in the proposed gTLD. Charleston Road Registry is uniquely positioned to provide this level of experience given its relationship with Google; Google invested over $3 billion in its IT infrastructure in 2011 and maintains a record of excellence in infrastructure operations. 

The proposed gTLD will provide registrants with the opportunity to differentiate their dedicated domain space such that the end users are able to discern the type of content intended to be found within the proposed gTLD. This will enable increased user visibility of registrants’ offerings, as well as provide registrants with the opportunity to enhance their respective content offerings and innovate in new ways.

The proposed gTLD will provide a more trusted and user-friendly environment where domain names and content related to the .mba gTLD can flourish. Charleston Road Registry seeks to have users deem the gTLD trustworthy and reliable and recognize it as an aggregated source of targeted goods, services, and information.

The proposed gTLD, furthermore, facilitates an improved online user experience through greater structure and categorization on the Internet. 

18.b.iv. Registration Policies

Charleston Road Registry will make access to Registry Services, including the shared registration system, available to all ICANN-accredited registrars. Domain names within the proposed gTLD will be available to the public for registration and use.

Charleston Road Registry is committed to implementing strong and integrated intellectual property rights protection mechanisms. Doing so is critical to Google’s goals of model Internet citizenship and fostering Internet development, especially in emerging regions. Accordingly, Charleston Road Registry intends to offer a suite of rights protection measures which builds upon ICANNʹs required policies while fulfilling our commitment to encouraging innovation, competition, and choice on the Internet.

Charleston Road Registry reserves the right to impose registrant verification enforcement policies on registrars.

Charleston Road Registry believes that the .mba gTLD will best add value to the gTLD space by limiting registration to only verified MBA-awarding institutions and MBA-related product and service providers. Charleston Road Registry plans to require registrars to confirm that a domain applicant is one such entity via an established process. If the domain applicant passes the eligibility verification process, only then will the applicant be eligible to apply for a second-level domain in the .mba gTLD. To preserve the integrity of the gTLD, Charleston Road Registry reserves the right to adopt certain monitoring measures, including periodic audits. Charleston Road Registry also reserves the right to adopt enforcement measures, including a request that registrars facilitate a user reporting method to log complaints and⁄or potential instances of misuse within the gTLD. If a registrant is found to be in violation of the terms of the registry-registrar agreement or the registrar-registrant agreement, Charleston Road Registry may request that the appropriate registrar enforce such agreements through penalties, including but not limited to suspension of the domain name.

18.b.v. Protection of Privacy and Confidential Information

Charleston Road Registry will strive to ensure the appropriate level of privacy and security will be met for its users. Charleston Road Registry and its provider of registry services, Google, have imposed measures to achieve this protection; additional specifics regarding the practices for the registry include but are not limited to the following:

 -All data transmitted from registrars to the registry will be encrypted using TLS or other similar data protection schemes to ensure that third parties cannot access personally identifying information or other sensitive data as it crosses the Internet.

- Charleston Road Registry will attempt to prevent the misuse of WHOIS data for improper purposes such as spam, intellectual property theft or phishing. Charleston Road Registry will attempt to identify patterns of abusive usage of WHOIS and will appropriately use CAPTCHA, query throttling or other techniques to prevent information scraping.

- Google will restrict access to data and information systems maintained by the registry to a specific list of individuals involved with supporting the Google Registry system in production. Google will review this list on a periodic basis to ensure that the level of access granted to individuals is appropriate. Google uses two-factor authentication and other mechanisms to ensure that staff with access to user information are properly identified prior to using registry systems.

- Google data backups stored offsite are encrypted with passwords that are securely managed on Google’s internal systems. Google can effectively remove the ability to access this data by destroying the relevant encryption password.

- Supplying Google account information will be optional for registrants unless the domain registration is directly associated with another Google product offering. Google will not disclose Google account information except for any contact information provided by the user that is required by ICANN to be displayed in response to a WHOIS query.

- Registrar billing and payment information will not be stored alongside domain name registration information. All registrar billing and payment information will be stored in a PCI-compliant billing system similar to that used by Google Ads.

- Data will not be shared with third parties without permission of registrants, except as required for registry operations or as required under the law, such as in response to a subpoena, other such court order, or demonstrated official need by law enforcement.

Beyond these specific mechanisms, both Charleston Road Registry and Google will govern its approach to privacy by the Google Privacy Policy. This policy applies to registrars, registrants and end users of registry services such as DNS zone publication and WHOIS data publication. The Privacy Policy is located at http:⁄⁄www.google.com⁄policies⁄privacy⁄.

18.b.vi. Outreach and Communications Efforts

Once Charleston Road Registry begins developing public-facing resources in its gTLD, it intends to inform the public about the gTLD and the opportunity to obtain domain space there through investments in marketing and public relations.

Charleston Road Registry intends to promote gTLDs in its portfolio collectively, such that the public gains an awareness and understanding of new gTLDs and the availability of new second-level domain space on the Internet. Charleston Road Registry believes that this approach will make the strongest impact in modifying consumer behavior and is the best path to achieving success for all new gTLDs collectively.

Charleston Road Registry will reach out to the Internet community via a number of different outreach and communications methods and venues to deliver its mission and message to the public, including but not limited to: press briefings, videos posted on various Internet sites, blogs and other social media, and paid advertising. In addition, when developing resources for localized Internet registrars in different global regions, Charleston Road Registry will use local marketing and communications platforms as needed.

18.c. Minimizing Social Costs and Other Negative Consequences

18.c.i
Members of the public will need to meet stated registration policy criteria to register domain names in the proposed gTLD. 

Registration will be managed by Charleston Road Registry in three phases. 

Phase 1 - The first phase will be an extended 60-day sunrise phase. Only owners of trademarks listed in the Trademark Clearinghouse may participate in this phase, and such owners may register domain names that consist of an identical match to their listed trademarks. If multiple qualified parties express an interest in registering the same domain name, Charleston Road Registry will award the domain name on a strictly first-come, first-served basis. At the end of the sunrise phase, at a minimum, Charleston Road Registry will follow ICANN rules for subsequent attributions of trademarked second-level domains and will offer other protections for trademark owners, including but not limited to an extended Trademark Claims Service of indefinite length. 

Phase 2 - The second phase will be a four-week open registration phase. During this phase, any interested applicant may apply for all second-level domain names not previously registered in the sunrise period. Trademarked terms will be subject to the Rights Protection Mechanisms set forth in Response 29. At the end of the second phase, if multiple parties have expressed an interest in registering the same second-level domain name, Charleston Road Registry will award the domain name through an auction to the highest bidder.

Phase 3 - The third phase will be a steady state phase for the duration of registry operation. During this phase, any interested applicant may apply for all second-level domain names not previously registered in an earlier phase. Trademarked terms will be subject to the Rights Protection Mechanisms set forth in Response 29. If multiple parties express an interest in registering the same domain name, Charleston Road Registry will award the domain name on a strictly first-come, first-served basis.

18.c.ii
While Charleston Road Registry reserves the right to charge different prices for unique second-level domains within the gTLD, once Charleston Road Registry determines the price for a particular second-level domain, Charleston Road Registry will not price discriminate among ICANN-accredited registrars. Charleston Road Registry does not intend but reserves the right to offer introductory discounts and bulk registration discounts. Volume discounts, marketing support and incentive programs may be made available, and if so will be offered to all ICANN-accredited registrars without preference.

18.c.iii
Pursuant to the ICANN-Registry Operator Agreement, Charleston Road Registry will provide written notice a minimum of 30 days prior to any increases in price for initial registrations, as well as written notice 180 days prior to any increase in registration renewals. Further, Charleston Road Registry will offer uniform pricing for renewals as specified in the ICANN-Registry Operator Agreement.

Charleston Road Registry does not currently intend to make contractual commitments to registrants regarding the magnitude of price escalation. Charleston Road Registry does, however, intend to keep its practices competitive and aligned to activity in the marketplace.

No

Not Available

No

As specified throughout this application, Charleston Road Registry (CRR) plans to implement comprehensive anti-abuse mechanisms. CRR will protect against the abusive registration of geographic names at the second and other levels in the applied-for gTLD by reserving to the registry protected geographic names in order to prevent registration of such strings.

In that regard, CRR has thoroughly reviewed Specification 5 of the Registry Agreement, the Government Advisory Committee’s (GAC) “Principles Regarding New gTLDs”, and the .info methodology for reservation and release of country names. Accordingly, CRR will, in connection with its registry services operator and registrar, initially reserve from registration by any party names with national or geographic significance within the TLD during the TLD’s Sunrise Period and Trademark Claims Period.

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

(1) 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;
(2) 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
(3) 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.

As noted above, the top-level domain shall not permit the public to register domain names with national or geographic significant at the second-level. The names will be set aside by use of the Reserved state making them inaccessible (See response to Question 27 for details). Google, as the registry services provider, has arranged for such reservation to occur prior to the launch of the TLD.

In the event there is a compelling use of a two-character geographic name, the two-character label string may be released to the extent that CRR reaches agreement with the government and country-code manager and consults with the GAC and ICANN. The Registry may also propose the future release of these reserved names based on the implementation by the prospective registrant of measures to avoid confusion with the corresponding country codes.

As with the .info TLD, only if a potential second-level domain registrant makes a proper showing of governmental support for country or territorial names will CRR relay this request to ICANN. CRR also plans to consult with the GAC and of ICANN before proceeding to delegate the domain at issue.

Charleston Road Registry (CRR) will outsource the entirety of its technical operations to Google. In addition to running the technical platform, Google will provide CRR with staffing and support to ensure that all registry services meet both the requirements laid out by ICANN in the new generic top-level domain (gTLD) Applicant Guidebook as well as in the gTLD registry agreement. Additional details of Google’s provision of services to CRR are set forth in Question 31, Section 31.1.

By making use of Google’s Registry platform, CRR will provide the following registry services:

- Receipt of data from registrars concerning registration of domain names and name servers
- Dissemination of top-level domain (TLD) zone files
- Dissemination of contact or other information concerning domain name registrations (WHOIS service)
- Internationalized Domain Names (IDN) Support for all domain names
- Domain Name System Security Extensions (DNSSEC) support
- IPv6 Support
- Data escrow
- Redemption grace period for domain names
- Registrar and developer account creation

“Q23_Registry Services Diagram” shows major services being exposed by high-level systems. Note that this diagram shows only data flow and does not specify the physical deployment characteristics of these services.

Details on these services are discussed below.

23.1. Receipt of Registration Data

Google will receive registration data from users in a manner consistent with standard registry operations. This will be handled via the extensible provisioning protocol (EPP) interface through ICANN-accredited third-party registrars. Google will operate a robust Shared Registration Service (SRS) that allows registrars to add, modify, and delete domain registrations and provides full support for the domain registration lifecycle.

Google’s shared registration system (SRS) infrastructure consists of three major components: an extensible provisioning protocol (EPP) server that provides an EPP interface to registrars; the Google SRS Frontend, which provides web-based access to the state of the Google Registry, the registrar’s profile and access to registration reports for the registrar; and the Google SRS Backend, which implements most business logic, interacts with the data store, and pushes updates to DNS and WHOIS servers in order to disseminate TLD Zone files as well as registrant contact information.

Details of the SRS are described in Question 24, EPP support in Question 25, and the registration lifecycle in Question 27.

23.2. Dissemination of TLD Zone Files

TLD zone data will be propagated in near real time to Google’s Authoritative DNS infrastructure, which will serve as the primary means of publication of the TLD zone files. This DNS infrastructure is based on Google’s existing Public DNS product, which handles over 70 billion queries per day. This DNS implementation will be fully compliant with RFCs 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 3901, 4343, 4472, 4972, and 5966 as well as ICANN’s Specification 10. A full description of Google’s Authoritative DNS infrastructure is described in Question 35.

In addition to real-time publication via port 53, the Google Registry will also support publication of the entire zone, as described below:

The master zone file will be internally generated and cached in the Google Shared Registration System (GSRS) as modifications to GSRS’s persistent store are made. The zone data will be signed by the Authoritative DNS infrastructure; a copy of the signed data is also returned to the GSRS. The entire master zone file will then be available to authorized parties at an HTTP URL shared with them over the web.

The master zone file at this location will be guaranteed to be no more than one hour old.

When retrieving the zone file, the client will pass a single HTTP request parameter (“key”), in order to identify individually the qualified client requesting access. This parameter will be the API key given to the registrar during account signup.

The mimetype “text⁄dns” will be set on the HTTP response and the content encoding will be gzip.

The master zone file will follow the format specified by RFC 1035, with the additional restrictions as specified in Specification 4, Section 2.1.4 of the gTLD Applicant Guidebook. DNSSEC resource records will also be present.

In addition, the master zone file will be made available through the Centralized Zone Data Access Provider as specified in Specification 4, Section 2.1.4 of the gTLD Applicant Guidebook.

23.3. Dissemination of Contact Information (WHOIS)

Google will create an implementation of the WHOIS protocol (as defined by RFC 3912) that will listen on port 43 for WHOIS requests. Googleʹs WHOIS service will communicate to the name registry through a private API end-point in order to retrieve the necessary information for WHOIS responses. In addition, Google will operate a public WHOIS, web-based Directory Service at 〈WHOIS.nic.mba〉 providing free, public query-based access. Both traditional WHOIS and web-based WHOIS will be made available over both IPv4 and IPv6.

As required by Specification 4 in the gTLD Applicant Guidebook, Googleʹs WHOIS service will perform in the following manner:
- Semi-free text format followed by a blank line and disclaimer specifying the rights of the Registry Operator, and user querying the database.
- Each data object shall be represented as a set of key⁄value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value.
- For fields where more than one value exists, multiple key⁄value pairs with the same key shall be allowed.
- The first key⁄value pair after a new-line starts a new record, and is used to identify the record itself.
- The format of fields governed by EPP RFCs 5730-5734 (domain status, individual and organizational names, address, street, city, state⁄province, postal code, country, telephone and fax numbers, email addresses, date and times) will be formatted as specified by those RFCs.

Updates to WHOIS data will be made in near real-time, with the registry’s service level agreement (SLA) committing to 95% of the updates reaching the serving infrastructure within 15 minutes. Details of WHOIS support are included in Question 26.

23.4. Internationalized Domain Names

IDNs allow registrars to register domain names with unicode code points representing non-ASCII-based character sets. IDNs constrained by the IDN Tables for this TLD will be supported by the Google Registry. Google’s IDN implementation will make use of the IDNA standard and be fully compliant with both RFCs 5890-5893 and ICANN’s IDN implementation guidelines. For more information on the IDN implementation for the TLD, see Question 44.

23.5. DNS Security Extensions

The Google Registry will support DNSSEC. In particular, registrants will be able to specify a DS record as part of normal domain name registration with their registrars, which will be transmitted to the Google Registry via its EPP interface. The Google Registry will then sign the DS record, along with all other DNS resource records in the TLD Zone, forming a chain of trust between the Google Registry and second-level domain name. The Google Registry itself will publish its own DS record with the root. Google’s DNSSEC implementation will be fully compliant with RFCs 4033, 4034, 4035, 5910, 4509, 4641, and 5155. More information on this topic, including the DNSSEC Policy statement for the TLD is contained in Question 43.

23.6. IPv6 Support

The Google Registry operates on Google’s production network, which supports IPv6. Specifically, the Google Registry will specifically support IPv6 access to all registry service endpoints (WHOIS, EPP, DNS, etc.). All services are provided through dual-stack, which is considered the industry-standard best practice for supporting IPv6. In addition, domain name registrants will be able to create IPv6 AAAA glue records for nameservers in the TLD zone. Further detail about Google’s IPv6 implementation is available in Question 36.

23.7. Data Escrow

Google will escrow relevant registration data, as required by ICANN’s registry agreement. Google will ensure that its data escrow will be fully ICANN compliant and performed in accordance to industry best practices. In addition to Google’s practice of hosting critical data on redundant and geographically disparate datacenters, data escrow will provide further assurance against data loss and ensure that all Google Registry data can be retrieved in a timely manner. For more information on Data Escrow, see Question 38.

23.8. Redemption Grace Period for Domain Names

After a domain name has been deleted by a registrar, the domain name shall move into a Redemption Grace Period. The status of the domain will be listed as PENDING DELETE RESTORABLE. When a domain is in this state, it is deleted from the zone for the TLD. This is a strong indicator to the registrant that it must act take action in order to restore the domain to its previous state. For details, see Question 27.

23.9. Creation of Registrar and Developer Accounts

Google’s Registry will use Google Accounts to manage registrars.

To create a Google Account, all parties will be directed to the following URL:

 http:⁄⁄www.google.com⁄accounts

Once a prospective registrar or developer has created an account in Google, the registrar or developer can upgrade from a standard Google account to a registrar and⁄or developer, if certain requirements are met.

To obtain a set of credentials used to interact with the Google Registry, a registrar will proceed through the following workflow:
A. The Google registrar logs in with Google account credentials.
B. The Google registrar submits an application identifying that it is an accredited ICANN registrar, and that it wishes to interact with the Google Registry. 
C. The Google registrar requests and resets initial EPP credentials, which are separate from a Google account.

Once a Registrar has been certified and authorized for billing, they will be ready to interact with Google through Google EPP. At this point, the registrar can also view reports on domains registered, EPP transactions, remaining account balance, and other TLD registry statistics.

“Q23_Registrar Registration Process Diagram” shows the registration process for registrars.

In addition to registrars, Google will also provide accounts to developers and other authorized users, who will obtain credentials through the following workflow:
A. The developer logs in the previously created Google account.
B. The developer requests an API key to be used for all public API calls.
C. The developer reviews access restrictions, quota, and service-level agreements and agrees to appropriate terms.
D. Google Registry grants access to zone data exported by the domain.

“Q23_Developer Registration Process Diagram” shows the registration process for developers.

All Shared Registration System (SRS) services described in Question 23 will run on Google’s robust, high-performance platform. Google’s production platform is an extremely high-capacity, high-availability, scalable platform designed to support some of the most resource-intensive and often-used applications on the Internet, including Google Search, Gmail, and YouTube. Google builds large clusters out of thousands of individual servers. Google uses a common set of tools to allocate resources, provide access to basic services such as storage and locking, and to simplify programmers’ ability to build distributed systems using the cluster’s hardware. Rather than relying on expensive hardware to provide reliability, Google uses a more cost effective approach based on commodity components, and builds fault tolerance into its software. Google simultaneously increases performance, reliability, and scalability of our production systems by splitting work into shards and running multiple replicas of the same process. 

The numbered sections below discuss details of our SRS implementation and capacity plans.

24.1. Google SRS (GSRS)

The Google Shared Registration System (GSRS) will provide all standard registry services:

- Receipt of data from registrars concerning registration of domain names and name servers
- Dissemination of top-level domain (TLD) zone files
- Dissemination of contact or other information concerning domain name registrations (WHOIS service)
- Internationalized Domain Names Support for all domain names
- Domain Name System Security Extensions (DNSSEC) support
- IPv6 Support
- Data Escrow

For descriptions and details of all SRS functions, see Question 23.

24.2. Google SRS Components

GSRS will be a multi-tier application that consists of the following components.

- Google SRS Front End (GSRS-FE): Presentation. A web application which provides an interface between registrars, developers, and other parties that need access to Google Registry information through a web interface. GSRS-FE will also include a web-based WHOIS interface. 
- Google SRS Back End (GSRS-BE): Business Logic. A representational state transfer (RESTful) service that exposes and controls all registry data. Most business logic related to registry data storage and persistence will be implemented in GSRS-BE.
- Google EPP (GEPP): API Proxy. A public end-point for EPP (Extensible Provisioning Protocol) for the top-level domain. GEPP will translate all EPP requests and responses to interface with GSRS-BE. For more information on EPP support, see Question 25.
- Google WHOIS (GWHO): A public end-point for WHOIS queries for the top-level domain. GWHO will translate all WHOIS requests and responses to interface with the GSRS-BE. For more information on WHOIS support, see Question 26.

In addition, GSRS will integrate with the following internal systems. These internal systems are designed for extremely high performance and robustness, and use the same technologies used for other high-capacity services currently in production.

- Google Persistence Service (Persistence): A multi-master persistence solution which will run on top of Google’s proprietary database, BigTable. The Google Persistence Service coordinates between masters using an algorithm for fault-tolerant distributed systems, such as Paxos. BigTable is Google’s internal implementation of a distributed hash table used for the majority of our persistence needs.
- Google Accounts (Authentication): An existing platform for creation and authentication of user accounts. Google Accounts provides a standard login page for all Google products, as well as programmatic access for internal applications to retrieve credentials for the logged-in user.
- Google Monetization (Billing, as needed for the TLD): A monetization and billing system. Enables Google products to create accounts, create invoices, and perform financial transactions for Google customers.
- Google Authoritative DNS (Master Zone File): A robust public DNS server. Google Authoritative DNS will receive master zone file information from the GSRS-BE and distribute DNS information to clients.

“Q24_SRS Services Diagram” shows the interactions with these systems as requests come into a Google datacenter and are handled appropriately. Note that, as shown in “Q24_SRS Services Diagram”, all SRS requests are passed to the GSRS-BE, which contains all business logic for Google Registry. Integrated services are then used as needed. Google plans to provision these services to handle significantly greater load than our most aggressive expectations -- see below for details.

24.3. Google SRS Deployment Parameters

Google plans to deploy GSRS in five geographically-distributed datacenters throughout North America. Traffic to these datacenters is dynamically adjusted according to load, and the system will be provisioned to allow two simultaneous datacenter outages without substantial performance impact.

Each datacenter will include several replicas to handle specific machine failures for any GSRS service. Google’s production servers include the ability to expand to add new servers dynamically according to need. If SRS performance suddenly requires additional throughput capacity -- for instance, during a Distributed Denial of Service (DDoS) attack -- Google will be able to enable up to 100 additional replica servers in any datacenter dynamically. The limit of 100 additional replica machines is a self-imposed limit and may be revised upward based on ongoing operational considerations. 

Each machine will be able to support a minimum of 250 queries per second (read or write), where one query contains one record. For architectural simplicity, our initial implementation will read data without any additional SRS-level caches.

24.4. GSRS Performance Scaling

Google plans to deploy sufficient capacity to handle SRS request load on the same scale as the largest top-level domains on the Internet. These computations are detailed in “Q24_GSRS Performance and Scaling”.

The key factor for scaling GSRS performance capacity will be the GSRS-BE component. Other components for GSRS (both GSRS-FE and GEPP) will receive user requests and then transform them into Remote Procedure Call (RPC) calls to GSRS-BE. GSRS-FE and GEPP will not perform any CPU-, disk-, or memory-intensive computations themselves. The performance capacity estimations below will therefore discuss only GSRS-BE capacity.

Based on existing domains and calculations for inbound traffic, Google estimates that there will be about 2300 queries per second for EPP operations, consisting mostly of checks for existing domains, and 3600 queries per second for WHOIS operations. In total, Google estimates that GEPP-BE must handle roughly 5900 queries per second for a scale of 100 million domains. Other operations, such as zone file operations and developer API calls, will create a relatively negligible level of load. 

Google will meet the SRS throughput requirement, with a 50% utilization rate, with 48 machines allocated across the five datacenters. At this level of utilization, our active capacity will be double the expected throughput requirement. If a datacenter is lost through a production outage or change request, then additional machines will be enabled immediately to take upon the additional load with no manual intervention required. Google production systems have the standard capability to enable new machines to handle increased capacity needs immediately.

These estimations do not include any smart caching anywhere in the architecture. If the Google Registry reaches a very large number of domains and additional capacity measures are required, Google will consider a design for an appropriate WHOIS and EPP check result caching plan to relieve load and to improve latency characteristics.

These estimates use a very aggressive set of assumptions for scaling, which should be sufficient for a large open domain.

24.5. GSRS Network Scaling

Google expects that our SRS network bandwidth requirements will be greatly below Google’s existing per-datacenter network capacity, even for its lowest-capacity datacenters in production. Details of its computations are included below.

Google assumes that 99% of RPC calls across both EPP and WHOIS will be less than 5 kB. EPP and WHOIS queries return more of a fixed number of records, and most queries will return only one record. 5 kB is derived as an estimate from taking the sample WHOIS output in the applicant guidebook, and multiplying it by three to account for XML inflation as if the same information passed through an EPP interface. Considering that most EPP commands are expected to be 〈check〉 commands, this is a very conservative estimate.

Google then uses 5 kB as the assumed size to calculate the estimates for bandwidth per machine and per datacenter at maximum load.

Network Bandwidth Requirements per Machine = Queries per Second * Size of RPC Calls

With 250 qps and 5 kB per query, Google expect a maximum of about 12.5 MB⁄s of bandwidth requirement. This is about one-eighth of our current absolute minimum commodity standard of 1 Gb Ethernet. Our backbone routers connect many metro networks around the globe at 10Gb or greater.

Network Bandwidth Requirement per datacenter = Requirements per Machine * Number of Machines

With 12.5 MB⁄s of bandwidth per machine, and 100 machines maximum per datacenter, Google expects a maximum of about 1.25 GB⁄s data requirements during a major event that requires increased load demand. All Google datacenters’ connections to its production network have a multiple 10 GB⁄s links, and many exceed this by far.

Based on these computations, Google believes that the network bandwidth required by the SRS system for as many as 100 million second-level domains will never exceed the capacity that even our smallest datacenter can provide.

24.6. Multi-Master Design

GSRS will use a multi-master architecture. This architecture is detailed further in Question 32. Machines across multiple datacenters will serve active traffic, with no machines on cold or hot standby. All instances of the data store update in real-time, and updates to registry data are committed across a quorum of replicas before the write is confirmed. When GSRS or a dependent service goes down or is drained by an outage, Google’s network architecture will redirect all affected traffic to another datacenter. Google will design most services as stateless, so service instances will not require any coordination mechanisms.

24.7 Google SRS Adherence to Specification 6

The Google Registry, and in particular the SRS will be compliant with all RFCs outlined in Specification 6. Any RFCs mentioned below and their successors will be complied with.

24.7.1 - Standards Compliance

24.7.1.1 DNS

Google’s domain name system (DNS) implementation will comply with RFCs 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 4343, and 5966. See Question 35 for more details on DNS RFC implementation compliance.

24.7.1.2 EPP

Google’s EPP implementation will comply with RFCs 5910, 5730, 5731, 5732, 5733, 5734, 3915, and 3735 for any extensions developed. Please see Question 25 for more details on EPP RFC implementation compliance.

24.7.1.3 DNSSEC

Google’s DNSSEC implementation will comply with RFCs 4033, 4034, 4035, 4509, 5155, and the best practices indicated in RFC 4641. A DPS statement will be published for each TLD supported by the Google Registry. Please see Question 43 for more details on DNSSEC implementation compliance.

24.7.1.4 IDN

Google’s implementation of internationalized domain names (IDN) will comply with RFCs 5890, 5891, 5892, 5893 and ICANN’s published IDN Guidelines. Please see Question 44 for more details on IDN RFC implementation compliance.

24.7.1.5 IPv6

Google’s implementation of IPv6 will follow BCP 91 and RFCs 4472. All Registry services will be offered over IPv6. Please see Question 36 for more details on Google’s IPv6 implementation.

24.7.2 Registry Services and Wildcard Prohibition

Google understands the definition of “registry services” as defined in section 2.1 of Specification 6. Google will not support wildcard matching or resolution in the TLD zone as required by Section 2.2 of Specification 6.

24.7.3 Registry Continuity

Google will ensure registry continuity as specified in Section 3 of Specification 6. High availability, extraordinary event handling, and business continuity will be provided with respect to the TLD. See Question 39 for more details on Google’s Registry continuity plan.

24.7.4 Abuse Mitigation

Google will implement the abuse mitigation requirements as specified in Section 4 of Specification 6. An abuse contact will be made available. See Question 28 for more details on Google’s abuse handling. Google will also take action to remove malicious use of orphan glue records when provided evidence in written form that such records are present in connection with malicious content.

24.7.5 Supported Initial and Renewal Registration Periods

Google will implement the supported initial and renewal registration periods as specified in Section 5 of Specification 6. The Google Registry will support domain name registration with validity periods of between one to 10 years in increments of one year. Renewal registration may extend registration to a maximum of 10 years from renewal date in increments of one year.

24.8. Google SRS SLA and Adherence to Specification 10

The Google SRS will significantly exceed the requirements of the Service Level Requirement Matrix defined in Specification 10 in the gTLD Applicant Guidebook. All EPP and WHOIS⁄RDDS calls supported by the Google SRS system will have a 99.9% monthly uptime.

For the purpose of measuring this commitment, Google uses the following definitions:
RPC: A series of TCP⁄IP packets forming a distinct request, and the corresponding TCP⁄IP packets forming the response.
Error RPC: An RPC which does not return with 3x 95th percentile latency, or which fails because of internal transient errors.
Error Minute: Any minute during which 10% of RPC requests are error RPCs.
Monthly Uptime: The total number of minutes in a month minus the number of error minutes divided over the total number of minutes in the month, rounded to the nearest .01%. 

When calculating monthly uptime percentage, Google does not distinguish between scheduled and unscheduled downtime. 

Google will meet or exceed all service level agreements (SLA) described in the ICANN Applicant Guidebook. Specifically, Google will meet the commitments as specified in attachment “Q24_SLAs”. Note that the values represent a commitment to exceed SLA Requirements in Specification 10.

DNS
- DNS Availability: 0 minutes of downtime.
- DNS Name Server Availability: Less than 31 minutes of downtime per month (At least 99.93% availability)
- TCP DNS resolution RTT: 300ms for at least 95% of the queries
- UDP DNS resolution RTT: 300ms for at least 95% of the queries
- DNS update time: 15 min, for at least 95% of the probes

RDDS (WHOIS)
- RDDS Availability: Less than 43 minutes of downtime per month. (At least 99.9% availability)
- RDDS Query RTT: Less than 400 ms.
- RDDS Update Time: Less than 15 minutes for 95% of probes.

EPP
- EPP Service Availability: Less than 43 minutes of downtime per month. (At least 99.9% availability)
- EPP Session-Command RTT: Less than 1000 ms for at least 95% of commands.
- EPP Query-Command RTT: Less than 400 ms for at least 95% of commands.
- EPP Transform-Command RTT: Less than 800 ms for at least 95% of commands.

Downtime values are on a monthly basis. 

Google has the track record to deliver SRS to 99.9% availability. Google is confident in its ability to meet these SLAs for SRS because of its experience with engineering highly-available platforms. As discussed by Urs Hoelzle, Senior Vice President of Technical Architecture, Google has designed its major services to obtain 99.99% reliability [1].

24.9. SRS Technical Support

Charleston Road Registry will provide registrars with access to telephone, email, and web chat support, and will escalate issues to the Google technical team as technical faults are identified. For a further elaboration of the escalation process, see Question 42.

Google will notify ICANN and registrars, at least 24 hours beforehand, of maintenance for all planned outages and maintenance which will directly, significantly, and visibly affect users of the SRS.

24.10. Resourcing Plans

Google will implement these technical requirements using the teams and resources discussed below.

The cost of these services will generally be set at reasonable market rates per agreement between Charleston Road Registry and Google. The expected costs are discussed in Questions 46 and 47.

All services that GSRS will depend on are already well-provisioned and ready to assume the additional load of the Google SRS, including up to 100 million second-level domains, which is well in excess of expected need. The load that GSRS will generate for existing systems will be significantly less than the capacity already designated as part of normal growth for Google and the company’s need for high-performance hardware and support personnel resources.

24.10.1. Registry Team

The Google Registry Team will be responsible for designing and implementing our SRS, EPP, and WHOIS systems, including IDNs. They will also be responsible for creating tests and monitoring for these systems.

During initial implementation, this team will consist of at least four to seven software engineers responsible for implementing the project. Additionally, Google plans to staff one software engineer who is responsible for engineering testing and monitoring for the Google Registry, and one software engineer who is responsible for backup, restoration and escrow. In total, Google plans to implement the Google Registry with a team of six to nine software engineers.

After the Google Registry is complete, Google expects to staff a team to support the ongoing operation of the registry. This team will consist of at least four engineers who will participate in on-call rotation, respond to alerts, provide support to ICANN and registrars for emergency escalations, and maintain responsibility for bug fixes and improvements. This team will continue maintenance throughout the life of the registry.

This team’s responsibilities will generally be limited to registry-specific components. The Google Registry Team will work closely with other relevant teams, including the Authoritative DNS support team, Storage Site Reliability Engineering team, network engineering and operations, and customer support teams. These other teams are described in more detail in Question 31 (Section 31.16) as well as the relevant sections throughout this application.

24.11. Summary and Key Insights

Google has an existing production infrastructure that can exceed the performance requirements of the SRS platform:
- Google has a global network of datacenters to provide the scalability to meet the performance requirements of SRS.
- Google has a multi-master high availability strategy to meet the reliability requirements of SRS.
- Google has the proven operational processes and personnel to support the requirements going forward.
- The use of Google’s platform allows Charleston Road Registry to commit to service levels that substantially exceed the ICANN requirements in Specification 10.

24.12. Footnotes

[1] New York Times, “99.999% Reliable? Don’t Hold Your Breath”. http:⁄⁄www.nytimes.com⁄2011⁄01⁄09⁄business⁄09digi.html

The primary purpose of Google EPP will be to provide for a provisioning interface to the Google Registry using the standardized EPP protocol. 

Google has no initial plans to provide a software development kit, since there already are a variety of open- and closed-source EPP client implementations available on the web today.

Google’s EPP service will act as a connector between EPP clients and Google’s backend systems, which will handle business logic for registry operations.

25.1. RFC Compliance

Google’s EPP interface will handle the follow tasks:

- Listen for EPP connections over port 700.
- Support and maintain the EPP session through the life of the connection.
- Translate EPP requests and responses between equivalent requests and responses exposed by the Google SRS Backend private API.
- Terminate the Transport Security Layer (TLS) connection as defined by RFC 5734. TLS client certificates will be self-certified and transmitted to Google via the registrar application process. The credentials in the certificate will be matched against the account identified by the EPP username and password.

Google EPP will support a well-defined set of EPP RFCs with no additional EPP extensions.

25.1.1. Core Protocol - RFC 5730 (http:⁄⁄tools.ietf.org⁄html⁄rfc5730)

RFC 5730 defines EPP, a simple object provisioning XML protocol. The base protocol itself is agnostic to the type of objects being provisioned and allows for extensions to the protocol.

Upon connection, a session is established with a 〈greeting〉 message from the server as defined by the RFC. From there, the client will login with a 〈login〉 command, then entertain a series of request and response cycles, and then finally ends the session with a 〈logout〉 command. 

All EPP commands will be supported according to the RFC in their standard command and response formats.

As part of the 〈greeting〉, a 〈dcp〉 element is presented indicating Google’s data-collection-policy for the Registry. In general, the 〈dcp〉 element will attempt to mirror (as far as the protocol can mirror) Google’s Privacy Policy as stated in http:⁄⁄www.google.com⁄policies⁄privacy⁄. A copy of our full Privacy Policy as of March 1, 2012, is also included in Question 31 as an attachment.

For all commands, only objects defined by RFCs 5731 (domains), 5732 (hosts), and 5733 (contacts) will be supported. No other extensions will be used.

For the 〈login〉 command, the following policy specifics will be implemented:
- A maximum of three failed login attempts per connection
- On the 12th failed login attempt, the account will be locked out and require support to reactivate.
- Changing the EPP password with the optional 〈newPW〉 element will not be supported. Password changes will instead be handled through the password change interface on the Google SRS Front End. Error code 2501, ʺAuthentication error; server closing connectionʺ will always be returned if this command is used. 
- The 〈version〉 element must be set to 1.0.
- The 〈lang〉 element must be set to “en”. 

For all other EPP commands there will be no implementation policy specifics.

Standard behavior as defined by the RFC for each command is expected:
- 〈check〉: Determine if an object can be provisioned within the registry
- 〈info〉: Retrieve information associated with a given object
- 〈poll〉: Discover and retrieve service messages by a server for individual clients
- 〈create〉: Create an instance of an object
- 〈delete〉: Remove an instance of an existing object
- 〈renew〉: Extend the validity of an existing object
- 〈transfer〉: Determine real-time status of pending and completed transfer requests
- 〈transfer op=”request”〉: Request that an object be transferred
- 〈transfer op=”approve”〉: Approve a transfer request
- 〈transfer op=”reject”〉: Reject a transfer request
- 〈transfer op=”cancel”〉: Cancel a transfer request
- 〈update〉: Update the information in an existing object

25.1.2. Domain Objects - RFC 5731 (http:⁄⁄tools.ietf.org⁄html⁄rfc5731)

RFC 5731 defines support for domain objects over the EPP protocol.

Since RFC 5732 will be supported as well, domain objects will not be able to specify attributes to describe a name server host machine, but rather must reference the relevant host with 〈domain:hostObj〉 references.

When 〈domain:authInfo〉 is used, a 〈domain:pw〉 must be passed within to denote the password for the domain (or registrant using the “roid” attribute to denote this), or a 〈domain:null〉 to null it out.

For EPP commands dealing with domain object validity, domains will be by default valid indefinitely unless otherwise specified.

A 2305 error response code will be issued if there are dependent children subordinate to the domain, which still exist in the repository if a 〈delete〉 command is issued.

For all domains which require additional vetting of the registrant because of gTLD registration policy reasons, offline review of the domain may occur for transformation EPP commands. Otherwise, no offline review will occur in general.

25.1.3. Host Objects - RFC 5732 (http:⁄⁄tools.ietf.org⁄html⁄rfc5732)

RFC 5732 provides EPP mappings for host objects. This RFC will be supported in its entirety. There are no special considerations needed for the Google Registry.

There will be no offline review before provisioning of any host.

25.1.4. Contact Objects - RFC 5733 (http:⁄⁄tools.ietf.org⁄html⁄rfc5733)

This RFC provides EPP mapping for contact objects. This RFC will be supported in its entirety.

As specified by the RFC, unless prohibited by the server’s stated data collection policy, per-field disclosure policies will be supported via the 〈contact:disclose〉 element when provisioning contacts.
 
There will be no offline review before provisioning of any contact.

25.1.5. EPP Transport over TCP - RFC 5734 (http:⁄⁄tools.ietf.org⁄html⁄rfc5734)

RFC 5734 defines connection handling procedures regarding the EPP mechanism. 

The following policy is adopted from suggestions from this RFC:
-There will be no more than ten concurrent TCP connections from a single source destination IP without first contacting Google to establish an alternate upper limit.
- If a well-formed EPP request is not received at least every 30 seconds, the TCP⁄IP connection may be severed.
- TLS is mandatory to connect to Google EPP.
- A single TLS client certificate will be required for each EPP user and password pair. Multiple user⁄password pairs will not be permitted for a single TLS client certificate.
- A Certificate Name (CN) and subject AltName:dnsName will be set to the hostname of GEPP to be validated against by the client.

25.1.6. DS records - RFC 5910 (http:⁄⁄tools.ietf.org⁄html⁄rfc5910)

RFC 5910 governs the additions to the EPP domain mapping RFC for provisioning DS records for a particular domain. Of the two possible supported mechanisms by the RFC, Google EPP will support the ʺDS Data Interfaceʺ, where the client is responsible for the creation of the DS information and is required to pass DS information when performing adds and removes.

Other particular implementation specifics include:
- The optional 〈secDNS:maxSigLife〉 element will not be initially supported, and a 2102 error code will be returned.
- 〈secDNS:update〉 with an attribute of urgent will not be initially supported, and a 2102 error code will be returned if present.

25.1.7. Grace periods - RFC 3915 (http:⁄⁄tools.ietf.org⁄html⁄rfc3915)

RFC 3915 extends the EPP RFCs to account for grace period functionality. Grace periods allow for actions to be reversed or revoked within a specified period of time. In particular, this RFC governs four grace periods: add grace period, auto renew grace period, renew grace period and transfer grace period. Google will comply with this RFC in its entirety.

25.1.8. IDN RFCs

In addition to RFCs directly related to EPP, RFCs defining internationalized domain names (IDN) (5890, 5891, 5892, and 5893) and how they are specified will be implemented for Google EPP. In particular, IDNs will be specified using punycode and in the subset of unicode character code points dictated by the IDN tables attached to this gTLD application.

25.2. EPP Extensions

Beyond RFC 5910 which extends EPP to support DNSSEC DS records, no additional EPP extensions will be implemented or supported.

25.3. Google EPP Testing

Google will develop Google EPP using a software methodology, which ensures correct functionality by concurrently developing unit and large functional tests alongside the production code itself. Standard XML parsing libraries will be used depending on the implementation language. Implementation will also include monitoring rules that test EPP workflows in production on an ongoing basis. Before deploying to production, Google will create staging environments during development for internal manual and automated testing.

25.4. Operational Testing and Evaluation for Registrars

All ICANN-accredited registrars must first complete operational testing and evaluation (OT&E) before submitting EPP commands through the production Google EPP environment. The aim of this testing is to ensure that registrars are functioning properly.

OT&E instructions will be presented to the registrar after it has created a registrar account with the Google Registry. In general, these instructions will include a series of ordered EPP commands the registrar must perform along with test account credentials.

The registrar, once the registrar is ready for certification, it will request a Google Registry Front End evaluation. The test environment will reset to a nominal state, and at this point, the registrar must execute the series of ordered EPP commands within a specified amount of time. If registrar fails OT&E, the registrar will be notified of the failure, and can try again at a later date. If the registrar passes OT&E, the registrar will be notified, and be given production EPP credentials.

25.5. Resourcing Plans

Google Inc. will implement these technical requirements using the teams and resources discussed below.

The cost of these services will generally be set at reasonable market rates per agreement between Charleston Road Registry and Google. The expected costs are discussed in Questions 46 and 47.

25.5.1. Registry Team

The Registry Team will be responsible for designing and implementing the shared registration system (SRS), EPP, and WHOIS systems, including IDNs. They will also be responsible for creating tests and monitoring for these systems.

During initial implementation, this team will consist of at least four to seven software engineers responsible for implementing the project. Additionally, Google plans to staff one software engineer who is responsible for engineering testing and monitoring for the registry, and one software engineer who is responsible for backup, restoration and escrow. In total, Google plans to implement the registry with a team of six to nine software engineers.

After the registry is complete, Google expects to staff a team to support the ongoing operation of the registry. This team will consist of at least four engineers who will participate in on-call rotation, respond to alerts, provide support to ICANN and registrars for emergency escalations, and maintain responsibility for bug fixes and improvements. This team will continue maintenance throughout the life of the registry.

This team’s responsibilities will generally be limited to registry-specific components. The Registry Team will work closely with other relevant teams, including the Authoritative DNS support team, Storage Site Reliability Engineering team, network engineering and operations, and customer support teams. These other teams are described in more detail in Question 31 (Section 31.16), as well as the relevant sections throughout this application.

25.6. Summary and Key Insights

Google can design, build and run EPP interface that meets the requirements of a gTLD registry because of:
- A thorough understanding of the requirements for the systems.
- A reuse of existing industry, standard EPP XML schemas to de-risk system implementation.
- A proven software development methodology that will verify implementation against requirements.
- Operational procedures that facilitate the ongoing maintenance of the platform and the support of onboarding of new registrars.

Google will implement and maintain a “thick” data model WHOIS service, in which the registry will store and serve contact information related to each domain name -- as opposed to a “thin” model, which provides a query referral to a registrar. 

Google will operate a public WHOIS service available via port 43 in accordance with RFC 3912, and a web-based Directory Service at 〈WHOIS.nic.mba〉 providing free, public query-based access. Both of these services will be made available over both IPv4 and IPv6.

Google’s WHOIS service on port 43 will comply with the WHOIS protocol as described in RFC 3912 by accepting an ASCII request (terminated with a 〈CR〉〈LF〉) and replying with an ASCII response, terminating the TCP connection once the output is finished. RFC 3912 does not contain further detail on the format of the response payload itself; the format will be as described in “SPECIFICATION 4: SPECIFICATION FOR REGISTRATION DATA PUBLICATION SERVICES”, Section 1, and relevant Best Practices.

If ICANN specifies alternative formats and protocols, Google will implement these as soon as reasonably practical and will implement IDN related WHOIS requirements as they evolve. As a matter of policy, Google WHOIS will not return IDN variants for WHOIS queries. Queries for specific domains must be made.

26.1 High-level overview of the WHOIS service.

The attachment “Q26_WHOIS Services Diagram” shows an overview diagram of WHOIS services, and other relevant aspects of Google’s network.

Step 1: Request.
When a request is received (via the web or “traditional” interface), the appropriate service will extract the query from the request and perform checks to combat abusive behavior (such as Denial of Service and “WHOIS scraping”). Google has extensive infrastructure that profiles requests and applies heuristics to determine if requests are legitimate or “scraping”, and we plan to use this infrastructure to limit abuse of the WHOIS service. This functionality is described in Question 30, Section 30.b.3.2.

The request will also increment a counter to allow for reporting of statistics.

Step 2: Lookup.

The service will then query the registry database service, using the GSRS backend API. As the WHOIS service will query the database for the response, Google will provide fresh answers, instead of extracting all of the data from the database and synchronizing the data between servers. In order to provide fast, accurate responses, and to act as the first line of defense against DoS attacks, the WHOIS service may cache the result and reply from cache on subsequent queries for a maximum of 15 minutes.

Step 3: Reply
Once a result, or an indication that the requested information does not exist, is received from the database it will be converted into the appropriate response format: HTML for web-based requests, or RFC 3912 style responses for port 43 requests.

Step 4: Response.
The result of the lookup will then be returned to the requester.

26.2. WHOIS Infrastructure

Google operates a fast, reliable, and redundant network, and has developed frameworks for encoding and making remote procedure calls (RPCs). This infrastructure can be leveraged to provide communication and connectivity with other registry systems.

Google has significant experience developing secure, stable, resilient, and high-performance applications that perform lookups against a datastore, and has built substantial infrastructure for running such applications and scaling them to meet demand.

As described in detail in the responses to Questions 31 and 32, the WHOIS service will be designed as a simple, stateless server that accepts user queries and transforms them into RPCs that will be serviced by the SRS backend server. This model allows additional capacity to be scaled in accordance with need simply by adding additional replicas of the WHOIS server, and means that the resource requirements to operate this layer of the service should be minimal. Google continuously monitors the load on production servers and systems and proactively upgrades and supplements systems before there is any degradation in service. The registry will be initially provisioned to support at least 100 million domain names, which substantially exceeds the expected load, but Google’s overall scale would allow the scope of the service to be increased substantially if required.

We estimate that each second-level domain will generate slightly more than 3 WHOIS queries per day. Based on our projections, this will result in an expected load of 3600 qps (queries per second) from WHOIS requests. Since each machine can handle 250 qps, and we plan for a 50% utilization rate, we expect to provision about 30 machines. For more details of our expected WHOIS load and performance capacity, see Question 24.

This infrastructure will also help Google meet and exceed the specified Service Level Agreements, including those in Section 10 of the Registry Agreement, as discussed in the response to Question 24. We plan to serve WHOIS queries with at least 99.9% availability, with less than 500 ms latency, and an update time of less than 15 minutes for 95% of updates.

26.3 WHOIS Synchronization

As mentioned in previous sections, all incoming RPCs to equivalent calls to the Google SRS Backend. This means that there is no synchronization between Google WHOIS and the SRS since Google WHOIS maintains no persistent state. However, as also previously mentioned, Google may deploy a cache in the WHOIS service to reduce load on the GSRS BE and database while reducing latency, creating a freshness delay of up to 15 minutes.

26.4. WHOIS Data and Request⁄Response Example

Google WHOIS will follow data formats specified in Specification 4 in the application guidebook. Here is an example WHOIS domain query and response.

Query::
EXAMPLE.mba

Response:
Domain Name: EXAMPLE.mba
Domain ID: D424242-mba
WHOIS Server: WHOIS.nic.mba
Updated Date: 2012-08-13T20:13:00Z
Creation Date: 2012-02-14T00:45:00Z
Registry Expiry Date: 2014-10-08T00:44:59Z
Sponsoring Registrar: EXAMPLE REGISTRAR LLC
Sponsoring Registrar IANA ID: 314159265
Domain Status: clientDeleteProhibited
Domain Status: clientRenewProhibited
Domain Status: clientTransferProhibited
Domain Status: serverUpdateProhibited
Registrant ID: 5372808-ERL
Registrant Name: EXAMPLE REGISTRANT
Registrant Organization: EXAMPLE ORGANIZATION
Registrant Street: 123 EXAMPLE STREET
Registrant City: ANYTOWN
Registrant State⁄Province: AP
Registrant Postal Code: A1A1A1
Registrant Country: EX
Registrant Phone: +1.5555551212
Registrant Phone Ext: 1234
Registrant Fax: +1.5555551213
Registrant Fax Ext: 4321
Registrant Email: EMAIL@EXAMPLE.mba
Admin ID: 5372809-ERL
Admin Name: EXAMPLE REGISTRANT ADMINISTRATIVE
Admin Organization: EXAMPLE REGISTRANT ORGANIZATION
Admin Street: 123 EXAMPLE STREET
Admin City: ANYTOWN
Admin State⁄Province: AP
Admin Postal Code: A1A1A1
Admin Country: EX
Admin Phone: +1.5555551212
Admin Phone Ext: 1234
Admin Fax: +1.5555551213
Admin Fax Ext:
Admin Email: EMAIL@EXAMPLE.mba
Tech ID: 5372811-ERL
Tech Name: EXAMPLE REGISTRAR TECHNICAL
Tech Organization: EXAMPLE REGISTRAR LLC
Tech Street: 123 EXAMPLE STREET
Tech City: ANYTOWN
Tech State⁄Province: AP
Tech Postal Code: A1A1A1
Tech Country: EX
Tech Phone: +1.1235551234
Tech Phone Ext: 1234
Tech Fax: +1.5555551213
Tech Fax Ext: 93
Tech Email: EMAIL@EXAMPLE.mba
Name Server: NS01.EXAMPLEREGISTRAR.mba
Name Server: NS02.EXAMPLEREGISTRAR.mba
DNSSEC: signedDelegation
DNSSEC: unsigned
〉〉〉 Last update of WHOIS database: 2012-08-13T20:15:00Z 〈〈〈

26.5 Bulk Registration Data Access to ICANN

The Google Registry will comply with Section 3 of Specification 4 in the application guidebook to provide ICANN bulk registration data access.

Data will be provided on a weekly basis. Data will include data committed as of 00:00:00 UTC on the day previous to the one designated for retrieval by ICANN.

The Google Registry will provide at a minimum all content requested in the specification: domain name, domain name repository, object id, registrar id, statuses, last updated date, creation date, expiration date, and name server names. For sponsoring registrars, the registry will provide: registrar name, registrar repository object id, hostname of registrar Whois server, and URL of registrar.

The format of the data will be provided as specified in Specification 2 for Data Escrow.

The Google Registry will have the file ready for download as of 00:00:00 UTC on the day designated for retrieval by ICANN. The file will be made available for download by SFTP with a hostname, username, and password provided to ICANN.

26.6. Resourcing

Google Inc. will implement these technical requirements using the teams and resources discussed below. 

The cost of these services will generally be set at reasonable market rates per agreement between Charleston Road Registry and Google. The expected costs are discussed in Questions 46 and 47.

26.6.1. Registry Team

Our Registry Team will be responsible for designing and implementing our SRS, EPP, and WHOIS systems, including IDNs. They will also be responsible for creating tests and monitoring for these systems.

During initial implementation, this team will consist of at least 4-7 software engineers responsible for implementing the project. Additionally, we plan to staff one software engineer who is responsible for engineering testing and monitoring for the registry, and one software engineer who is responsible for backup, restoration and escrow. In total, we plan to implement the registry with a team of 6-9 software engineers.

After the registry is complete, we expect to staff a team to support the ongoing operation of the registry. This team will consist of at least four engineers who will participate in on-call rotation, respond to alerts, provide support to ICANN and registrars for emergency escalations, and maintain responsibility for bug fixes and improvements. This team will continue maintenance throughout the life of the registry.

This team’s responsibilities will generally be limited to registry-specific components. The Registry Team will work closely with other relevant teams, including the Authoritative DNS support team, Storage Site Reliability Engineering team, network engineering and operations, and customer support teams. These other teams are described in more detail in Question 31 (Section 31.16), as well as the relevant sections throughout this application.

26.7. Summary and Key Insights

- Google will operate a thick WHOIS service with an interface on port 43 complying with RFC 3912 as well as a web-based query interface. These services will display data in accordance with Specification 4 of the registry agreement.
- Google’s WHOIS service offers a simple, stateless, scalable front end to the registry’s SRS-BE servers. The capacity of the service can be expanded simply by adding additional replica WHOIS servers. Google will initially scale the service to support a registry with 100 million domain names.

Charleston Road Registry (CRR) sets forth below a description of the various stages and states of a second-level domain (SLD) in its proposed registry system. Please see “Q27_Registry Life Cycle Diagram” for a graphical depiction of the domain registration lifecycle.

27.1. Life Cycle States
 
The following registration life cycle states are described in the sections below:
 
- Reserved
- Available
- Add Grace Period
- Registered
- Renew Grace Period
- Auto-Renew Grace Period
- Pending Restore
- Redemption Grace Period
- Pending Delete
- Pending Transfer
- Transfer Grace Period

State changes provide specific use cases to the DNS (Domain Name System) architecture explained in responses for Question 31 (Technical Overview), Question 32 (Architecture) and Question 35 (DNS Service). Note that this response makes references to EPP (Extensible Provisioning Protocol) functionality which is fully described in Question 25. Additionally, state changes may change the information retrievable via Registration Data Directory Services (RDDS, a combination of WHOIS and Web-based WHOIS) as described in Question 26.

27.2. Reserved

Reserved domains are not generally available to register. For example, such restrictions may result from agreements with ICANN⁄IANA for operational⁄technical reasons or with governments for geographic names. See response to Question 22 (Protection of Geographic Names) for further details. The registry will maintain a schedule of reserved words as per Specification 5 of the Registry Agreement. For a reserved domain, an EPP 〈check〉 query would return a value of avail=ʺ0ʺ, and there would be no entry in the zone file or RDDS associated with the domain name. EPP 〈create〉 requests will result in a rejection, except those that have prior approval from CRR. The registry foresees two cases as envisioned by Specification 5 of the New gTLD Agreement, particularly applicable to geographic names: 1) CRR releases an SLD for use by the applicable government or country-code manager. In this case, at the end of the registration, the SLD would return to the Reserved state. 2) CRR works with the affected government(s) or country-code manager(s) to permanently make available SLD(s). In this case, at the end of a reservation the string would revert to the Available state.

In addition to an explicit Reserved state, CRR will also support a functional equivalent to reserving through registration. This approach follows the practices of the .info registry. That is, CRR will reserve certain names by registering them for the registry, pursuant to Section 2.6 of the gTLD registry agreement. Names reserved using this approach follow the life cycle described below. Generally, CRR will use the state machine to control reservations but leaves open the possibility of using reservation by registration when more appropriate.

27.3. Available

If a second level domain (SLD) is not reserved, it is considered available if either of the following holds true:
- The SLD has not existed previously.
- The SLD has passed through the Pending Delete state.

Domains that are available do not exist in the zone file or RDDS. The Shared Registry System - Back End (SRS-BE) would return a value of avail=ʺ1ʺ when responding to the EPP 〈check〉 query for domain in the Available state.

All other states would return a value of avail=ʺ0ʺ.

27.4. Add Grace Period (AGP)

Names that are selected for registration are entered into the zone file at the start of this five-day add-grace period (〈addPeriod〉). Registrars are charged for submitting 〈create〉 requests to the registry.

The Google SRS-Backend (GSRS-BE) manages the 5-day grace period countdown, including the transition of the state to Registered. During the Add Grace Period, registrars can cancel the registration and receive a credit for the cost of the original registration (with domain names becoming immediately Available or Reserved, as appropriate), subject to ICANNʹs AGP Limits Policy. GSRS-BE will set the status of the Domain Name to 〈addPeriod〉 while making the zone file and RDDS updates, and then reset it when grace period ends.

27.5. Registered

Owners of domain names can register them for a period of one to ten years. The registrar may renew the SLD for no less than one and no more than ten years from the current day using the EPP 〈renew〉 command. GSRS-BE will manage state changes based on expiration date of domains, including updates to the zone file and RDDS. By default, status of the object is “ok”. Subsequent EPP 〈transform〉 commands or actions by SRS-BE may change that value to indicate restrictions present or transformations pending.

27.6 Renew Grace Period (RGP)

Upon receipt of a 〈renew〉 EPP command, SRS-BE will transition the domain name to the state of Renew Grace Period (〈renewPeriod〉). The renew grace period allows registrars to correct the mistaken renewal of an SLD. The Renew Grace Period lasts for five (5) days during which the receipt of a 〈delete〉 EPP command will result in the crediting back to the registrar the cost of the renewal. After this grace period ends, the domain name will revert to the Registered state. Domains in the RGP may transition to the following states: Redemption Grace Period (by meaning of a delete) or Pending Transfer (by means of a transfer) as described in sections 27.8 and 27.11, respectively.

27.7. Auto-Renew Grace Period (ARGP)

GSRS-BE will automatically renew a registration once it has expired and charge the registrar the current renewal fee. By default, CRR will extend the registration for one year. The ARGP is intended to allow registrars to delete a registration which has been auto-renewed and to receive a refund for the renewal fee. For the first 45 days after an automatic renewal, the domain is in state of the Auto-Renew Grace Period (〈autoRenewPeriod〉). During this 45-day grace period, GSRS-BE will accept requests from the EPP for the existing owner to update, renew, transfer and delete the registration provided there is not a corresponding status that prohibits the transformation. The registrar will then be charged the cost of this new transaction. If the registry happens to receive a 〈delete〉 EPP command during the ARGP, CRR will credit the cost of a renewal to the registrar. Without intervention, SRS-BE will then update the domain’s state to Registered.

27.8. Redemption Grace Period (RdGP)

SLDs that are deleted, such as when a registrar uses the 〈delete〉 EPP command, then enter the Redemption Grace Period (RdGP) (〈redemptionPeriod〉), with the exception of those deleted during the Add Grace Period (see above). The RdGP permits registrars to restore domains that were mistakenly deleted. The RdGP lasts for thirty (30) days. SRS-BE will first check for a clientDeleteProhibited or a serverDeleteProhibited prohibition before making the transition, and will not make the transition if those prohibitions exist.

Domains which enter this state become non-operational and are removed from the zone file and RDDS. The SRS-BE will accomplish this change by updating the DNS service. GSRS-BE will also set the status to “pendingDelete”. 

During the RdGP, the SRS-BE will reject all EPP requests other than 〈restore〉. Registrars have 30 days to submit a 〈restore〉 request in order for the transaction to be accepted and the transaction cost credited back to the registrar. Registrars must provide a 〈report〉 that provides, among other things, a reason (〈resReason〉) and supporting information (〈statement〉) within 5 days (during which time the status will be Pending Restore or 〈pendingRestore〉). CRR will not process a 〈restore〉 without a 〈report〉. If a 〈restore〉 request is not received or if a 〈report〉 is not received on time, GSRS-BE transitions the domain name to the Pending Delete state. Should a registrar reactivate the domain, SRS-BE will update the DNS zone file and RDDS. When complete, SRS-BE will update the state to Registered.

27.9. Pending Delete
 
This state is the final stage of the lifecycle prior to the domain again being made available. It lasts for 5 days. During this period, registrars shall not have the ability to reactivate the domain, but would have to wait to make a new request once the domain becomes available. During the Pending Delete phase, the SRS-BE will reject all requests to transform a domain name received through the EPP interface. The status of the domain name will be 〈pendingDelete〉. After this stage, the domain shall be removed from the registry’s database and once again made available for registration.

27.10. Released⁄Available

As noted above, at the conclusion of the Pending Delete state, GSRS-BE removes the domain name entirely from its database. It is now available for registrars. See 27.3 above for further details of “Available” state. The exception would be those domain names on the reserved list, which will instead return to the Reserved state after they are released.

27.11. Transfers

CRR and Google will adhere to the 15 March 2009 ICANN Policy on Transfer of Registrations (as well as its successor scheduled to take effect on 1 June 2012). Therefore, registrars are allowed to transfer domains between each other, provided that the states and status allow for it.

Transfer requires the following conditions:
- The domain must be in one of the following states: Add Grace Period, Registered, Renew Grace Period, Transfer Grace Period, or Auto Renew Grace Period.
- Neither a clientTransferProhibited nor a serverTransferProhibited status must be present.

Provided those two conditions are met, GSRS-BE will set the status to 〈pendingTransfer〉 while it performs its activities (during this period, the domain is considered to be in the Pending Transfer state). First, the registry will notify both registrars of the pending transfer. The registry will complete the transfer if it receives an 〈ACK〉 response from the Registrar of Record if received within the first five (5) days. If after five (5) days and the registry has not received any message, the transfer will be automatically completed. If a 〈NACK〉 response is received from the Registrar of Record, the transfer will be rejected. A rejected transfer would result in the SRS-BE setting the state back to its previous value.

Upon completion of the transfer, CRR will update the zone file and RDDS and send another notification to both registrars. When a transfer is complete, the registration period for the SLD is extended by a year (but not to exceed ten (10) years from the date of the transfer) and the gaining registrar will be charged for submitting a 〈transfer〉 EPP request.

27.11.1. Transfer Grace Period (TGP)

The registry places the domain name into the Transfer Grace Period (〈transferPeriod〉) for the first 5 days after the completion of the 〈transfer〉 request. During this time, the Gaining registrar will receive a credit for the cost of the transfer if a 〈delete〉 EPP transaction is received. Provided the domain is not deleted, at the end of the 5 day period the domain will return to the Registered state. A transfer received during TGP would result in the domain moving to 〈pendingTransfer〉 as described above.

27.12. Resourcing

Google Inc. will implement these technical requirements using the teams and resources discussed below.

The cost of these services will generally be set at reasonable market rates per agreement between Charleston Road Registry and Google. The expected costs are discussed in Questions 46 and 47.

27.12.1. Registry Team

The Registry Team will be responsible for designing and implementing the SRS, EPP, and WHOIS systems, including details related to domain name lifecycle. They will also be responsible for creating tests and monitoring for these systems.

During initial implementation, this team will consist of at least 4-7 software engineers responsible for implementing the project. Additionally, Google plans to staff one software engineer who is responsible for engineering testing and monitoring for the registry, and one software engineer who is responsible for backup, restoration and escrow. In total, Google plans to implement the registry with a team of 6-9 software engineers.

After the registry is complete, Google expects to staff a team to support the ongoing operation of the registry. This team will consist of at least four engineers who will participate in on-call rotation, respond to alerts, provide support to ICANN and registrars for emergency escalations, and maintain responsibility for bug fixes and improvements. This team will continue maintenance throughout the life of the registry.

This team’s responsibilities will generally be limited to registry-specific components. The Registry Team will work closely with other relevant teams, including the Authoritative DNS support team, Storage Site Reliability Engineering team, network engineering and operations, and customer support teams. These other teams are described in more detail in Question 31 (Section 31.16), as well as the relevant sections throughout this application.

27.12.2. Customer Services Team

The Google Customer Services Team will be responsible for supporting customers and partners, including life cycle requests. Google has a very large existing customer service team of both internal staff as well as staff contracted through third parties, with many hundreds of dedicated staff members already in place. Since these teams and their management are already in place, no standalone implementation resources are needed.

To continue ongoing maintenance of CRR support needs, Google plans to add additional resources for capacity as needed. Google expects to add a total of approximately fifteen additional personnel (including both Google employees and outside vendors) to support all of CRR’s customers and partners. The individual staffing allocation to each TLD is described in Question 47.

27.13. Summary and Key Insights

- The registry will support a full registration lifecycle consistent with that offered by other major gTLDs. State changes are triggered by registrar commands via the EPP interface or by the SRS-BE, which manages changes triggered by the passage of time.

28. Abuse Prevention and Mitigation

Specifically, we will implement in our internal policies and in our Registry⁄Registrar and Registration Agreements that all registered domain names will be subject to a Domain Name Anti-Abuse Policy (“Abuse Policy”). The Abuse Policy will provide CRR with broad power to suspend, cancel, or transfer domain names that violate the Abuse Policy. We plan to post the Abuse Policy on a publicly facing website at nic.mba⁄abuse, which will provide a reporting mechanism whereby violations of the policy can be reported by those who are impacted; an easy to find place to report policy violations; “plain language” definitions of what constitutes a “reportable” problem; and compliance processes to provide due process, and sanctions that will be applied, in the case of policy violations. The nic.mba⁄abuse website will list CRR’s Abuse Point of Contact. The Abuse Point of Contact shall consist of, at a minimum, a valid e-mail address dedicated solely to the handling of abuse complaints. CRR will ensure that this information is kept accurate and up to date and will be provided to ICANN if and when changes are made.The Abuse Point of Contact will review complaints regarding an alleged violation of the Abuse Policy. 

28.1. Abuse Tracking

CRR also plans to catalog all abuse communications in Google’s customer relationship management (CRM) software using a ticketing system and to maintain records of all abuse complaints for an appropriate amount of time. We shall only provide access to these records to third parties under limited circumstances, such as in response to a subpoena or other such court order or demonstrated official need by law enforcement. 

The Abuse Policy will define abuse as an action that:
a. Causes actual and substantial harm, or is a material predicate of such harm; and
b. Is illegal or illegitimate, or is otherwise considered contrary to the intention and design of a stated legitimate purpose, if such purpose is disclosed.

28.2. Abuse Definitions

The Abuse Policy will also name and provide basic definitions as to what constitutes the abusive registration and⁄or use of domain names within the TLD. These will include, but not be limited to, the following activities:
1. Unqualified Applicant - not authorized to register domain name; 
2. Child Pornography - Web sites that contain content that exploits children, such as child pornography (including cartoon child porn) or content that presents children in a sexual manner;
3. Fake renewal notices - Fake renewal notices are misleading correspondence sent to registrants from an individual or organization claiming to be or to represent the current registrar. These are sent for a variety of deceptive purposes, such as obtaining an unnecessary fee (fraud); getting a registrant to switch registrars unnecessarily (“slamming”, or illegitimate market-based switching); or to obtain registrant credentials or authorization codes to facilitate theft of the domain;
4. Cross-TLD Registration Scam - a deceptive sales practice where an existing registrant is sent a notice that another party is interested in or is attempting to register the registrant’s domain string in another TLD;
5. Domain kiting⁄tasting - Registrants may abuse an Add Grace Period through continual registration and deletion of domain names to test their monetization (“tasting”), and re-registration of the same names in order to avoid paying the registration fees (“kiting”);
6. Phishing - a Web site 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);
7. Spam - use of electronic messaging systems from email addresses from domains in the TLD to send unsolicited bulk e-mail;
8. Malware ⁄ Botnet Command-and-Control - Malware authors sometimes use domain names as a way to control and update botnets. Botnets are composed of thousands to millions of infected computers under the common control of a criminal. Botnets can be used to perpetrate many kinds of malicious activity, including distributed denial-of-service attacks (DDoS), spam, and fast-flux hosting of phishing sites;
9. Use of Stolen Credentials –such as stolen credit card numbers, to register domain names for malicious purposes;
10. Pharming - redirecting of unknowing users to fraudulent Web sites or services, typically through domain name system (DNS) hijacking or poisoning;
11. Fast flux hosting - use of fast-flux techniques to disguise the location of Web sites or other Internet services, or to avoid detection and mitigation efforts, or to host illegal activities. Fast-flux techniques use DNS to frequently change the location on the Internet to which the domain name of an Internet host or name server resolves. Fast flux hosting may be used only with prior permission of CRR;

28.3. Abuse Policy Rights Reserved

The Abuse Policy will state, at a minimum, that CRR reserves the right to deny, cancel, or transfer any registration or transaction, or place any domain name(s) on registry lock, hold, or similar status, that it deems necessary, in its discretion: (1) to protect the integrity and stability of the registry; (2) to comply with any applicable laws, government rules or requirements, requests of law enforcement, or any dispute resolution process; (3) to avoid any liability, civil or criminal, on the part of CRR, as well as its affiliates, subsidiaries, officers, directors, and employees; (4) per the terms of the registration agreement or any agreement CRR has with any party; (5) to correct mistakes made by CRR, its registry services provider, or any registrar in connection with a domain name registration; (6) during resolution of any dispute regarding the domain; and (7) to remedy the abusive registration or use of any domain name.

28.4. Orphan Glue

We will remove orphan glue records for names removed from the zone when provided with evidence in written form to the Abuse Point of Contact that the glue is present in connection with malicious conduct according to Specification 6 of the New gTLD Registry Agreement. Google’s back-end systems will also periodically search for orphaned glue. We will inform its registrants that it removes glue if the covering zone is removed, and thus registrants should not reference it from outside the domain.

28.5. Resourcing

CRR and its affiliates will commit ample resources for the purpose of implementing its internal policies and its Registry⁄Registrar and Registration Agreements. As described herein, we will create an Internal Abuse Team, including an Abuse Point of Contact, whose responsibilities will include reviewing, responding, cataloging, and, if applicable, remedying complaints regarding alleged violations of the Abuse Policy. This team will be dedicated to manually reviewing abuse complaints. The roles and responsibilities of the team members are anticipated to include, but are not limited to, the following: 
- Reviewing, responding, and if applicable, resolving complaints regarding alleged violations of the Abuse Policy
- Enforcing the Abuse Policy 
- Monitoring productivity and efficiency of the manual review process
- Addressing high priority escalations from Law Enforcement quickly
- Collaborating with internal and external partners to drive issues to resolution 
- Interface with the technical team to improve workflow, prioritize escalations, create tools for the manual review process

28.6. Anti-abuse Notice and Takedown Procedure

In order to reduce abusive registrations that affect the security of the TLD and its users, CRR plans to provide a domain anti-abuse notice and takedown procedure. Specifically, we will operate an anti-abuse website at the URI address nic.mba⁄abuse that will provide the contact information for the Abuse Point of Contact. The nic.mba⁄abuse website will prominently display CRR’s Abuse Policy and a fill-in section wherein the user will then be asked to fill in several fields, including the user’s identity and contact information, and the identity and relevant information of the individual or organization that is making an abusive registration or use of a domain name within the TLD, and specific details on how, why, and when the complainant believes the registration or use of the domain name is abusive. The user will be asked to read the Abuse Policy before it submits a complaint and then click on a check box to indicate that the user has read and understands the Abuse Policy.

28.7. Abuse Response

CRR will then provide a targeted response time as to the decision regarding the complaint. We will review with the Internal Abuse Team and render a decision regarding the alleged abuse, and decide whether to deny, cancel, or transfer any registration or transaction, or place any domain(s) on registry lock, hold, or similar status that violates the Abuse Policy, if applicable. In accordance with the applicable terms of service, CRR reserves the right to terminate the accounts or domains of repeat abusers.

Specifically, the process is anticipated to occur as follows: an email containing the information relayed in the complaint will be sent to the Abuse Point of Contact. The Abuse Point of Contact will send an email to the complainant within twenty-four hours of receiving the complaint confirming receipt of the email. The Abuse Point of Contact will preliminarily review to determine whether the complaint reasonably falls within an abusive use as defined by the Abuse Policy. If the complaint does not, the Abuse Point of Contact will email the complainant within forty-eight business hours of the confirmation email to indicate that the subject of the complaint does not fall within the abusive uses as defined by the Abuse Policy, and that CRR considers the matter closed.

If the preliminary review does not resolve the matter, the Abuse Point of Contact will relay the complaint to CRR’s Abuse Team.

All requests from law enforcement will be flagged for prompt review by the Internal Abuse Team. With the resources of Google’s registry services team, CRR can meet its obligations under Section 2.8 of the Registry Agreement where required to take reasonable steps to investigate and respond to reports from law enforcement and governmental and quasi-governmental agencies of illegal conduct in connection with the use of its TLD. 

In high-priority cases the Internal Abuse Team will seek to determine within forty-eight business hours whether the registration or use of the domain within the TLD is abusive as defined by the Abuse Policy. In all cases, the Internal Abuse Team will determine whether a domain is abusive within seven business days or sooner of receipt of the Complaint. If an abusive use is determined, the Internal Abuse Team may alert the registry services team to immediately suspend resolution of the domain name, as appropriate. Thereafter, if we decide to suspend resolution of the domain name at issue, the Abuse Point of Contact will immediately notify the abusive domain name registrant of such action, the nature of the complaint, and provide the registrant with the option to respond within ten days. All such actions will be ticketed in Google’s CRM software to maintain accurate complaint processing records.

If the registrant responds within ten business days, the Internal Abuse Team will review the response to determine if the registration or use is not abusive. If the Internal Abuse Team is satisfied by the registrant’s response, the Abuse Point of Contact will submit a request to the registry services team to reactivate the domain name. If the registrant does not respond within ten business days or the Internal Abuse Team is not satisfied by the registrant’s response, the Abuse Point of Contact will notify the registry services team to continue the suspension, transfer or cancel the abusive domain name, as appropriate.

The anti-abuse procedure will not prejudice either party’s election to pursue another dispute mechanism, such as the Uniform Rapid Suspension System (URS) or Uniform Domain-Name Dispute-Resolution Policy (UDRP). If CRR’s registrar receives notice of a URS or UDRP complaint pertaining to a domain name within the TLD, the registrar will ensure that the domain name is locked within twenty-four hours of receipt of the complaint. The registrar will also notify CRR’s Abuse Point of Contact and the registrant.

28.8. Abuse Prevention

In order to further minimize abusive domain name registrations and other activities that have a negative impact on Internet users, CRR will promote the ability to contact a domain registrant using information in WHOIS by providing accessibility in a reliable, consistent, and predictable fashion. CRR will adhere to port 43 WHOIS Service Level Agreements (SLA), which require that port 43 WHOIS service be highly accessible and fast.

 CRR will authenticate registrant information by providing an email verification link sent to the registrant to confirm its email address. In addition, we will ensure an ongoing ability to contact the registrant via email by confirming the new email address as part of changes affecting the contact information.

CRR plans to regularly monitor registration data for accuracy and completeness, employing authentication methods, and establishing policies and procedures to address domain names with inaccurate or incomplete WHOIS data. 

As required by Specification 4 of the new gTLD Registry Agreement, CRR will offer thick WHOIS services, in which all authoritative WHOIS data is maintained at the registry. Through CRR’s registrar and registry services team, we will maintain timely, unrestricted and public access to accurate and complete WHOIS information, including registrant, technical, billing, and administrative contact information, identity of the registrar, domain name’s expiration date, nameservers associated with the domain, and specified fields of data for the Registrant Contact, Administrative Contact, and Technical Contact.

CRR will employ query rate limiting and CAPTCHA procedures for its WHOIS database to minimize abuse of its features.

28.9. Summary and Key Insights

Abusive activity on the Internet has been a growing problem, creating security and stability issues for registrants, registrars and users of the Internet in general. CRR intends to address this issue across its TLDs by dedicating ample resources for the purpose of implementing its strict abuse policies and procedures. 

Abusive registrations and uses of domain names in the global top-level domain (gTLD) will not be tolerated. The nature of such abuses creates security and stability issues for the registry, registrars and registrants, as well as for users of the Internet in general. As set forth in prior responses, Charleston Road Registry (CRR) will employ a stringent verification process to establish that every prospective registrant meets the registration criteria. In addition to this verification process, the registry promises to incorporate the following Rights Protection Mechanisms.

29.1. Rights Protection Mechanisms – Sunrise Period

Subject to the Sunrise Eligibility Requirements (SERs) outlined herein, Charleston Road Registry (CRR) will offer a Sunrise Period of 60 days for owners of trademarks listed in the Trademark Clearinghouse to register domain names that contain a second level consisting of an identical match to their listed trademarks. In addition, CRR plans to implement a pricing structure to make it easy for brand owners to secure their trademarks and brand names within the gTLD. CRR’s registrar will confirm all Sunrise and Registration eligibility. As an added measure of security for brand owners, CRR will staff an internal sunrise team (the “Sunrise Contact”) which will review all Sunrise registrations to ensure Sunrise and registration eligibility.

The SERs, which will be verified by Clearinghouse data, will include the following: (i) proof of membership in eligible registrant class, (ii) ownership of a mark that is (a) nationally or regionally registered and for which proof of use, such as a declaration and a single specimen of current use – was submitted to, and validated by, the Trademark Clearinghouse; or (b) that have been court-validated; or (c) that are specifically protected by a statute or treaty currently in effect and that was in effect on or before 26 June 2008; (iii) representation that all provided information is true and correct; and (iv) provision of data sufficient to document rights in the trademark.

Upon submission of all of the required information and documentation, the registrar will review the submissions and verify the trademark and eligibility information and all contact information provided for registration. The registrar shall then send confirmation messages, listing any deficiencies regarding the trademark information provided with the application. If a registrant does not cure any eligibility deficiencies and⁄or respond by the means listed within one week, the registrar will release the name.

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

After receiving a Sunrise Complaint, the Sunrise Contact will review the Complaint to see if the Complaint reasonably asserts a legitimate challenge as defined by the SDRP. If the Complaint does not, the Sunrise Contact will email the complainant within 36 hours of the complaint to indicate that the subject of the complaint does not fall within SDRP, and that CRR considers the matter closed.

If the domain name is not found to have adequately met the SERs, the Sunrise Contact may alert the registrar to immediately suspend resolution of the domain name, as appropriate. Thereafter, the Sunrise Contact will immediately notify the registrant of such action, the nature of the complaint, and provide the registrant with the option to respond within ten days to cure the SER deficiencies or the domain will be canceled. All such actions will be ticketed in Google’s customer relationship management (CRM) software to maintain accurate SDRP processing records.

If the registrant responds within ten business days, its response will be reviewed by the Sunrise Contact to determine if the SERs are met. If the Sunrise Contact is satisfied by the registrant’s response, it will submit a request by the registry services team to reactivate the domain name. The Sunrise Contact will then notify the Complainant that its complaint was ultimately denied and provide the reasons for the denial. If not, both the registrant and the complainant will be notified that the domain name will be released.

29.2. Rights Protection Mechanisms – Trademark Claims Service

CRR will offer a Trademark Claims Service during the Sunrise Period and plans to continue to offer the service for an indefinite period of time thereafter during general registration. CRR will staff an internal team that will be considered the Trademark Claims Contact. The registrar will verify whether any domain name requested to be registered in the gTLD is an identical match of a trademark that has been filed with the Trademark Clearinghouse. It is anticipated that a domain name will be considered an identical match when the domain name consists of the complete and identical textual elements of the mark, and includes domain names where (a) spaces contained within a mark that are either replaced by hyphens (and vice versa) or omitted; (b) certain special characters contained within a trademark are spelled out with appropriate words describing it (e.g., @ and &); and (c) punctuation or special characters contained within a mark that are unable to be used in a second-level domain name are either (i) omitted or (ii) replaced by hyphens or underscores. 

If the registrar determines that a prospective domain name registration is identical to a mark registered in the Trademark Clearinghouse, the registrar will provide a “Trademark Claims Notice” (“Notice”) in English on the registrar’s website to the prospective registrant of the domain name. The Notice will provide the prospective registrant with access to the Trademark Clearinghouse Database information referenced in the Trademark Claims Notice to enhance its understanding of the Trademark rights being claimed by the trademark holder via a link. The Notice will be provided in real time without cost to the prospective registrant.

After receiving the Notice, the registrar will require the prospective registrant to click a link that specifically warrants that: (i) the prospective registrant has received notification that the mark(s) is included in the Clearinghouse; (ii) the prospective registrant has received and understood the Notice; and (iii) the registration and use of the requested domain name will not infringe on the rights that are the subject of the Notice. 

CRR reserves the right to adopt other procedures and requirements for the Trademark Claims Service. At a minimum, it is anticipated that after the effectuation of a registration that is identical to a mark listed in the Trademark Clearinghouse, the registrar will then provide a clear notice to the trademark owner of the trademark with an email detailing the WHOIS information of the registered domain name. The trademark owner then has the option of filing a Complaint under the Uniform Domain Name Dispute Resolution Policy (UDRP) and⁄or the Uniform Rapid Suspension System (URS) against the domain name. As discussed in its right protection mechanisms, CRR will require in its domain name registration agreements that its registry operator and registrar providers, as well as all registrants, submit to the Uniform Domain Name Dispute Resolution Policy (UDRP) and the Uniform Rapid Suspension System (URS) procedures. CRR and its registrar(s) will abide by decisions rendered under the UDRP and URS on a timely and ongoing basis upon notification.

29.3. Rights Protection Mechanisms – URS

CRR will specify in the Registry Agreement, all Registry-Registrar Agreements, and all Registration Agreements used in connection with the gTLD that it will abide by all decisions made by panels in accordance with the Uniform Rapid Suspension System (URS). CRR’s registrar will be tasked with receiving all URS Complaints and decisions. After receiving a URS complaint about a domain name within the gTLD, the registrar will ensure that the domain name is locked within twenty-four (24) hours of receipt of a URS complaint from the URS Provider and will notify CRR’s Abuse Point of Contact and the registrant. In the event of a determination in favor of the complainant, the registrant will notify the Abuse Point of Contact and the registry services provider to ensure that the registry suspends the domain name in a timely fashion and has the website at that domain name is redirected to an informational web page provided by the URS Provider about the URS throughout the life of its registration. CRR’s Abuse Point of Contact will oversee and monitor the status and resolution of all URS complaints and decisions.

29.4. Rights Protection Mechanisms – UDRP

CRR will specify in the Registry Agreement, all Registry-Registrar Agreements, and all Registration Agreements used in connection with the gTLD, that it will abide by all decisions made by panels in accordance with the Uniform Domain-Name Dispute-Resolution Policy (UDRP). CRR’s registrar will be tasked with receiving all UDRP complaints and decisions. After receiving a UDRP complaint about a domain name within the gTLD, the registrar will ensure that the domain name is locked within twenty-four (24) hours of receipt of a UDRP complaint from the UDRP Provider and will notify CRR’s Abuse Point of Contact and the registrant. In the event of a determination in favor of the complainant, the registrant will notify the Abuse Point of Contact and the registry services provider to ensure that the registry cancels or transfers the domain name in a timely fashion as provided for by the decision. CRR’s Abuse Point of Contact will oversee and monitor the status and resolution of all UDRP complaints and decisions.

29.5. Rights Protection Mechanisms – Proven Registrars

CRR will contract with various ICANN-accredited registrars. CRR is committed to reducing abusive registrations, and will ensure that its registrar operates accordingly. 

29.6. Rights Protection Mechanisms – Pre-Authorization and Authentication

CRR will authenticate registrant information by providing an email verification link sent to the registrant to confirm its email address. In addition, CRR will ensure proper access to domain functions by requiring multi-factor authentication from registrants to process update, transfer, and deletion requests.

No name will resolve until the registrant has been verified by the internal team as an eligible registrant.

29.7. Rights Protection Mechanisms – Grace Period

See Question 27 for a detailed discussion of CRR’s policies with respect to Add Grace Periods.

29.8. Rights Protection Mechanisms – Domain Anti-Abuse Policy

CRR will implement in its internal policies and its Registry-Registrar and Registration agreements that all registered domain names will be subject to a Domain Name Anti-Abuse Policy (“Policy”). See Question 28 for a detailed discussion of CRR’s Anti-Abuse Policy.

29.9. Resourcing

Google will implement these technical requirements using the teams and resources discussed below.

The cost of these services will generally be set at reasonable market rates per agreement between CRR and Google. The expected costs are discussed in Questions 46 and 47.

29.9.1. Registry Team

The Registry Team will be responsible for designing and implementing the SRS, EPP, and WHOIS systems, including implementation of the rights protection mechanisms. They will also be responsible for creating tests and monitoring for these systems.

During initial implementation, this team will consist of at least 4-7 software engineers responsible for implementing the project. Additionally, Google plans to staff one software engineer who is responsible for engineering testing and monitoring for the registry, and one software engineer who is responsible for backup, restoration and escrow. In total, Google plans to implement the registry with a team of 6-9 software engineers.

After the registry is complete, Google expects to staff a team to support the ongoing operation of the registry. This team will consist of at least four engineers who will participate in on-call rotation, respond to alerts, provide support to ICANN and registrars for emergency escalations, and maintain responsibility for bug fixes and improvements. This team will continue maintenance throughout the life of the registry.

This team’s responsibilities will generally be limited to registry-specific components. The Registry Team will work closely with other relevant teams, including the Authoritative DNS support team, Storage Site Reliability Engineering team, network engineering and operations, and customer support teams. These other teams are described in more detail in Question 31 (Section 31.16), as well as the relevant sections throughout this application.

29.9.1. Customer Service Team

The Customer Services Team will be responsible for supporting customers and partners, including responding to abusive registrations. Google has a very large existing customer service team of both internal staff as well as staff contracted through third parties, with many hundreds of dedicated staff members already in place. Since these teams and their management are already in place, no standalone implementation resources are needed.

To continue ongoing maintenance of CRR support needs, Google plans to add additional resources for capacity as needed. Google expects to add a total of approximately fifteen additional personnel (including both Google employees and outside vendors) to support all of CRR’s customers and partners. The individual staffing allocation to each gTLD is described in Question 47.

29.10. Summary and Key Insights

CRR is committed to implementing strong and integrated intellectual property rights protection mechanisms. Doing so is critical to Google’s goals of model Internet citizenship and fostering Internet development, especially in emerging regions. Accordingly, CRR intends to offer a suite of rights protection measures which builds upon ICANNʹs required policies while fulfilling our commitment to encouraging innovation, competition, and choice on the Internet.

30.a. Security Policy

Google plans to use the same common secure infrastructure to support the proposed registry that we use for our other production networks and computing environments. Google currently provides best-in-class security technologies and processes to protect Google’s products, services, infrastructure and user data. Google’s common secure infrastructure supports some of the web’s most widely-used services, such as Google Search YouTube, and Google Apps. These services are used by many millions of consumers, businesses and government customers for their daily operations. Google does not have any plan to support High Security Top Level Domain (HSTLD).

30.a.1. Google Security Policies

Google’s security programs are governed through the Google Security Team. The Security Team is led by Google’s Vice President of Security, who reports to Google Senior Leadership including the President of Technology and Chief Executive Officer. Google’s VP of Security has approved the security policies that underpin Google’s information security program.

Our Security Team is committed to:
- Control and maintain the confidentiality, integrity, and availability of information and information systems.
- Limit Google’s exposure to the risks arising from loss, corruption or misuse of our information assets.
- Ensuring consistency, which is attained against legal, regulatory, policy and best practice requirements.

Google regularly reviews and updates the security policies that address purpose, scope, responsibilities, management commitment, coordination among organizational entities, and 
compliance.

To ensure the consistent implementation of security controls across the various layers of infrastructure and services, Google has documented the following security policies.

- Basic Security Policy: States the foundation and principles of Google’s Security Policies. 
- Physical Security Policy: States how the safety of people and property is protected at Google. 
- Accounts Access and Administration Policy: States the kinds of internal accounts Google has and how to access, use, and administer them in a way that reduces risk and provides the ability to audit account activity.
- Data Security Policy: States how data should be handled at Google to help ensure its confidentiality, integrity, and availability.
- Corporate Services Security Policy: Informs Google employees of what to expect regarding access, monitoring, and other security considerations for communications and other data sent, received, or stored using Googleʹs corporate services. 
- Network and Computer Security Policy: States how to reduce the likelihood of compromise to Googleʹs data and infrastructure from devices connected to Google networks. 
- Applications, Systems, and Services Security Policy: Ensures that adequate attention is paid to security in the design, procurement, development, deployment, and maintenance of Applications, Systems, and Services.
- Change Management Policy: Describes the safeguards that protect Google from accidental or malicious changes to Googleʹs systems.
- Information Security Incident Response Policy: States the minimal requirements for preparing for and responding to information security incidents.
- Datacenter Security Policy: Ensures that adequate attention is given to verifying that each datacenter hosting Google systems maintains security controls that provide protection appropriate to the criticality of those systems.

30.a.2. Independent Assessment Reports

Google regularly engages independent assessors to independently assess its information systems, infrastructure and security program and controls for compliance with the following:

- Federal Information Security Management Act (FISMA). Independent assessments conducted every two years. In 2011, Google received FISMA certification for Google Apps Cloud, another service that uses the same production network as the Google registry will use. Grant Thornton LLP performed independent assessment, and United States General Services and Administration (GSA) issued FISMA certification to Google based on this independent assessment.
- Statement on Standards for Attestation Engagements (SSAE16). Independent assessments conducted annually.
- Sarbanes-Oxley (SOX). Independent assessments conducted annually. 
- Payment Card Industry (PCI). Independent assessments conducted annually.

Government agencies and Enterprise customers are currently using Google Apps Cloud Services. Google’s corporate and production networks were both in scope for FISMA and SSAE16 independent assessments. Google is also currently preparing for ISO 27001 certification of Google Apps Cloud. 

30.a.3. Commitments made to Registrants

Google will make the following commitments to registrants.

- Google’s existing dedicated Security Organization will remain the focal point for ensuring implementation of adequate system security in order to prevent, detect, and recover from security breaches. Various teams in the security organization ensure that Google’s infrastructure and services are operated, used, maintained, and disposed of in accordance with internal security policies.
- Google will continue to contemplate threats from internal and external sources, and will exercise our existing incident response capability.
- Google will continue to perform quarterly scanning of our internal and external infrastructure to detect network, database, application, and OS vulnerabilities. 
- Google will continue to maintain robust Logging, Monitoring and Auditing capabilities for its systems and networks. These policies are discussed further in Section 30b.
- Google’s externally facing network infrastructure will continue to enforce strict access control restrictions to deny all traffic and allow only authorized protocols to enter the Google network.
- Google has established background investigations for all Google employees in accordance with local laws and will continue to do background investigations for any new Google employees.