ICANN New gTLD Application

New gTLD Application Submitted to ICANN by: Charleston Road Registry Inc.

String: cal

Originally Posted: 13 June 2012

Application ID: 1-1680-27519


Applicant Information


1. Full legal name

Charleston Road Registry Inc.

2. Address of the principal place of business

1600 Amphitheatre Parkway
Mountain View 94043
US

3. Phone number

16502530000

4. Fax number

1 650 253 0001

5. If applicable, website or URL


Primary Contact


6(a). Name

Sarah Falvey

6(b). Title

Senior Policy Analyst

6(c). Address


6(d). Phone Number

1 202 346 1230

6(e). Fax Number


6(f). Email Address

tas-contact9@google.com

Secondary Contact


7(a). Name

Chris Iannuccilli

7(b). Title

Director of Marketing

7(c). Address


7(d). Phone Number

1 650 253 2903

7(e). Fax Number


7(f). Email Address

chrisiann@google.com

Proof of Legal Establishment


8(a). Legal form of the Applicant

Corporation

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

State of Delaware (General Corporations Code)

8(c). Attach evidence of the applicant's establishment.

Attachments are not displayed on this form.

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


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

Google Inc.

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


Applicant Background


11(a). Name(s) and position(s) of all directors

Christine FloresDirector

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

Christine FloresCEO, President, and Secretary
Donald S. HarrisonAssistant Secretary
James MaroccoCFO and Treasurer

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

Google Inc.Not Applicable

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


Applied-for gTLD string


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

cal

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


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


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


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


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


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


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


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

Attachments are not displayed on this form.

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


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


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

While the string for which Charleston Road Registry (CRR) is applying, .cal, 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 .cal string for rendering issues; none were found.

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


Mission/Purpose


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

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 operator 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 Google 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, ʺcal,ʺ which is intended to be short for ʺcalendar.ʺ The mission of this gTLD, .cal, is to provide a dedicated domain space in which to enact second-level domains that relate to the management of an individual, group, or enterpriseʹs calendar via Google Calendar. This mission will enhance consumer choice by providing new availability in the second-level domain space for users of Google calendar, 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). How do you expect that your proposed gTLD will benefit registrants, Internet users, and others?

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

18.b.i.1. Specialty

Charleston Road Registry intends to apply for an exemption to ICANN’s Registry Operator Code of Conduct and operate the proposed gTLD with Google as the sole registrar and registrant. The proposed gTLD will specifically align with Google Calendar, an existing Google product, and will provide users with improved capabilities that meet their diverse needs.

The specialization goal of the proposed gTLD is to provide a dedicated second-level domain space for a user’s or enterprise’s management of their Google Calendar. This specialization introduces a new domain name hierarchy that will generate new Google Calendar namespace, and provide for streamlined, internal Google management of the introduction and phase out of new or retiring products and⁄or services in the second-level domain.

This specialization offers Internet users Google services that will enhance their current and future experience with Google Calendar. Google will manage a process whereby users will be able to make use of unique vanity names in the gTLD; such second-level domains will only point to the Google offering. This provides users with a distinctive namespace as they develop and implement a unique, customized vision for their use of Google Calendar. Google strives to offer its customers leading edge tools that will not only enable them to better personalize their respective second-level domain content, but also spur further creativity and generate new options on the Internet.

As the Internet is ever changing, these services will evolve to meet users’ needs to the benefit of the Internet public. Google seeks to continuously provide tools that solve problems faced by Internet users, and, in partnership with Charleston Road Registry, the proposed gTLD will open the opportunity for Google to provide these customer-centric solutions.

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.

Charleston Road Registry’s service level goal for the proposed gTLD is to ensure that Google, as the proposed sole registrant, is supported in delivering the high level of quality, speed, and service to users for which it is known. Indeed, two of Google’s core principles in providing Internet search and related goods and services are “focus on the user and all else will follow” and “fast is better than slow.”

In focusing on the user, Google strives to provide the best user experience possible. Google will continue to operate under this principle when designing new offerings and providing goods and services within the proposed gTLD.

Google keeps speed in mind with each new product it releases, from faster mobile applications to improved Web browsers designed for rapid search and navigation. Google continues to devote its resources to improving speed and efficiency. In managing the proposed gTLD, Google expects to keep its service reliability and speed to this standard through direct management of all technical infrastructure related to DNS resolution other than the operation of the root servers.

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

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, high level of security, and become known as an exemplary domain name services provider.

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 so that Google registers and manages domain names in the .cal gTLD, that those domain names are used for only Google Calendar-related purposes, and that the registry is responsive to legal rights owners (if applicable).

As noted, Charleston Road Registry intends to apply for an exemption to ICANN’s Registry Operator Code of Conduct and operate the proposed gTLD with Google as the sole registrar and registrant. This facilitates Google’s ability to further enhance the Google Calendar brand and the reputation of Google Calendar offerings.

In addition, Charleston Road Registry’s operation of the new gTLD will provide the opportunity for users to build and⁄or bolster their unique brands or tailor unique user identities 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, increase productivity in enterprises, and spur innovation in the gTLD space.

Google will have the opportunity to differentiate and innovate upon its Google Calendar products and services through its use of the gTLD.

The proposed gTLD, .cal, will provide a new mechanism for users to make use of a unique, vanity second-level domain name that points to the userʹs Calendar account. Charleston Road Registry anticipates the .cal gTLD will help grow the volume of calendar offerings on the Internet, thereby increasing competition among web-based calendar service providers.

The proposed gTLD will promote competition in the gTLD space by inciting competitors to respond with improved gTLD operations, greater range and higher quality products and services integrated with domain name offerings, and⁄or the creation of their own respective gTLDs, to the benefit of all Internet users. Launching the proposed gTLD will also generate increased competition in the online marketplace by adding incremental availability to the second-level domain pool.

As noted above, Charleston Road Registry intends to apply for an exemption to the ICANN Registry Operator Code of Conduct. Given that the proposed gTLD is exclusively intended for use in connection with Googleʹs service, Charleston Road Registry believes that there is a reasonable case for such an exemption. Should ICANN not approve this proposed exemption, Charleston Road Registry will facilitate a fair and equitable registrar process, providing open access to any registrar who meets ICANN accreditation guidelines.

18.b.ii.2. Differentiation

The proposed gTLD will clearly be differentiated from other gTLDs due to its purposefully limited scope. This differentiation includes: (1) uniqueness in terms of the users the proposed gTLD seeks to benefit; (2) a clear indicator that second-level domains within the gTLD offer a particular, targeted content; (3) and because the TLD will be associated with a Google offering, Internet users will immediately be able to rely on the quality of the product.

The gTLD will provide an authoritative environment for the provision of Google Calendar offerings. New, higher quality products offered in the gTLD will also attract new users to the Google offering.

The .cal gTLD will provide Google with the opportunity to differentiate its Calendar offerings from other calendar and meeting scheduling service providers by virtue of its branded gTLD. This gTLD is not currently available in the gTLD space, and its provision will eliminate the need for Google to use more generic gTLDs, such as .com, to deliver its Calendar offerings.

The proposed gTLD will also encourage differentiation among users. Google’s services, including tools to improve and customize users’ unique Google Calendar experiences, will provide users with new ways of distinguishing themselves from others.

18.b.ii.3. Innovation

The proposed gTLD will promote further innovation by creating a new space for the categorization and classification of online content. The proposed gTLD is in itself innovative, as it seamlessly combines DNS services with other Google products and services.

The proposed gTLD will spur further innovation at Google by providing an accelerated platform for the introduction of new Calendar offerings to the public. The proposed gTLD will provide a mechanism for enhanced branding and management of Google’s Calendar offerings.

The proposed gTLD, .cal, will promote innovation by encouraging Google to create new offerings for distribution in the .cal gTLD. In addition, the proposed gTLD will encourage other online services to create new offerings and⁄or provide an umbrella gTLD in which to link their respective offerings, providing Internet users the same benefits as .cal will provide. In addition, Google may choose to innovate within its portfolio of web spaces and introduce distinguishing features that further crystallize the relationship between offerings provided in the gTLD and the Google brand and reputation. This will likely invite user comparison among domain sites, encouraging competitors to innovate and develop new features and services.

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 users this same level of continuous development in advancing its management and operation of the gTLD, engendering an improved user experience.

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 users in the proposed gTLD. Charleston Road Registry is uniquely positioned to provide this level of experience given its relationship with Google; per its SEC filings, Google invested over $3 billion in its IT infrastructure in 2011 and maintains a record of excellence in infrastructure operations.

Google keeps user experience in mind with each new service it releases, from allowing users to personalize their Gmail accounts to providing small to medium businesses with tools customized for their specific needs. The proposed gTLD provides Google with a formal mechanism whereby it can continue to improve its services to address the ever-changing needs of all Internet users.

The proposed gTLD, furthermore, facilitates an improved online user experience by provisioning the DNS on users’ behalf and streamlining the process by which users are able to link to and make use of the Google offering.

The proposed gTLD, .cal, will provide users with an improved Google Calendar experience by allowing for users’ direct management of their respective content within the .cal gTLD

In focusing on the user, Google strives to provide the best user experience possible. Google will continue to operate under this principle when designing and providing new service offerings in the proposed gTLD. The proposed gTLD will provide users with improved customization services and facilitate additional opportunities to enhance their current and future experience with Google Calendar.

The proposed gTLD will provide a more trusted and user-friendly environment where domain names and content related to the .cal 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.

Lastly, the proposed gTLD improves the Internet user experience by creating greater structure and categorization on the Internet.

18.b.iv. Registration Policies

Because the sole purpose of the proposed gTLD is to associate domain names with the Google Calendar offering, Charleston Road Registry intends to apply for an exemption to the ICANN Registry Operator Code of Conduct and operate the gTLD with Google as the sole registrar and registrant. As the sole registrant, Google will have the opportunity to differentiate and innovate upon its Google Calendar products and services through its use of the gTLD.

Given the proposed limited scope and use of the gTLD, Charleston Road Registry believes that there is a reasonable case for such an exemption. Should ICANN not condone this proposed exemption, Charleston Road Registry will make access to Registry Services, including the shared registration system, available to all ICANN-accredited registrars.

Charleston Road Registry believes that given its specific use, the .cal gTLD will best add value to the gTLD space by limiting all second-level domains to the sole use of pointing at Google Calendar offerings. Google will manage a process whereby users will be able to make use of unique vanity names in the gTLD; such second-level domains will only point to the user’s Google Calendar account. In addition, only entities and individuals with a Google Calendar account or who create a new account may be eligible to enact a second-level domain within the gTLD.

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 its commitment to encouraging innovation, competition and choice on the Internet.

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. Although Google will be the only registrant (and is intended to serve as the only registrar for the gTLD as well), Charleston Road Registry and its provider of registry services, Google, have imposed measures to achieve this protection for their users; additional specifics regarding the practices for the registry include but are not limited to the following:

- Since Google will be the only registrant, personally identifying information regarding individual users will not be sent to or stored by the registry. Such data will remain on Google’s infrastructure used to provide the individual service, and is subject to Google’s existing privacy policy.

- 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 the WHOIS service 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.

- In the event that other registrars are involved, 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.

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 Google begins developing public-facing resources in its gTLD, it intends to inform the public about the gTLD and the opportunity for users to obtain domain space there through marketing and public relation investments.

Charleston Road Registry, in conjunction with Google, intends to promote gTLDs under its purview 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 and Google believe 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 and Google 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, Google will use local marketing and communications platforms as needed.

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

18.c.i
Should ICANN grant Charleston Road Registry’s exemption to the Code of Conduct, and the proposed gTLD operate with Google as the sole registrar and registrant, members of the public will not be able to directly register domain names in this new gTLD. Users will, however, be given the opportunity to make use of a vanity second-level domain as a memorable identifier linked to content in Google Calendar. Users will be assigned a vanity domain name pursuant to Google’s forthcoming user registration guidelines. In addition, Google will follow ICANN rules for 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.

18.c.ii
Should ICANN grant Charleston Road Registry’s exemption to the Code of Conduct, the proposed gTLD will operate with Google as the sole registrar and registrant. As registrations will be granted based on Google business needs and user demand, Charleston Road Registry will charge prices commensurate with overall business costs. Charleston Road Registry does not intend but reserves the right to offer introductory discounts and bulk registration discounts to this sole registrant.

18.c.iii
Should ICANN grant Charleston Road Registry’s exemption to the Code of Conduct, the proposed gTLD operate with Google as the sole registrar and registrant. As registrations will be granted based on Google business needs and user demand, Charleston Road Registry will charge prices commensurate with overall business costs. Contractual commitments to registrants regarding price escalation are not relevant to Google’s mission or goals for the new gTLD at this time, as Google is the sole registrant.

Community-based Designation


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

No

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


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


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


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


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


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

Attachments are not displayed on this form.

Geographic Names


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

No

Protection of Geographic Names


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

As is specified throughout this application, Charleston Road Registry (CRR) plans to operate the top-level domain as a closed registry and shall not permit any party to register or operate any second-level domain names within the TLD.  In accordance with ICANN’s recommendations in the January 11, 2012, version of the New gTLD Applicant Guidebook, Specification 5 of the Registry Agreement, and in the spirit of sections 2.2 and 2.7 of the GAC Principles Regarding New gTLDs, CRR shall reserve to ourselves the following:

(1) all of the English country and territory names found in ISO 3166-1 and their specified short form abbreviations;
(2) all the of names found in the United Nations Group of Experts on Geographical Names, as found in the Technical Reference Manual for the Standardization of Geographical Names, Part III (Names and Countries of the World); and
(3) all of the names of the United Nations member states as prepared by the Working Group on Country Names of the United Nations Conference on the Standardization of Geographical Names in the six official languages of the United Nations.

As noted above, the top-level domain shall not permit the public to register domains at the second-level. The registry shall not use or license the use of any full country name in English, or any other reserved language, as a second-level domain except in accordance with Specification 5 of the New gTLD Agreement. With regard to the abbreviated country and territory names found in ISO 3166-1, CRR plans to reserve current and future country abbreviations for use at the second-level. This follows the spirit and function of the procedures that the .info TLD utilized.

As with the .info TLD, CRR shall ensure that all geographic abbreviation identifiers contained within the ISO 3166-1 list will be reserved to us as the registry operator. Unlike the .info TLD, however, the registry shall not make any of these identifiers publicly available for registration. CRR plans to make these these two letter geographic abbreviation identifiers available to Google to provide localized content via second-level domains. Googleʹs Web Search and other services are customized for a number of countries and regions across the world, and these two letter second level domain names would be used to provide a namespace to which that customization could be applied. For example, bw.Google could provide search results that would be most relevant for users in Botswana. It could allow Google to direct users to the site that can give them the most relevant results.

CRR notes that confusion regarding whether the second-level domain is an official conduit of the affected country should be of minimal concern for governments in the context of a closed registry whose TLD is the trademark of a private entity and where all usage of the domain is directly tied to Google’s brand and offerings. Unlike .info, there should be a minimal possibility of creating geopolitical conflicts in the top-level domain resulting from confusion associated with national government websites. Further, it is not CRR desire to serve TLDs that compete with national ccTLDs, rather to serve Google’s users more localized content in a given region.

Google’s core business functions include facilitating searches for Internet content and communications among Internet users. In connection with these functions, CRR intends to fully utilize the abbreviated country code names to harness the TLD to provide localized content, especially to the developing world. Throughout 2011, several chapters of the Internet Society in developing nations have found that despite growing connectivity in their nations, Internet usage and electronic commerce were not thriving due to a lack of localized content. Google’s localized sites shall help provide a means of rectifying this situation, ensuring that Internet users in developed and developing nations have access to substantive content that is relevant to their lives.

While the development and deployment of specific localized sites will depend upon global and local demand and the technological integration of new gTLDs into the larger Internet fabric, Google’s goal is to continually expand its usage of localized sites in the top-level domain.

Registry Services


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

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
- Google DNS hosting and service association

“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.〈TLD〉google〈⁄TLD〉〉 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.

23.10 Google DNS Hosting and Service Association

This Google Registry service causes the domain name to be associated with the Google Calendar service, so that DNS for second-level domains (SLD) within the TLD will automatically resolve to the relevant Google service.

When a domain is initially registered, the DNS hosting service automatically becomes active, which will cause the nameservers associated with the Google Registry to be automatically changed to a specific set of nameservers operated by Google (e.g., ns1.google.com and ns2.google.com). These nameservers will operate on the same Google infrastructure used to host the Google Registry’s own zone data, and will therefore offer equivalent levels of reliability, security, and performance. Client-initiated updates to the name servers for the domain name will not be accepted and the server will respond with an error type 2304 - “Object status prohibits operation”.

Google will maintain a database with an association between individual SLDs and one or more specific Google services. In the case of the .cal TLD, all SLDs will be automatically associated with the Calendar service. Depending on the specific services associated with a domain name, zone data will be generated within the SLD zone with the appropriate resource records required in order to properly operate the service. For association with the Calendar service, this may include creating MX, A, and AAAA records at the apex of the zone as well as A records for the www and calendar labels. These resource records would be dynamically (but infrequently) updated to seek to ensure that the end user would always be directed to the appropriate Google servers to handle requests for the relevant service.

The SLD will be associated with a particular user’s Calendar account by means of the Account Ownership EPP Extension, as described in Question 25. This association will be required during the registration process, and will allow Google to serve the appropriate content for the TLD.

Sample zone data demonstrating the general model of DNS provisioning for these TLDs is included below:

*** Example .cal TLD zone file: ***
$ORIGIN cal.
$TTL 172800
@ IN SOA ns1.google.com. kmagal.google.com. (
2012033000 ; serial
7200 ; refresh (2 hours)
1800 ; retry (30 min)
1209600 ; expire (2 weeks)
300 ; negative (5 min)
)

NS ns1.google.com.
NS ns2.google.com.

example 86400 IN NS ns1.google.com.
86400 IN NS ns2.google.com.
86400 IN NS ns3.google.com.
86400 IN NS ns4.google.com.

*** Example example.cal zone file: ***
$ORIGIN example.cal.
$TTL 172800
@ IN SOA ns1.google.com. soncavu.google.com. (
2012033000 ; serial
7200 ; refresh (2 hours)
1800 ; retry (30 min)
1209600 ; expire (2 weeks)
300 ; negative (5 min)
)

NS ns1.google.com.
NS ns2.google.com.
NS ns3.google.com.
NS ns4.google.com.

MX 5 cal-smtp-in.l.google.com.
MX 10 alt1.cal-smtp-in.l.google.com.
MX 20 alt2.cal-smtp-in.l.google.com.

@ 600 IN A 192.0.2.1
600 IN AAAA 2001:0DB8::1

www 600 IN A 192.0.2.1
600 IN AAAA 2001:0DB8::1

calendar 600 IN A 192.0.2.1
600 IN AAAA 2001:0DB8::1

Demonstration of Technical & Operational Capability


24. Shared Registration System (SRS) Performance

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

25. Extensible Provisioning Protocol (EPP)

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, this gTLD will also include special EPP extensions for account ownership. This extension is described in detail in the attachment “Q25_Account Ownership EPP Extension”.

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.

26. Whois

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

Response:
Domain Name: EXAMPLE.cal
Domain ID: D424242-cal
WHOIS Server: WHOIS.nic.cal
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.cal
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.cal
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.cal
Name Server: NS01.EXAMPLEREGISTRAR.cal
Name Server: NS02.EXAMPLEREGISTRAR.cal
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.

27. Registration Life Cycle

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.cal⁄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.cal⁄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.cal⁄abuse that will provide the contact information for the Abuse Point of Contact. The nic.cal⁄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.

29. Rights Protection Mechanisms

                                             
29. Rights Protection Mechanisms

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) intends to operate this gTLD as a secure and closed registry, and does not plan to offer domain name registrations to third-parties. Charleston Road Registry (CRR) will employ a stringent verification process to establish that every prospective registrant meets the registration criteria. The security of the gTLD is enhanced by the fact that only CRR and its affiliates will be eligible to register domains. In addition to this verification process, the registry promises to incorporate the following Rights Protection Mechanisms.

29.1. Rights Protection Mechanisms – Sunrise Period

Operation of a closed gTLD with no third-party registrants should mitigate concerns of abusive registrations. Nonetheless, subject to the Sunrise Eligibility Requirements (SERs) outlined herein, CRR will offer a Sunrise Period of 60 days for owners of trademarks listed in the Trademark Clearinghouse to claim domain names that contain a second level consisting of an identical match to their listed trademarks. 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”) who 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, namely, employees and⁄or affiliates of CRR; (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 intends to utilize its parent company Google Inc. as its registrar, though it reserves the right to contract with other ICANN-accredited registrars in the future. CRR is committed to reducing abusive registrations, and will ensure that its registrar operates accordingly.

29.6. Rights Protection Mechanisms – Pre-Authorization and Authentication

It is anticipated that only Google and its affiliates will be eligible to register domain names within the gTLD. At no time during the life of the registry will CRR plan to offer domain name registrations to third-parties. CRR will staff an internal team that will pre-approve all registrations made in the gTLD by CRR and⁄or Google. CRR will thus verify that every prospective registrant is with CRR, Google or another affiliate of CRR.

In order to ensure that only Google and its authorized affiliates are authorized to register and operate domain names within the gTLD, 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: Summary of the security policy for the proposed registry

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.



© Internet Corporation For Assigned Names and Numbers.