New gTLD Application Submitted to ICANN by: NTT Resonant Inc.

Application Downloaded On: 04 Nov 2014

String: goo

Application ID: 1-1810-48580

Applicant Information

1. Full legal name
NTT Resonant Inc.

2. Address of the principal place of business
Granparktower, 3-4-1 Shibaura Minato-ku, Tokyo - 108-0023 JP

3. Phone number
+81 3 6703 6000

4. Fax number
+81 3 5476 2688

5. If applicable, website or URL
http://www.nttr.co.jp/

Primary Contact

6(a). Name
Yasushi Tsuruki

6(b). Title
Manager

6(c). Address

6(d). Phone Number
+81 3 6703 6310

6(e). Fax Number
+81 3 5476 2683

6(f). Email Address
gmo-gtld@nttr.co.jp

Secondary Contact

7(a). Name
Masahiro Arata

7(b). Title
assistant section chief

7(c). Address

7(d). Phone Number
+81 3 6703 6101

7(e). Fax Number
+81 3 5476 2683

7(f). Email Address
gtld@nttr.co.jp

Proof of Legal Establishment

8(a). Legal form of the Applicant
Corporation

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

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.

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
Name
Position
Hidemune SUGAHARADirector ?part time?
Kazuhiko KUSHIMADirector ?part time?
Kouichi TAKAHARADirector ?part time?
Masahiro WAKAIRepresentative Director, President
Shinji TANAKADirector?part time?
Takashi TANIGUCHIDirector?part time?
Takeshi NATSUNODirector ?part time?
Toshio NISHIYAMAManaging Director
Youichiro TAKAYADirector?part time?

11(b). Name(s) and position(s) of all officers and partners
Name
Position
Representative Director, President
Masahiro WAKAIre

11(c). Name(s) and position(s) of all shareholders holding at least 15% of shares
Name
Position
NTT Communications CorporationNot Applicable
NTT DOCOMO, 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.
goo


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



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



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



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



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



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



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



15A. If an IDN, upload IDN tables for the proposed registry. An IDN table must include:
  1. the applied-for gTLD string relevant to the tables,
  2. the script or language designator (as defined in BCP 47),
  3. table version number,
  4. effective date (DD Month YYYY), and
  5. contact name, email address, and phone number.
    Submission of IDN tables in a standards-based format is encouraged.



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



15C. List any variants 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.

The .goo string and A-Label were developed in line with and checked against the eligibility, stability and policy criteria as stated in the ICANN Applicant Guidebook - version 2012-01-11. The results of those checks are as follows:

- The string has less than 63 characters;
- The string in ASCII is composed of three or more visually distinct characters;
- The ASCII label consists entirely of letters;
- The string is not a reserved name as shown in section 2.2.1.2.1
- Reserved Names of the ICANN Applicant Guidebook - version 2012-01-11; and
- .goo is not identical or similar to any of the top 10 invalid TLDʹs responsible for the majority of DNS pollution, as referenced in the Security and Stability Advisory Committee (SSAC)ʹs report on this topic at http:⁄⁄www.icann.org⁄en⁄committees⁄security⁄sac045.pdf. It is likely that the .goo has not already been queried with meaningful frequency at the root. Therefore, it is unlikely that .goo will inherit significant invalid query traffic.

Due to the positive results of these checks, NTT Resonant Inc. does not believe that the .goo gTLD will be subject to any operational or rendering problems.


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



18A. Describe the mission/purpose of your proposed gTLD.

The mission and purpose of the new restricted .goo gTLD is to benefit internet users by ensuring increased trust, convenience and utility.

The .goo gTLD will create a new generation gTLD serving the interests of end users by providing an authoritative Internet space where an internet search engine and web portal site ʺgooʺ will communicate information, services and resources to internet users. The use of the .goo gTLD will be controlled by NTT Resonant Inc. (NTT Resonant). The majority of the anticipated domain name registrations in .goo will be used in the promotion and communication of the goo brand, as a user-friendly portal site giving access to a variety of services, provided by a secure and innovative company. A subset of domain names has the potential to be created and used in the communication and marketing purposes, with internet users assured of brand authenticity.

NTT Resonant, jointly owned by NTT Communications Corporation (a long-distance and international telecommunication carrier, a wholly-owned subsidiary of Nippon Telegraph and Telephone Corporation (NTT) founded in May 1999) and NTT DOCOMO, INC. (a mobile communications carrier and a subsidiary of NTT founded in August 1991), is one of the NTT Group companies. NTT Group consists of NTT (a holding company), 756 subsidiaries and 102 affiliated companies focusing on the businesses around regional communication, long-distance and international telecommunications, mobile communications and data communications. NTT Group has consolidated operating revenues: 10.3 trillion yen, operating income: 1.2 trillion yen, total assets: 19.7 trillion yen and it has over 219,000 employees (as of 31 March 2011).

NTT Resonant is a well-recognized portal business operator (via the portal site ʺgooʺ) and a provider of versatile internet services. The name ʺgooʺ symbolizes NTT Groupʹs goal to expand its global network; ʺgʺ stands for ʺglobalʺ and ʺooʺ represents the infinity symbol. NTT Resonant provides over 70 different services on ʺgooʺ such as information exchange via ʺTeach me! Gooʺ, internet research⁄search engine business showing results in a unique way by integrating results from Google with its own service, groupware services software as a service (SaaS), online store operation and information services (on topics such as weather, news, sports, TV programs, financial news and business). NTT Resonant has been ranked as 9th in ʺNet View 2011.10ʺ web audience rating conducted by Nielsen NetRatings Japan Inc. and as 36th out of 500 sites of leading Japanese companies and organizations in ʺWeb Brand Survey 2011-Octoberʺ conducted by Nikkei BP Consulting Inc. NTT Resonant aims to go far beyond its customersʹ expectations by providing a sense of ʺdiscoveryʺ through easy access to services and relevant information in a user-friendly approach. NTT Resonant seeks to proactively foster consumer trust and continuous innovation in all its activities, to provide internet users with a sense of security and authenticity of the ʺgooʺ brand.

Business activities are increasingly conducted over the internet, allowing for greater levels of interaction between businesses and customers. As a result, both businesses and end users benefit from ease of interaction and a wider range of choices with lower transaction costs. However, the development in this arena in the current domain name system has exposed both businesses and consumers to increased criminal activities over the internet, including data breach, hacking and phishing. These sophisticated criminal activities cause reputational damage to businesses as internet users lose consumer confidence and trust with the businesses targeted by such criminal activities. The .goo gTLD will facilitate greater trust and assurance from internet users connecting with NTT Resonant online, whilst still allowing convenient and efficient interaction.

NTT Resonantʹs mission and purpose of the proposed new gTLD share ICANNʹs initiatives to promote public interest. NTT Resonant is committed to contribute towards achieving such initiatives in line with ICANNʹs Affirmation of Commitments, which includes:
- consumer trust: the .goo gTLD registry will be operated in a centralized manner with a restrictive registration policy. Registration of domain names will only be available to NTT Resonant, which will provide added consumer trust that .goo domain names are trustworthy. As .goo domain names are subject to registration standards, policies and procedures under NTT Resonantʹs control, this eliminates the possibility of malicious conduct within the .goo domain space;
- competition: the proposed new gTLD is not intended to instigate competition and consumer choice among prospective registrants. Instead it is anticipated to contribute to ICANNʹs initiatives to promote public interest through its operation focused on promoting consumer trust. Increased trust in .goo will drive existing and new top level domain (TLD) registry operators to make improvements in mechanisms to improve consumer trust of their TLDs; and
- consumer choice: the proposed new gTLD will enable user-driven improvements and innovations assisting NTT Resonantʹs marketing efforts through its ability to create new second and third level domain names on demand. These names will provide the consumers with more choices for interacting with NTT Resonant. As NTT Resonant has effective control over the registration and use of domain names under .goo domain space, this will also contribute towards general service innovations on the internet.

Given the restricted nature of the .goo gTLD, the projected number of registration is likely to be limited. It is anticipated that only a small number of domain names (between 5-30) will be registered in the first few years. However, the number of domain registrations is likely to increase as NTT Resonant develops and implements new services and marketing campaigns. As the new .goo gTLD expands and evolves, NTT Resonant may consider offering the use of second level domain names to its customers and⁄or partner organizations at a later date. In this endeavor, NTT Resonant will continue to comply with all operational, technical and policy requirements, as well as maintaining consumer trust and the stability of the internet. NTT Resonant will keep ICANN reasonably informed of any material developments relating to .goo including compliance with the continued operations instrument obligations as set out in Specification 8 of the Registry Agreement.

NTT Resonant will utilize Internationalized Domain Names (IDNs) at the second level in Japanese language. The use of IDNs will allow internet users to engage with .goo in their native language, creating a more positive user experience and encouraging diversity. As the use of the .goo gTLD evolves, it is anticipated that the use of IDNs, including additional languages, may increase within the .goo domain space.

NTT Resonant is well-recognized as a portal business operator via its portal site ʺgooʺ with the ʺgooʺ trademarks registered in Japan for (but not limited to) the following categories: classes 35 (advertising, business management, business administration), 36 (insurance, financial affairs, monetary affairs, real estate affairs), 37 (building construction, repair, installation services), 38 (telecommunications), class 39 (transport, packaging and storage of goods) and 42 (scientific and technological services and research and design relating hereto).

NTT Resonant has 13 existing domain names containing the ʺgooʺ trademark in the following spaces including:
- gTLDs: simplegoo.com, super-goo.com, gooapis.com, gooapis.biz, gooblog.info, gooblog.biz
- Country-Code TLDS (ccTLDs): goo.ne.jp, goo.jp, gooapis.jp, gooblog.jp.

Recently, NTT Resonant was successful in securing sunrise application for the .biz, .info, .net and .org domain spaces based on existing trademark registration.


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

18(b)i.
The key goals of the proposed new .goo gTLD are in line with ICANNʹs Affirmation of Commitments: to promote consumer trust, competition and consumer choice. NTT Resonant also seeks to foster its online reputation and provide an authoritative internet space through which NTT Resonant is able to communicate with its customers directly and effectively. The ability to create domain names on demand related to specific marketing, specialty service and product development supports these goals. Strengthened security measures, service levels and more effective functionality will provide a trusted and positive experience for users of the goo portal site.


18(b)ii.
It is anticipated that the proposed .goo gTLD will make positive contributions to the wider internet community by providing:

Differentiation (Increased trust):
The .goo gTLD will simplify how internet users interact with NTT Resonant by providing a distinctive domain space. Internet users will be able to directly navigate intuitively to .goo gTLD site, saving time and resources searching for an official site. The current domain name system has shown that it is vulnerable to malicious abuses due to registration of domain names which seek to exploit consumer confusion. NTT Resonant can address some of these vulnerabilities by maintaining complete control over the domain names registered under the .goo domain space. Together with consumer trust, internet users will be able to rely on the authoritativeness of the domain names under .goo domain space, which will differentiate interaction between internet users and NTT Resonant, by offering the users more security.

Competition:
The differentiation of .goo gTLD as a trusted site for NTT Resonant will drive existing and new TLD registry operators to make improvements in mechanisms to improve consumer trust of their TLDs. Internet users will be encouraged to interact with domain names under .goo domain space. As a result .goo will have a flow on effect to enable increased competition. Therefore, the benefits of the proposed .goo will be distributed not only to its direct customers, but to the internet community at large forcing improved services and competitive pricing in the market place.

Innovation:
With the expansion of the internet community to all corners of the world, the existing TLD structure presents limitations, not only in the availability of domain names for registrants, but also to businesses and organizations establishing a coherent global online brand presence to meet their evolving business needs. It is often difficult to register a domain name in existing domain space due to unavailability of the desired name. Even when the desired domain name is available, it may come with a high price tag associated with a purchase of such desired name from a third party. NTT Resonant has the ability to create second or third level domain names including the use of IDNs on demand which are relevant to its customer base, services and products. This will particularly provide better support for users accessing the .goo gTLD on mobile devices. NTT Resonant will be able to combine its use of the domain space with innovative user focused marketing and services to address the currently unmet needs in the existing domain name system providing greater consumer choice.

Further, NTT Resonant is currently engaging proactively with third parties (who have existing trademark registration for ʺgooʺ in different categories) that may have an interest in the use of second level domain names in the .goo gTLD. NTT Resonant has undertaken this action in line with ICANNʹs Affirmation of commitments in promoting consumer choice through the creation of new second level domain names on demand by possible third parties. NTT Resonant will continue to have control over the use of such domain names through e.g. licensing arrangement with such third parties.


18(b)iii.
The proposed .goo gTLD will provide positive user experience, which meets the changing and growing needs of the global internet community. NTT Resonant will maintain control in the registration and use of domain names and will ensure that the new gTLD will only be used for purposes authorized by NTT Resonant. Therefore .goo gTLD will:
- provide an easy and intuitive reference and the point of access for internet users;
- represent authenticity thus promoting user confidence, free from potential false impersonation of unrelated third parties;
- direct internet users to relevant information in a timely manner by creating short domain names on demand;
- use IDNs intended to enable customers to interact directly in their native language;
- enhance security and minimize security risks by implementing necessary technical and policy measures;
- strengthen brand reputation and user confidence by eliminating user confusion; and
- prevent potential abuses in the registration process reducing overall costs to businesses and users.

The .goo gTLD should address the concerns better that the current domain name system is open to potential malicious abuse and user confusion in the registration processes. Although the current system allows an eligible party to lodge a claim through existing Uniform Domain Name Dispute Resolution Policy (UDRP) or other dispute resolution processes, the .goo will reduce potential abuses in the
registration processes and overall costs to internet users. User confidence in the domain name system will be strengthened, which will ultimately contribute towards promoting ICANNʹs core values in benefiting the public interest.


18(b)iv.
The proposed registration policy is attached in response to Question 28.

Only NTT Resonant will be eligible to register domain names in .goo at this stage. The domain name registration processes will address the requirements mandated by ICANN, including rights abuse prevention measures.


18(b)v.
NTT Resonant is committed to protection of privacy and confidential information in accordance with its objective of increasing consumer trust and providing a safe and legitimate internet space for internet users. Privacy and confidential information will be protected in accordance with all applicable laws and regulations relating to internet security, privacy and userʹs confidential information. NTT Resonant complies with all relevant requirements and standards for the internet services industry as well as compliance with all applicable legislation on protection of personal information including the Guideline on Protection of Personal Information in Telecommunications Business (Japan), as required by the Japanese Ministry of Internal Affairs and Communications.

NTT Resonant also has implemented its own privacy policy to demonstrate its commitment to the protection of user privacy and confidential information. NTT Resonantʹs privacy policy includes provisions regarding:
1. collection of personal information;
2. use and disclosure of personal information;
3. handling of personal information;
4. security measures implemented by NTT Resonant;
5. access to personal information held by NTT Resonant; and
6. compliance with laws.

NTT Resonant is committed to abide by all laws and regulations related to privacy protection and will only acquire personal information, as necessary, in a fair and lawful manner. Personal information obtained by NTT Resonant will only be used:

As the .goo gTLD will only be registered by NTT Resonant, the amount of data that will be collected for the purposes of operating the gTLD and made publicly available in the WHOIS database will be very limited. NTT Resonant will provide a publicly available and searchable WHOIS look up facility, where information about the domain name status, registrant information including administrative and technical contact details can be found in accordance with Specification 4 of the Registry Agreement. In order to prevent misuse of the WHOIS look up facility, NTT Resonant will utilize measures including a requirement where any person submitting a WHOIS database query is required to read and agree to the terms and conditions in accordance with the registration policies. This will include the terms of use that the WHOIS database is provided for information purposes only and that the user agrees not to use the information for any other purposes such as allowing or enabling the transmission of unsolicited commercial advertising or other communication.

NTT Resonant will deploy Domain Name System Security Extensions (DNSSEC) which is intended to benefit both NTT Resonant and its users interacting with ʺgooʺ services online. DNSSEC provides additional security by validating information in the transmission, therefore it is intended to benefit those who publish information in the domain name system (DNS) and the users who retrieve information from the new gTLD. NTT Resonant already implements measures to protect privacy or confidential information of its users against misuse, loss, alteration and unauthorized access. Such measures include accreditation under the PrivacyMark system, which complies with Japan Industrial Standards (JIS Q15001:2006 personal information protection management system) and the use of Secure Sockets Layer (SSL) encrypted communication.

NTT Resonant will continue to apply all security measures currently implemented and will comply with all other policies and practices required by ICANN in the Registry Agreement and any relevant Consensus Policy for protecting the privacy and confidential information of registrants and users in the new .goo domain space.


18(b)vi.
The proposed new gTLD will be publicized by a media plan to promote recognition of the new gTLD within the internet community to be a trusted site and as a sign of authenticity. During the initial stage of the operation of the proposed new gTLD, it is anticipated that internet users will be re-directed to current websites.

However, over time, it is foreseen that communication to the internet community of the existence of the proposed new gTLD and encouragement to utilize the trusted site will contribute towards minimizing malicious abuses and protecting internet users.


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

As a restricted gTLD, registration will only be open to internal users at this stage and no third parties will be able to register domain names under .goo domain space. Therefore, it is not anticipated that third party trademark owners (other than trademark owners of ʺgooʺ trademarks, who may have an option to use the second level domain names under the .goo gTLD) will incur costs in relation to the .goo gTLD. The affiliate entities and any other parties who meet the eligibility criteria under the registration policy wishing to register domain names must ensure that all the policy requirements for registration are satisfied. NTT Resonant will utilise the services of the proposed Trademark Clearinghouse to ensure that domain names registered and the use of those domain names, do not infringe any registered third party intellectual property rights.

It is estimated that time and money spent by consumers who have been targeted by malicious abuse in utilising services on the internet will reduce over time as a result of the new, trusted .goo gTLD.


18(c)i.
The initial registration of the proposed new gTLD will be restricted to NTT Resonant and NTT Resonant is intended to be the registrant under the .goo gTLD. Therefore conflicts between multiple applications are not anticipated to occur.


18(c)ii.
This gTLD will only be registered by NTT Resonant at this stage, so pricing incentives are not applicable or relevant.


18(c)iii.
This gTLD will only be registered by NTT Resonant at this stage, so pricing incentives or pricing increases are not applicable or relevant as no additional fees are to be charged.


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

No


20A. Provide the name and full description of the community that the applicant is committing to serve. In the event that this application is included in a community priority evaluation, it will be scored based on the community identified in response to this question. The name of the community does not have to be formally adopted for the application to be designated as community-based.



20B. Explain the applicant’s relationship to the community identified in 20(a).



20C. Provide a description of the community-based purpose of the applied-for gTLD.



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



20E. Provide a complete description of the applicant’s intended registration policies in support of the community-based purpose of the applied-for gTLD. Policies and enforcement mechanisms are expected to constitute a coherent set.



20F. Attach any written endorsements for the application from established institutions representative of the community identified in 20(a). An applicant may submit written endorsements by multiple institutions, if relevant to the community.



21A. Is the application for a geographic name?

No


22. Describe proposed measures for protection of geographic names at the second and other levels in the applied-for gTLD. This should include any applicable rules and procedures for reservation and/or release of such names.

NTT Resonant Inc. is not currently planning to utilize geographic names at the second and other levels in the .goo gTLD. However, and notwithstanding the absence of geographic names in NTT Resonant Inc.ʹs forward planning and use intentions, NTT Resonant Inc. has considered the requirements necessary should it, at a later date, seek to obtain ICANN approval for the use of geographic names as follows.

NTT Resonant Inc. generally respects and abides by the GACʹs Principles regarding New gTLDs, dated March 28, 2007. In particular, NTT Resonant Inc. adheres to and⁄or intends to adhere to the recommendations directed towards new registry operators in Sections 2.1, 2.4, 2.7(b) On the other hand, NTT Resonant Inc. assumes that several of the recommendations directed towards new registry operators, in general, are less applicable in the case of Single-Registrant operational models such as .goo than in an completely open Registry model. These include without limitation Sections 2.2, 2.3, 2.7(a) and 2.9.

In order to comply with the requirements of the Registry Agreement, Specification 5, and as with all other domains in the .goo gTLD, all Two-character labels (Section 2) and Country and Territory Names (Section 5) will be initially reserved. However, NTT Resonant Inc. believes that the use of geographic terms can provide great benefit and simplicity to internet users because these terms are intuitive ways to resolve to NTT Resonant Inc.ʹs content that is specifically relevant and targeted to users in the particular geographic region and in line with local customs, laws and regulations. The use of the geographic terms will be valuable to internet users because they can be reassured that the content that they are viewing is relevant to their local situation thus mitigating the risk of unnecessary user confusion.

NTT Resonant Inc. intends to use any Two-character label and⁄or Country or Territory Name domains in NTT Resonant Inc.ʹs discretion, and to participate in or implement a process by which any Government may reasonably object to that use. NTT Resonant Inc. envisions a number of possible scenarios for ensuring Government agreement to the use of Country and Territory names. These will be explored in detail with ICANN and the Governmental Advisory Committee to ensure a mutually agreeable solution. Scenarios range from at a minimum; NTT Resonant Inc. informing the Chair of the Governmental Advisory Committee (GAC) to ICANN in writing of its proposed use of geographic terms and provide Governments who wish to do so with an opportunity to block the use of their relevant name in the .goo gTLD. Other plausible scenarios would include;

SCENARIO 1 (Letter to GAC):
In advance of any use of geographical names NTT Resonant Inc. will send a letter to the chair of the Governmental Advisory Committee (GAC) informing the GAC of its intention to use geographical names in the .goo gTLD. The letter will outline the reasons for using geographical names and provide Governments with the opportunity to contact NTT Resonant Inc. within 90 days to reserve their respective geographical name from use in the .goo gTLD. Should a Government inform NTT Resonant Inc. that it wishes to reserve the use of their respective geographical name, the name will remain reserved for the duration of NTT Resonant Inc.ʹs registry agreement with ICANN. The opportunity to reserve a name will be offered to Governments free of charge.

SCENARIO 2 (Letter informing individual Governments):
In advance of any use of geographical names NTT Resonant Inc. will send a letter to the Government concerned and inform it of NTT Resonant Inc.ʹs intention to use geographical names in the .goo gTLD. The letter will outline the reasons for using geographical names and provide the Government with the opportunity to contact NTT Resonant Inc. within 90 days to reserve its respective geographical name from use in the .goo gTLD. Should the Government inform NTT Resonant Inc. that it wishes to reserve the use of its respective geographical name, the name will remain reserved for the duration of NTT Resonant Inc.ʹs registry agreement with ICANN. The opportunity to reserve a name will be offered to the Government free of charge.

SCENARIO 3 (Letter requesting permission from individual Government):
In advance of any use of geographical names NTT Resonant Inc. will send a letter to the Government concerned and inform it of NTT Resonant Inc.ʹs intention to use geographical names in the .goo gTLD. The letter will outline the reasons for using geographical names and request the Governmentʹs approval or non-objection to the proposed use of the geographical name. Should the Government not respond to the NTT Resonant Inc. within 90 days, NTT Resonant Inc. will understand this to mean that the Government does not object to NTT Resonant Inc.ʹs proposed use of the geographical name. However should the Government at a later stage contact NTT Resonant Inc. and request that the geographical name no longer be used, NTT Resonant Inc. will work in good faith with the Government to try to find a mutually agreeable solution.

Alternatively: However should the Government at a later stage contact NTT Resonant Inc. and request that the geographical name no longer be used, NTT Resonant Inc. will work in good faith with the Government to try to find a mutually agreeable solution. If such a solution cannot be found NTT Resonant Inc. will respect the Governmentʹs wishes and reserve the name from use without cost to the Government concerned.

Generally, it is extremely unlikely that NTT Resonant Inc.ʹs tightly controlled use of any cc.goo or countryname.goo domain name could be confusing or detrimental to users, or otherwise offensive to any country. Nor is it likely to be detrimental to the operator of a country code top level domain. To the extent that use of any .goo domain was ever deemed confusing or offensive, NTT Resonant Inc. has a strong desire to resolve the situation quickly and respectfully to any affected Governmentʹs sovereign interests. NTT Resonant Inc. will ensure that its designated abuse contact is aware of the additional sensitivities that may potentially arise with respect to use of cc.goo or countryname.goo domains, such that any complaints of this nature are prioritized accordingly. NTT Resonant Inc. will not use geographic names until ICANN has approved such use.


23. Provide name and full description of all the Registry Services to be provided. Descriptions should include both technical and business components of each proposed service, and address any potential security or stability concerns.
The following registry services are customary services offered by a registry operator:
  1. Receipt of data from registrars concerning registration of domain names and name servers.
  2. Dissemination of TLD zone files.
  3. Dissemination of contact or other information concerning domain name registrations (e.g., port-43 WHOIS, Web- based Whois, RESTful Whois service).
  4. Internationalized Domain Names, where offered.
  5. DNS Security Extensions (DNSSEC). The applicant must describe whether any of
    these registry services are intended to be offered in a manner unique to the TLD.
Additional proposed registry services that are unique to the registry must also be described.

NTT Resonant Inc. has chosen GMO Registry, Inc as the registry infrastructure provider for .goo. Any information regarding technical and operational capability of the proposed the TLD registry (answers to questions 23 – 44) therefore refers to GMO’s registry infrastructure systems.
 GMO Registry, Inc (GMO) is working with CentralNic Ltd to establish its gTLD registry system. Please see Appendix 23.1 for the acceptance letter from CentralNic. Any information regarding technical and operational capability of the proposed TLD registry (answers to questions 23 – 44) therefore refers to a new registry installed in and operated from Tokyo, Japan, replicating CentralNic’s registry infrastructure systems and set up and managed under CentralNic’s supervision.
GMO hereby explicitly confirms that all registry services stated below are engineered and will be provided in a manner compliant with the new gTLD Registry Agreement, ICANN consensus policies (such as Inter-Registrar Transfer Policy and AGP Limits Policy) and applicable technical standards. Except for the registry services described, no other services will be provided by the Registry that relate to (i) receipt of data from registrars concerning registrations of domain names and name servers; (ii) provision to registrars of status information relating to the zone servers for the TLD;(iii) dissemination of TLD zone files; (iv) operation of the Registry zone servers; or (v) dissemination of contact and other information concerning domain name server registrations in the TLD as required by the Registry Agreement.
There are no other products or services, except those described above that the Registry Operator would provide (i) because of the establishment of a Consensus Policy, or (ii) by reason of GMO being designated as the Registry Operator.
Any changes to the registry services that may be required at a later time in the course of GMO operating the TLD registry will be addressed using rules and procedures established by ICANN such as the Registry Services Evaluation Policy.
GMO proposes to operate the following registry services, utilising CentralNic's registry system as the model for the new Registry, to be built and managed with the support and under the supervision of CentralNic:

23.1. Receipt of Data From Registrars
GMO Registry will operate a Shared Registry System (SRS) for the TLD. The SRS consists of a database of registered domain names, host objects and contact objects, accessed via an Extensible Provisioning Protocol (EPP) interface, and a web based Registrar Console. Registrars will use these interfaces to provide registration data to the registry.
The SRS will be hosted in the primary operations centre in Tokyo, Japan. The primary operations centre comprises a resilient, fault-tolerant network infrastructure with multiple high quality redundant links to backbone Internet carriers. The primary operations centre is hosted in a telco-grade data centre and boasts significant physical security capabilities, including 24x7 patrols, CCTV and card-based access controls.
CentralNic's existing SRS system currently supports more than 350,000 domain names managed by over 1,500 registrars, and this system will be replicated for GMO.  GMO will have effective and efficient 24x7 customer support capabilities to support these domain names and registrars, and this capability will be expanded to meet the requirements of the TLD and provide additional capacity during periods of elevated activity (such as during Sunrise periods).
The SRS and EPP systems are described more fully in §24 and §25. The Registrar Console is described in §31.
EPP is an extensible protocol by definition. Certain extensions have been put in place to comply with the new gTLD registry agreement, ICANN Consensus Policies and technical standards:
  1. Registry Grace Period Mapping - compliant with RFC 3915
  2. DNSSEC Security Extensions - compliant with RFC 5910
  3. Launch Phase Extension - will be only active during the Sunrise phase, before the SRS opens for the general public. The extension is compliant with the current Internet Draft https://github.com/wil/EPP-Launch-Phase-Extension-Specification/blob/master/draft-tan-epp-launchphase.txt
More information on EPP extensions is provided in §25.
The SRS will implement and support all ICANN Consensus Policies and Temporary Policies, including:
23.2. Provision to Registrars of Status Information Relating to the Zone Servers
GMO will operate a communications channel to notify registrars of all operational issues and activity relating to the DNS servers which are authoritative for the TLD. This includes notifications relating to:
  1. Planned and unplanned maintenance;
  2. Denial-of-service attacks;
  3. Unplanned network outages;
  4. Delays in publication of DNS zone updates;
  5. Security incidents such as attempted or successful breaches of access controls;
  6. Significant changes in DNS server behaviour or features;
  7. DNSSEC key rollovers.
Notifications will be sent via email (to preregistered contact addresses), with additional notifications made via an off-site maintenance site and via social media channels.

23.3. Dissemination of TLD Zone Files
GMO will make zone files available via the Centralized Zone Data Access Provider according to specification 4, section 2 of the Registry Agreement.
GMO will enter into an agreement with any Internet user that will allow such user to access an Internet host server or servers designated by GMO and download zone file data. The agreement will be standardized, facilitated and administered by a Centralized Zone Data Access Provider (the “CZDA Provider”). GMO will provide access to zone file data using the file format described in Section 2.1.4 of Specification 4 of the New gTLD Registry Agreement.
GMO, through the facilitation of the CZDA Provider, will request each user to provide it with information sufficient to correctly identify and locate the user. Such user information will include, without limitation, company name, contact name, address, telephone number, facsimile number, email address, and the Internet host machine name and IP address.
GMO will provide the Zone File FTP (or other Registry supported) service for an ICANN-specified and managed URL for the user to access the Registry’s zone data archives. GMO will grant the user a non-exclusive, non-transferable, limited right to access GMO’s Zone File FTP server, and to transfer a copy of the top-level domain zone files, and any associated cryptographic checksum files no more than once per 24 hour period using FTP, or other data transport and access protocols that may be prescribed by ICANN.
GMO will provide zone files using a sub-format of the standard Master File format as originally defined in RFC 1035, Section 5, including all the records present in the actual zone used in the public DNS.
GMO, through the CZDA Provider, will provide each user with access to the zone file for a period of not less than three (3) months. GMO will allow users to renew their Grant of Access.
GMO will provide, and CZDA Provider will facilitate, access to the zone file to user at no cost.

23.4. Operation of the Registry Zone Servers
No matter how good the registration system, Internet users require that domain names resolve quickly and reliably. GMO’s DNS service provides name resolution for all domain names in the registry.
This service will be constructed on top of an already-operational worldwide publication/distribution system and network of name servers. These name servers employ IP-Anycast technology for scalable geographic redundancy, strong defense from Denial of Service attacks, high quality of service, and to give excellent response to widely geographically diverse clients.
DNSSEC and IPv6 are already fully integrated into this network and its component servers.
The DNS system fully complies with all relevant RFCs and all ICANN specifications, and has been engineered to ensure resilience and stability in the face of denial-of-service attacks, with substantial overhead and geographical dispersion.
The DNS system is described further in §35.

23.5. Dissemination of Contact and Other Information Concerning Domain Name Server Registrations
GMO will operate a Whois service for the TLD. The Whois service will provide information about domain names, contact objects, and name server objects stored in the Shared Registry System via a port-43 service compliant with RFC 3912. The Whois service will permit interested parties to obtain information about the Registered Name Holder, Administrative, Technical and Billing contacts for domain names in the TLD. The Whois service will return records in a standardised format that complies with ICANN specifications.
GMO will provide access to the Whois service at no cost to the general public.
The Whois service supports a number of features, including rate limiting to prevent abuse, privacy protections for natural persons, and a secure Searchable Whois Service. The Whois service is more fully described in §26.
Should ICANN specify alternative formats and protocols for the dissemination of Domain Name Registration Data, such as RDAP, GMO will implement such alternative specifications as soon as reasonably practicable.

23.6. DNSSEC
The TLD zone will be signed by DNSSEC. Zone files will be signed using NSEC3 with opt-out, following a DNSSEC Practice Statement detailed in §43 and based on RFC 6841.
The DNSSEC implementation complies with RFCs 4033, 4034, 4035, 4509 and follows the best practices described in RFC 4641. Hashed Authenticated Denial of Existence (NSEC3) will be implemented, which complies with RFC 5155. The SRS will accept public-key material from child domain names in a secure manner according to industry best practices (specifically the secDNS EPP extension, described in RFC 5910). GMO will also publish in its website the DNSSEC Practice Statements (DPS) describing critical security controls and procedures for key material storage, access and usage for its own keys and secure acceptance of registrants’ public-key material. GMO’s DNSSEC Practice Statement is based on RFC 6841.

23.7. Rights Protection Mechanisms
GMO will provide all mandatory Rights Protection Mechanisms that are specified in the Applicant Guidebook, namely the Trademark Claims Service and Sunrise service. All the required RPM-related policies and procedures such as UDRP, URS, PDDRP and RRDRP will be adopted and used in the TLD. More information is available in §29.
In addition to such RPMs, GMO may develop and implement additional RPMs that discourage or prevent registration of domain names that violate or abuse another party’s legal rights. GMO will include all ICANN mandated and independently developed RPMs in the registry-registrar agreement entered into by ICANN-accredited registrars authorised to register names in the TLD. GMO shall implement these mechanisms in accordance with requirements established by ICANN in each of the mandatory RPMs set forth in the Trademark Clearinghouse.
The "LaunchPhase" EPP extension (described above) will be used to implement an SRS interface during the Sunrise period for the TLD. Depending on the final specification for the Trademark Claims Service (details of which have not yet been published), an additional EPP extension may be required in order to implement this service. If this is necessary, the extension will be designed to minimise its effect on the operation of the SRS and the requirements on registrars, and will only be in place for a limited period while the Trademark Claims Service is in effect.

23.8. Registrar Support and Account Management
GMO will leverage CentralNic’s 16 years of experience of supporting over 1,500 registrars to provide high-quality 24x7 support and account management for registrars. CentralNic's experienced technical and customer support personnel will train local GMO staff in Tokyo to assist registrars during the on-boarding and OT&E process, and provide responsive personal support via email, phone and a web based support ticketing system.

23.9. Reporting to ICANN
GMO will compile and transmit a monthly report to ICANN relating to the TLD. This report will comply with Specification 3 of the New gTLD Registry Agreement.

23.10. Personnel Resources
 
23.10.1. Initial Implementation
The .goo registry system will be established on a new registry platform designed by CentralNic, and built and operated by GMO on its own dedicated infrastructure. The initial implementation of the registry system will be carried out jointly by both companies.
The implementation project has been divided into two separate tasks: the setup of the physical (network and server) infrastructure, which will be carried out by GMO, and the setup of the logical (software and database) infrastructure, which will be carried out by CentralNic.
For the implementation phase, GMO will assign the necessary personnel resources to complete its part of the project from its existing HR resources. The Full-Time Equivalent persons (FTEs) assigned by GMO to this phase of operations is described in Appendix 23.2.
CentralNic will also contribute personnel to the implementation team. The FTEs assigned to the project are shown in Appendix 23.3. These roles are funded by GMO under the agreement between GMO and CentralNic (see §46).
 
23.10.2 Ongoing Operation
Once established, the ongoing operation of the registry will be primarily carried out by GMO, with support and assistance from CentralNic. The Full-Time Equivalent persons (FTEs) assigned by GMO and CentralNic to this phase of operations are described in Appendices 23.2 and 23.3 CentralNic’s contribution to the ongoing operations of the system are funded by GMO under the agreement between GMO and CentralNic (see §46).
Ongoing operations are divided into three areas: Technical Operations, Technical Development, and Technical Support. The resources assigned to these areas are described below.

23.10.2.1. Technical Operations
Technical Operations refers to the deployment, maintenance, monitoring and security of the registry system, including the SRS and the other critical registry functions. Technical Operations staff design, build, deploy and maintain the technical infrastructure that supports the registry system, including power distribution, network design, access control, monitoring and logging services, and server and database administration. Internal helpdesk and incident reporting is also performed by the Technical Operations team. The Technical Operations team performs 24x7 monitoring and support for the registry system and mans the Network Operations Centre (NOC) from which all technical activities are coordinated.
During the initial implementation and startup of the registry system, the Technical Operations function of the registry will be conducted jointly by GMO and CentralNic. The FTEs assigned to this function by each company are described in Appendices 23.2 and 23.3. After three years from delegation, this function will be handed off to GMO’s engineering team, who will provide the Technical Operations function on an ongoing basis.

23.10.2.2. Technical Development
CentralNic’s Technical Development team develops and maintains the software which implements the critical registry functions, including the EPP, Whois, Zone File generation, data escrow, reporting, backoffice and web-based management systems (intranet and extranet), and open-source registrar toolkit software. All critical registry software has been developed and maintained in-house by this team and will be provided under license to GMO, together with the appropriate training to ensure the optimal operation of the registry.
CentralNic intends to maintain a Technical Development team consisting of the following positions. These persons will be responsible for maintaining and developing the registry software that will support GMO in operating the TLD: The estimated FTEs dedicated to the GMO registry platform (shown in Appendix 23.3) are drawn from the above personnel.

23.10.2.3. Technical Support
Technical Support refers to 1st, 2nd and 3rd line support for registrars and end-users. Areas covered include technical support for systems and services, billing and account management. Support personnel also deal with compliance and legal issues such as UDRP and URS proceedings, abuse reports and enquiries from law enforcement.
1st line support issues are normally dealt with by these personnel. 2nd and 3rd line support issues (relating to functional or operational issues with the registry system) are escalated to Technical Operations or Technical Development as necessary.
During the initial implementation and startup of the registry system, the Technical Support function of the registry will be conducted jointly by GMO and CentralNic. The FTEs assigned to this function by each company are described in Appendices 23.2 and 23.3. Once the initial implementation is completed and three years have passed since delegation, this function will be handed off to GMO’s engineering team, who will provide the Technical Support function on an ongoing basis.
GMO’s Technical Support team will be trained in accordance with CentralNic standards.
 
 
 


24. Shared Registration System (SRS) Performance:
describe

NTT Resonant Inc. has chosen GMO Registry, Inc as the registry infrastructure provider for .goo. Any information regarding technical and operational capability of the proposed TLD registry (answers to questions 23 – 44) therefore refers to GMO’s registry infrastructure systems.
 
The registry system that is being built by GMO closely follows the design of CentralNic’s own registry. A number of high-availability and resilience mechanisms will be in place to ensure that the SRS meets the availability requirements in Specification 10. They have already been deployed and proven in CentralNic’s system. They are described in the original response to Question 24 and elsewhere. Specifically, they are:
 
  1. Redundant edge routing infrastructure connected to the resilient data centre network, which itself is multi-homed to three different providers (NTT, Pacnet, JPIX). Additionally, GMO plans to obtain an additional independent transit link from a third party provider. This design will ensure that a failure on the provider network will not affect the availability of critical registry services.
 
  1. Redundant Juniper NetScreen SSG550M firewall devices configured in active high-availability mode protect against the failure of a single firewall device.
 
  1. Redundant core switching infrastructure and front-end load balancers protect against single or multiple failures within the network and application core.
 
  1. Resilient, clustered database system, which can continue to function even if all but one node in the cluster fails.
 
Additionally, the registry system has been designed to have enough capacity that periods of significantly higher volume – such as those commonly experienced at the launch of a new TLD – will not affect the performance or availability of the SRS to registrars.
 
Finally, the construction of a hot standby site in San Jose allows the registry to be rapidly restored in the event of a significant outage at the primary site in Tokyo.
 
24.1. Registry Type
GMO Registry, Inc.(GMO) will operate a "thick" registry, in which the registry maintains copies of all information associated with registered domains. Registrars maintain their own copies of registration information, thus registry-registrar synchronization is required to ensure that both registry and registrar have consistent views of the technical and contact information associated with registered domains. The Extensible Provisioning Protocol (EPP) adopted supports the thick registry model. See §25 for further details.

24.2. Architecture
Figure 24.1 provides a diagram of the overall configuration of the SRS. This diagram should be viewed in the context of the overall architecture of the registry system described in §32.
The SRS is hosted GMO’s primary operations centre in Tokyo, Japan. It will be connected to the public Internet by diverse upstream transit providers. Figure 32.1 provides a diagram of the outbound network connectivity. Interconnection with upstream transit providers is via two BGP routers that connect to the firewalls, which implement access controls over registry services.
Within the firewall boundary, connectivity is provided to servers by means of resilient gigabit ethernet switches implementing Spanning Tree Protocol.
The registry system will implement two interfaces to the SRS: the standard EPP system (described in §25) and the Registrar Console (described in §31). These systems will interact with the primary registry database (described in §33). The database is the central repository of all registry data. Other registry services also interact with this database.
GMO personnel will perform management of the registry system using an internal "Staff Console".

24.3. EPP System Architecture
A description of the characteristics of the EPP system is provided in §25. This response describes the infrastructure that supports the EPP system.
A network diagram for the EPP system is provided in Figure 24.2. The EPP system is hosted at the primary operations centre in Tokyo. During failover conditions, the EPP system operates from the hot standby site in San Jose, USA (see §34).
GMO’s EPP system will have a three-layer logical and physical architecture, consisting of load balancers, a cluster of front-end protocol servers, and a pool of application servers. Each layer can be scaled horizontally in order to meet demand.
Registrars establish TLS-secured TCP connections to the load balancers on TCP port 700. Load is balanced using DNS round-robin load balancing.
The load balancers pass sessions to the EPP protocol servers. Load is distributed using a weighted-least-connections algorithm. The protocol servers run the Apache web server with the mod_epp and mod_proxy_balancer modules. These servers process session commands (hello, login and logout) and function as reverse proxies for query and transform commands, converting them into plain HTTP requests which are then distributed to the application servers. EPP commands are distributed using a weighted-least-connections algorithm.
Application servers receive EPP commands as plain HTTP requests, which are handled using application business logic. Application servers process commands and prepare responses which are sent back to the protocol servers, which return responses to clients over EPP sessions.
Each component of the system is resilient: multiple inbound connections, redundant power, high availability firewalls, load balancers and application server clusters enable seamless operation in the event of component failure. This architecture also allows for arbitrary horizontal scaling: commodity hardware is used throughout the system and can be rapidly added to the system, without disruption, to meet an unexpected growth in demand.
The GMO EPP system will comprise of the following systems:
Load balancers: 2x IBM x3550M3 (2x Xeon E5620 2.4GHz 4C, 32GB mirrored, 6x 500GB SAS RAID10)
EPP Protocol Servers: 3x IBM x3550M3 (2x Xeon E5620 2.4GHz 4C, 32GB mirrored, 6x 500GB SAS RAID10)
EPP Application Servers: 6x IBM x3550M3 (2x Xeon E5620 2.4GHz 4C, 32GB mirrored, 6x 500GB SAS RAID10)

24.3.1. mod_epp
mod_epp is an Apache server module which adds support for the EPP transport protocol to Apache. This permits implementation of an EPP server using the various features of Apache, including CGI scripts and other dynamic request handlers, reverse proxies, and even static files. mod_epp was originally developed by Nic.at, the Austrian ccTLD registry. Since its release, a large number of ccTLD and other registries have deployed it and continue to support its development and maintenance. Further information can be found at http://sourceforge.net/projects/aepps. The SRS uses mod_epp to manage EPP sessions with registrar clients, and to convert EPP commands into HTTP requests which can then be handled by backend application servers.

24.3.2. mod_proxy_balancer
mod_proxy_balancer is a core Apache module. Combined with the mod_proxy module, it implements a load-balancing reverse proxy, and includes a number of load balancing algorithms and automated failover between members of a cluster. The SRS uses mod_proxy_balancer to distribute EPP commands to backend application servers.

24.4. Performance
GMO will perform continuous remote monitoring of its EPP system, and this monitoring will include measuring the performance of various parts of the system. As of writing, the average round-trip times (RTTs) for various functions of CentralNic’s EPP system, which will be used as a model for GMO, were as follows:
connect time: 52ms
login time: 46ms
hello time: 12ms
check time: 30ms
logout time: 13ms
These figures include an approximate latency of 2.4ms due to the distance between the monitoring site and the EPP system. They were recorded during normal weekday operations during the busiest time of the day (around 1300hrs UTC) and compare very favourably to the requirement of 4,000ms for session commands and 2,000ms for query commands defined in the new gTLD Service Level Agreement. RTTs for overseas registrars will be higher than this due to the greater distances involved, but will remain well within requirements.

24.5. Scaling
Horizontal scaling is preferred over vertical scaling. Horizontal scaling refers to the introduction of additional nodes into a cluster, while vertical scaling involves using more powerful equipment (more CPU cores, RAM etc) in a single system. Horizontal scaling also encourages effective mechanisms to ensure high-availability, and eliminate single points of failure in the system.
Vertical scaling leverages Moore's Law: when units are depreciated and replaced, the new equipment is likely to be significantly more powerful. If the average lifespan of a server in the system is three years, then its replacement is likely to be around four times as powerful as the old server.
For further information about Capacity Management and Scaling, please see §32.

24.6. Registrar Console
The Registrar Console is a web-based registrar account management tool. It provides a secure and easy-to-use graphical interface to the SRS. The Registrar Console will be hosted on a virtual platform at the primary operations centre in Tokyo. As with the rest of the registry system, during a failover condition it will be operated from the hot standby site in San Jose. The virtual platform is described in Figure 24.3.
The features of the Registrar Console are described in §31.
The virtual platform is a utility platform based on KVM that supports systems and services which do not operate at significant levels of load, and which therefore do not require multiple servers or the additional performance that running on "bare metal" would provide. The platform functions as a private cloud, with redundant storage and failover between hosts.

24.7. Quality Assurance
GMO will employ the following quality assurance (QA) methods:
24x7x365 monitoring provides reports of incidents to NOC
Quarterly review of capacity, performance and reliability
Monthly reviews of uptime, latency and bandwidth consumption
Hardware depreciation schedules
Unit testing framework
Frequent reviews by QA working group
Schema validation and similar technologies to monitor compliance on a real-time, ongoing basis
Additionally, CentralNic will use the following measures to ensure the quality of the registry software:
Revision control software with online annotation and change logs
Bug Tracking system to which all employees have access
Code Review Policy in place to enforce peer review of all changes to core code prior to deployment
Software that incorporates built-in error reporting mechanisms to detect flaws and report to Operations team
GMO and CentralNic will jointly use the following:
Four stage deployment strategy: development environment, staging for internal testing, OT&E deployment for registrar testing, then finally production deployment
Evidence-based project scheduling
Specification development and revision
Weekly milestones for developers
Gantt charts and critical path analysis for project planning
Registry system updates will be performed on an ongoing basis, with any user-facing updates (ie changes to the behaviour of the EPP interface) being scheduled at specific times. Disruptive maintenance is scheduled for periods during which activity is lowest.

24.8. Billing
GMO will operate a complex billing system for domain name registry services to ensure registry billing and collection services are feature rich, accurate, secure, and accessible to all registrars. The goal of the system is to maintain the integrity of data and create reports which are accurate, accessible, secured, and scalable. The foundation of the process is debit accounts established for each registrar. GMO will withdraw all domain fees from the registrar’s account on a per-transaction basis and will provide fee-incurring services (e.g., domain registrations, registrar transfers, domain renewals) to a registrar for as long as that registrar’s account shows a positive balance.
Once ICANN notifies GMO that a registrar has been issued accreditation, GMO will begin the registrar on-boarding process, including setting up the registrar's financial account within the SRS.

24.9. Registrar Support
GMO will provide a multi-tier support system on a 24x7 basis with the following support levels:
1st Level: initial support level responsible for basic customer issues. The first job of 1st Level personnel is to gather the customer’s information and to determine the customer’s issue by analyzing the symptoms and figuring out the underlying problem.
2nd Level: more in-depth technical support level than 1st Level support containing experienced and more knowledgeable personnel on a particular product or service. Technicians at this level are responsible for assisting 1st Level personnel solve basic technical problems and for investigating elevated issues by confirming the validity of the problem and seeking for known solutions related to these more complex issues.
3rd Level: the highest level of support in a three-tiered technical support model responsible for handling the most difficult or advanced problems. Level 3 personnel are experts in their fields and are responsible for not only assisting both 1st and 2nd level personnel, but with the research and development of solutions to new or unknown issues.
GMO will provide a support ticketing system for tracking routine support issues. This is a web-based system (available via the Registrar Console) allowing registrars to report new issues, follow up on previously raised tickets, and read responses from GMO’s support personnel.
When a new trouble ticket is submitted, it is assigned a unique ID and priority. The following priority levels are used: 
Normal: general enquiry, usage question, or feature enhancement request. Handled by 1st level support.
Elevated: issue with a non-critical feature for which a work-around may or may not exist. Handled by 1st level support.
Severe: serious issue with a primary feature necessary for daily operations for which no work-around has been discovered and which completely prevents the feature from being used. Handled by 2nd level support.
Critical: A major production system is down or severely impacted. These issues are catastrophic outages that affect the overall Registry System operations. Handled by 3rd level support.
Depending on priority, different personnel will be alerted to the existence of the ticket. For example, a Priority 1 ticket will cause a notification to be emailed to the registrar customer support team, but a Priority 4 ticket will result in a broadcast message sent to the pagers of senior operations staff including the CTO. The system permits escalation of issues that are not resolved within target resolution times.

24.10. Enforcement of Eligibility Requirements
The SRS supports enforcement of eligibility requirements, as required by specific TLD policies.

24.11. Interconnectivity With Other Registry Systems
The registry system is based on multiple resilient stateless modules. The SRS, Whois, DNS and other systems do not directly interact with each other. Interactions are mediated by a distributed network of databases, which replicate from the primary registry database, which is the single authoritative source of data for the registry as a whole. Individuals modules perform "CRUD" (create, read, update, delete) actions upon the database. For performance reasons, the remote Anycast Whois sites use a replicated subset of the primary database.
Changes to the primary database made by one module will affect the behaviour of other registry systems: for example, when a registrar adds the "clientHold" status to a domain object, this is recorded in the database. When a query is received for this domain via the Whois service, the presence of this status code in the database results in the "Status: CLIENT HOLD" appearing in the whois record. It will also be noted by the zone generation system, resulting in the temporary removal of the delegation of the domain name from the DNS.

24.12. Resilience
The SRS has a stateless architecture designed to be fully resilient in order to provide an uninterrupted service in the face of failure of one or more parts of the system. This is achieved by use of redundant hardware and network connections, and by use of continuous "heartbeat" monitoring allowing dynamic and high-speed failover from active to standby components, or between nodes in an active-active cluster. These technologies also permit rapid scaling of the system to meet short-term increases in demand during "surge" periods, such as during the initial launch of a new TLD.

24.12.1. Synchronisation Between Servers and Sites
GMO’s system will be implemented as multiple stateless systems which interact via a central registry database. As a result, there will only be few situations where synchronisation of data between servers is necessary:
Replication of data from the primary operations centre to the Anycast Whois sites (see §26).
Replication is also used to synchronise the primary operations centre with the hot standby site hosted in San Jose (see §34). Database updates are replicated to the standby site in real-time via a secured VPN.

24.13. Operational Testing and Evaluation (OT&E)
An Operational Testing and Evaluation (OT&E) environment is provided for registrars to develop and test their systems. The OT&E system replicates the SRS in a clean-room environment. Access to the OT&E system is unrestricted and unlimited: registrars can freely create multiple OT&E accounts via the Registrar Console.

24.14. Resourcing
The .goo registry system will be established on a new registry platform designed by CentralNic, and built and operated on GMO’s dedicated infrastructure. The project plan for this is described in §23. As can be seen in the Resourcing Chart found in Appendix 23.2, during the ongoing operations of the registry, GMO will contribute to the development and maintenance of this aspect of the registry system. This team will not work on specific registry subsystems full-time, but a certain percentage of their time will be dedicated to each area.
Additionally, GMO will draw upon CentralNic’s own team of engineers and developers, as described in the FTE resource assignment described in Appendix 23.3. This contribution is slightly less than one full-time position. CentralNic personnel will work closely with GMO during the initial implementation of the registry, and will provide technical support and advice during ongoing operations through Year 3. CentralNic will provide enhancements to the performance and functionality of the registry system to GMO under the terms of the agreement between the two companies.
 
 
 


25. Extensible Provisioning Protocol (EPP): provide a detailed description of the interface with registrars, including how the applicant will comply with EPP in RFCs 3735 (if applicable), and 5730-5734.
If intending to provide proprietary EPP extensions, provide documentation consistent with RFC 3735, including the EPP templates and schemas that will be used.
Describe resourcing plans (number and description of personnel roles allocated to this area).
A complete answer is expected to be no more than 5 pages. If there are proprietary EPP extensions, a complete answer is also expected to be no more than 5 pages per EPP extension.

NTT Resonant Inc. has chosen GMO Registry, Inc as the registry infrastructure provider for .goo. Any information regarding technical and operational capability of the proposed TLD registry (answers to questions 23 – 44) therefore refers to GMO’s registry infrastructure systems.
The Extensible Provisioning Protocol (EPP) is an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. EPP defines generic object management operations and an extensible framework that maps protocol operations to objects. EPP has become established as the common protocol by which domain registrars can manage domains, nameservers and contact details held by domain registries. It is widely deployed in the gTLD and ccTLD registry space.
CentralNic has operated its EPP system since 2005 and it currently operates at significant load in terms of registrars, sessions and transaction volumes. This system will be replicated for GMO Registry, Inc (GMO). GMO’s EPP system will be fully compliant with the following RFC specifications:
25.1. Description of Interface
EPP is a stateful XML protocol layered over TCP (see RFC 5734). Protected using lower-layer security protocols, clients exchange identification, authentication, and option information, and engage in a series of client-initiated command-response exchanges. All EPP commands are atomic (there is no partial success or partial failure) and designed so that they can be made idempotent (executing a command more than once has the same net effect on system state as successfully executing the command once).
EPP provides four basic service elements: service discovery, commands, responses, and an extension framework that supports definition of managed objects and the relationship of protocol requests and responses to those objects.
EPP servers respond to client-initiated communication (which can be either a lower-layer connection request or an EPP service discovery message) by returning a greeting to a client. The server then responds to each EPP command with a coordinated response that describes the results of processing the command.
EPP commands fall into three categories: session management, queries, and transform commands. Session management commands are used to establish and end persistent sessions with an EPP server. Query commands perform read-only object information retrieval operations. Transform commands perform read-write object management operations.
Commands are processed by a server in the order they are received from a client. The protocol includes features that allow for offline review of transform commands before the requested action is completed. In such situations, the response clearly notes that the command has been received but that the requested action is pending. The corresponding object then reflects processing of the pending action. The server will also notify the client when offline processing of the action has been completed. Object mappings describe standard formats for notices that describe completion of offline processing.
EPP uses XML namespaces to provide an extensible object management framework and to identify schemas required for XML instance parsing and validation. These namespaces and schema definitions are used to identify both the base protocol schema and the schemas for managed objects.

25.1.1. Objects supported
Registrars may create and manage the following object types in GMO’s EPP system:
25.1.2. Commands supported
GMO will support the following EPP commands:
25.2. EPP state diagram
Figure 25.1 describes the state machine for the EPP system. Clients establish a connection with the server, which sends a greeting. Clients then authenticate, and once a login session is established, submits commands and receive responses until the server closes the connection, the client sends a logout command, or a timeout is reached.

25.3. EPP Object Policies
The following policies apply to objects provisioned via the EPP system:

25.3.1. domains
  1. Domains must comply with the syntax described in RFC 1035 §2.3.1. Additionally, the first label of the name must be between 3 and 63 characters in length.
  2. Domains must have a registrant attribute which is associated with a contact object in the database.
  3. Domains must have an administrative contact attribute which is associated with a contact object in the database.
  4. Domains must have a technical contact attribute which is associated with a contact object in the database.
  5. Domains may have a billing contact attribute which is associated with a contact object in the database.
  6. Domains may have between 0 (zero) and 13 DNS servers. A domain with no name servers will not resolve and no records will be published in the DNS
  7. The host object model for domains is used rather than the host attribute model.
  8. Domains may have a number of status codes. The presence of certain status codes indicates the domain's position in the lifecycle, described further in §27.
  9. Where policy requires, the server may respond to a domain:create command with an "Object Pending" (1001) response. When this occurs, the domain is placed onto the pendingCreate status while an out-of-band validation process takes place.
  10. When registered, the expiry date of a domain may be set up to ten years from the initial date of registration. Registrars can specify registration periods in one-year increments from one to ten.
  11. When renewed, the expiry date of a domain may be set up to ten years from the current expiry date. Registrars can specify renewal periods in one-year increments from one to ten. Domains which auto-renew are renewed for one year at a time.
  12. Domains must have an authInfo code which is used to authenticate inter-registrar transfer requests. This authInfo code may contain up to 48 bytes of UTF-8 character data.
  13. Domains may have one or more DS records associated with them. DS records are managed via the secDNS EPP extension, as specified in RFC 5910.
  14. Only the sponsoring registrar of the domain may submit update, renew or delete commands for the domain.

25.3.2. Host objects
  1. Host names must comply with RFC 1035. The maximum length of the host name may not exceed 255 characters.
  2. In-bailiwick hosts must have an IPv4 address. They may optionally have an IPv6 address.
  3. Multiple IP addresses are not currently permitted.
  4. Sponsorship of hosts is determined as follows: if an object is in-bailwick (ie child of a domain in the database, and therefore also child to a TLD in the system), then the sponsor is the sponsor of the parent domain. If the object is out-of-bailiwick, the sponsor is the registrar which created the contact.
  5. If a registrar submits a change to the name of a host object, if the new host name is subordinate to an in-bailiwick domain, then that registrar must also be the sponsor of the new parent domain.
  6. Registrars are not permitted to create hosts that are subordinate to a non-existent in-bailiwick domain, or to change the name of a host object so that it is subordinate to a non-existent in-bailiwick domain.
  7. A host cannot be deleted if one or more domains are delegated to it (the registry deletes hosts to remove orphan glue, see §28).
  8. Inter-registrar transfers are not permitted.
  9. Only the sponsoring registrar of the host may submit update or delete commands for the object.

25.3.3. Contact objects
  1. Contact IDs may only contain characters from the set [A-Z, 0-9, . (period), - (hyphen) and - (underscore)] and are case-insensitive.
  2. Phone numbers and email addresses must be valid as described in RFC 5733 §2.5 and §2.6.
  3. The contact:org, contact:sp, contact:pc, contact:phone and contact:fax elements are optional.
  4. Contacts must have an authInfo code which is used in inter-registrar transfers. This code may contain up to 48 bytes of UTF-8 character data.
  5. A contact cannot be deleted if one or more domains are associated with it.
  6. Only the sponsoring registrar of the contact may submit update or delete commands for the object.

25.4. EPP Extensions
GMO will support the following EPP extensions. CentralNic's implementations fully comply with the required specifications.

25.4.1. Registry Grace Period Mapping
Various grace periods and hold periods are supported by the Registry Grace Period mapping, as defined in RFC 3915. This is described further in §27.

25.4.2. DNSSEC Security Extensions Mapping
Registrars may submit Delegation Signer (DS) record information for domains under their sponsorship. This permits the establishment of a secure chain-of-trust for DNSSEC validation.
GMO will support the specification defined in RFC 5910. This supports two interfaces: the DS Data Interface and Key Data Interface. GMO will support the former interface (DS Data), where registrars submit the keytag, algorithm, digest type and digest for DS records as XML elements, rather than as key data. Key data is stored if provided as a child element of the secDNS:dsData element. The maxSigLife element is optional in the specification and is not currently supported.

25.4.3. Launch Phase Extension
CentralNic has assisted development of a standard EPP extension for registry "launch phases" (ie Sunrise and Landrush periods), during which the steady-state mode of "first-come, first-served" operation does not apply. This extension permits registrars to submit requests for domains with claimed rights such as a registered trademark. The extension is currently described in an Internet-Draft which is included in Appendix 25.1. It is hoped that this draft will eventually be published as an RFC which can be implemented by other registries and registrars.
GMO’s system will implement this extension and will support the most recent version of the draft during the initial launch of the TLD.
 
25.4.4. IDN Language Tag Extension
The IDN Language Tag extension permits a registrar to unambiguously identify the language associated with an internationalized domain name when submitting a domain:createcommand. This extension is described in an Internet-Draft which is included in Appendix 25.2.
GMO’s system will implement this extension and will support the most recent version of the draft during the initial launch of the TLD.
 

25.5. Registrar Credentials and Access Control
Registrars are issued with a username (their registrar ID) and a password. This password cannot be used to access any other service and only this password can be used to access the EPP system. Registrar officers with the "Management" access level can change their EPP password via the Registrar Console.
RFC 5730 requires "mutual, strong client-server authentication". GMO requires that all registrars connect using an SSL certificate. This certificate may be obtained from a recognised certificate authority, or it may be a self-signed certificate registered with GMO via the Registrar Console. Registrar officers with the "Management" access level can upload SSL certificates for their account.

25.6. Session Limits and Transaction Volumes
There are no limits on the number of active sessions a registrar can maintain with the server. Similarly, there are no limits on the volume of transactions a registrar may send. However the system is fully capable of imposing connection limits and this measure may be used in future to ensure equal access amongst registrars.

25.7. Transaction Logging and Reporting
All "transform" commands are logged. Transform commands are: create, renew, update, delete and transfer. The system logs the time and date when the command was received, the registrar which submitted it, the request and response frames, the result code and message. All commands, whether successful or not, are logged.
The transaction log is stored in the primary registry database. Registrars have access to the log for their account via the Registrar Console. The log viewer permits filtering by command, object type, object ID (domain, host name, contact ID), result code and timestamp.
“Query” commands (ie check, info, poll op="req") are logged via a separate logging system, in order to reduce unnecessary load on the primary database system. These logs are used to generate the monthly reports which will be submitted to ICANN.

25.8. EPP Message Queue
The EPP protocol provides a message queue to provide registrars with notifications for out-of-band events. CentralNic’s infrastructure currently supports the following EPP message notifications which will be replicated for GMO:
25.9. Registrar Support, Software Toolkit
CentralNic has supported EPP for many years. CentralNic has released a number of open source client libraries for several popular programming languages. These are used by registrars and registries around the world. CentralNic maintains the following open source EPP libraries: These libraries are available for anyone to use, at no cost. CentralNic develops these libraries, and accepts submissions and bug reports from users around the world.

25.10. Quality Assurance, RFC Compliance
To ensure that its EPP system fully complies with the relevant specifications documents, GMO will implement the following:

25.10.1. Schema Validation
The EPP system automatically validates all response frames against the XSD schema definitions provided in the RFCs. Should a non-validating response be sent to a registrar, an alert is raised with the NOC to be investigated and corrected. By default, this feature is disabled in the production environment but it is enabled in all other environments (as described below).

25.10.2. Multi-stage Deployment and Testing
EPP system code is developed, tested and deployed in a multi-stage environment:
  1. Developers maintain their own development environment in which new code is written and changes are prepared. Development environments are configured with the highest level of debugging and strictness to provide early detection of faults.
  2. All changes to the EPP system are subjected to peer review: other developers in the team must review, test and sign off the changes before being committed (or, if developed on a branch, being merged into the stable branch).
  3. Changes to EPP system code are then deployed in the OT&E environment. Registrars continually test this system as part of their own QA processes, and this additional phase provides an additional level of quality assurance.

25.10.3. Registrar Feedback
Registrars are provided with an easy way to report issues with the EPP system, and many perform schema validation on the responses they receive. When registrars detect issues, they are encouraged to submit bug reports so that developers can rectify the issues.

25.11. EPP System Resourcing
As can be seen in the Resourcing Chart found in Appendix 23.2, during the ongoing operations of the registry, GMO will contribute to the development and maintenance of this aspect of the registry system. This team will not work on specific registry subsystems full-time, but a certain percentage of their time will be dedicated to each area.
Additionally, GMO will draw upon CentralNic’s own team of engineers and developers, as described in the FTE resource assignment described in Appendix 23.3. This contribution is slightly less than one full-time position. CentralNic personnel will work closely with GMO during the initial implementation of the registry, and will provide technical support and advice during ongoing operations through Year 3. CentralNic will provide enhancements to the performance and functionality of the registry system to GMO under the terms of the agreement between the two companies.
 
 
 
 


26. Whois: describeA complete answer should include, but is not limited to:Frequency of synchronization between servers.
To be eligible for a score of 2, answers must also include:A complete answer is expected to be no more than 5 pages.

NTT Resonant Inc. has chosen GMO Registry, Inc as the registry infrastructure provider for .goo. Any information regarding technical and operational capability of the proposed TLD registry (answers to questions 23 – 44) therefore refers to GMO’s registry infrastructure systems.
 
Whois is one of the oldest Internet protocols still in use. It allows interested persons to retrieve information relating to Internet resources (domain names and IP addresses). Whois services are operated by the registries of these resources, namely TLD registries and RIRs.
Whois is described by RFC 3912, which serves as a description of existing systems rather than requiring specific behaviours from clients and servers. The protocol is a query-response protocol, in which both the query and the response are opaque to the protocol, and their meanings are known only to the server and to the human user who submits a query. Whois has a number of limitations, but remains ubiquitous as a means for obtaining information about name and number resources.

26.1. Compliance
The Whois service will comply with RFC3912 and Specifications 4 and 10 of the New gTLD Registry Agreement. The service will be provided to the general public at no cost. If ICANN specify alternative formats and protocols (such as RDAP) then GMO Registry, Inc (GMO) will implement these as soon as reasonably practicable.
GMO will monitor its Whois system to confirm compliance. Monitoring stations will check the behaviour and response of the Whois service to ensure the correctness of Whois records. GMO will maintain a public Whois contact to which bug reports and other questions about the Whois service can be directed.

26.2. Domain Name Query
By default, any query is assumed to be a domain name unless a keyword is prepended to the query. If the domain exists, then registration is returned, including the following fields: An example of a domain whois response is included in Appendix 26.1. The Domain ROID is the Repository Object Identifier as described in RFC 5730, §2.8. The ROID field corresponds to the domain:roid  element of EPP “info” responses.
A domain may be associated with one or more status codes. These are represented in Whois responses as phrases rather than EPP mnemonics. A domain may have any of the following status codes: The Registrant, Administrative, Technical and Billing Contact sections of the Whois record display the contact information for the contact objects that are associated with the domain. The information displayed replicates the information showed for a contact query (see below). The server shows similar information for the sponsoring registrar.
Domains may have 0-13 DNS servers. If a domain name has no DNS servers, then the "INACTIVE" status code appears in the Status section. If the registrant provided DS records for their DNSSEC-signed domain, then these are included. For each DS record, then the key tag, algorithm, digest type and digest are displayed.

26.3. Contact Object Query
Users can query for information about a contact by submitting a query of the form "contact [ID]", where "[ID]" is the contact ID equivalent to the contact:id element in EPP info responses. This is also the ID used when referring to contacts in domain responses.
The following information is included in Contact records: An example of a contact object whois response is included in Appendix 26.2. A contact object may be associated with one or more status codes. These are represented in Whois responses as phrases rather than EPP code mnemonics. A contact object may have any of the following status codes:
26.4. Host Objects
Users can query for information about a host object by submitting a query of the form "nameserver [HOST]". The following information is included in host records: An example of a host whois response is included in Appendix 26.3. A host object may have an IPv4 or IPv6 address if the host is "in-bailiwick", ie subordinate to a domain name within a TLD operated by the registry. IP address information is not shown for "out-of-bailiwick" hosts.
Host objects may only have two status codes: The Referral URL is the website of the Sponsoring Registrar for this host. If the host is subordinate to a domain name in the TLD, this will be the sponsoring registrar of the parent name. If the host is out-of-bailiwick, then the sponsoring registrar is the registrar who issued the original “create” request.

26.5. Character Encoding
Responses are encoded as UTF-8. Queries are assumed to be encoded in UTF-8.

26.6. IDN Support
The Whois service supports Internationalised Domain Names. Users may submit queries for IDN domains using either the U-label or the A-label.

26.7. Bulk Access
GMO will provide up-to-date registration data to ICANN on a weekly basis (the day to be designated by ICANN). GMO will provide the following data for all registered domain names: domain name, repository object id (roid), registrar id (IANA ID), statuses, last updated date, creation date, expiration date, and name server names. For sponsoring registrars it will provide: registrar name, registrar repository object id (roid), hostname of registrar Whois server, and URL of registrar. Data will be provided in the format specified in Specification 2 for Data Escrow (including encryption, signing, etc.) but including only the fields mentioned in the above.
At ICANN's request, GMO will provide ICANN with up-to-date data for the domain names of de-accredited registrars to facilitate a bulk transfer. The data will be provided in the format specified in Specification 2 for Data Escrow. The file will only contain data related to the domain names of the losing registrar. GMO will provide the data within 2 business days.

26.8. Load Projections
As described in §31, CentralNic's existing Whois system receives an average of 0.36 queries per day for each domain name in the registry, including misses for non-existent objects as well as hits.
The number of daily queries per domain for each existing gTLD was calculated using figures for the month of November 2011 published by ICANN. This analysis may be found in Appendix 26.6. It shows little correlation between the number of domains in the TLD and the number of queries that each domain receives. Smaller gTLDs such as .aero and .museum receive more queries per domain than larger gTLDs, but .jobs (which is much larger than either .aero or .museum) received more queries per domain than either. It should be noted that the high volumes observed for .XXX are very likely due to activities surrounding the Landrush and initial launch of that TLD.
CentralNic believes that the query rate observed for its own registry system is mainly affected by its efforts to deter abuse, and outreach to registrars, who often use Whois to perform availability checks, to encourage them to use EPP instead. CentralNic believes this query rate will also apply for GMO’s Whois service. A projection of query load for the Whois system for the first 24 months of operation can be found in Appendix 26.4. This model also includes data transit rates and bandwidth projections for the same period. As can be seen, the data and bandwidth requirements are relatively small compared to those for the Shared Registry System and authoritative DNS.

26.9. Technical Implementation
A diagram describing the infrastructure supporting the Whois service may be found in Figure 26.1. During normal operations, the Whois service will be operated at the primary operations centre in Tokyo. During failover conditions, it is operated at the Disaster Recovery site in San Jose (see §34).
Queries pass through the firewalls to one of two front-end load balancers. Round-robin DNS distributes queries between the devices. Load balancers are configured in High Availability mode so that if one server fails, the other will resume service on its IP address until the server can be restored. Queries are distributed to backend application servers via weighted least connections algorithm.

26.9.1. Application Server Architecture
Application servers are built on commodity hardware running CentOS. The service is provided using the mod_whois Apache module (see http://modwhois.sf.net/) which causes Apache to listen on port 43 and accept queries, which are then handled using a PHP script, which generates and returns the response.

26.9.2. Caching
Application servers use caching to reduce database load. Subsequent identical queries return a cached record until the cache expires, after which a new record is generated. Records are currently cached for 600 seconds (ten minutes), so if a domain is updated immediately after its Whois record has been cached, the updated record will be visible after ten minutes. This compares favourably to the 60 minute requirement in the gTLD Service Level Agreement. Records are cached in a shared Memached server. Memcached is a high-performance caching server used by some of the largest sites in the world, including Wikipedia, Flickr, Wordpress.com and Craigslist.

26.9.2. Database
The Whois service will draw data directly from the primary database. The query volume required to sustain the Whois service will be comparable to that of a modest web application such as a small e-commerce site, and as a result a dedicated database for the Whois system will not be required. As can be seen in Figure 26.1, a separate logging database will be used to aggregate log data for use with the rate limiting system.

26.10. Web based Whois Service
GMO will provide a web interface to the Whois service on its website. The web Whois will act as a proxy to the port 43 Whois service: users will enter a query into a form, and a server-side process will submit the query to the Whois server, and display the response. This service will not be subjected to the rate limiting described above, but users will be required to complete a CAPTCHA to prevent high-volume automated access.

26.11. Searchable Whois Service
GMO will provide a Searchable Whois Service (SWS). This service will be made available on the registry website. The SWS provides third parties with a search interface that allows queries for partial matches against a number of domain name properties, including: Access to the SWS is restricted. Users must submit an account request via the website, and agree to the terms and conditions which governs their access to the system. These terms are included as Appendix 26.5. Once their request has been reviewed and approved, they are issued with credentials that permit them to login to the SWS.
To prevent abuse of the SWS, users may only make fifty queries per day initially. This limit can be increased upon request and demonstration of legitimate need.

26.12. Anti-Abuse Mechanisms
CentralNic has implemented measures to mitigate the threat of abuse of the Whois service and these will be observed by GMO. The primary threat to the Whois service are so-called "dictionary" attacks, where an attacker attempts to enumerate the database by flooding the server with queries for domains taken from a precompiled list: as zone files are easy to obtain, this presents a threat to the privacy of contact information in the registry database. The information harvested can be used to compile email databases for spamming, or to send domain renewal scam letters, for example.
The Whois service implements rate-limiting to impede dictionary attacks. For each query, a counter associated with the client IP address is incremented. For subsequent queries, this counter determines the number of queries received within the previous hour. If the number of queries exceeds a pre-set maximum (currently 240 queries per hour), then the server returns an error, warning the user that they have exceeded the permitted query rate. If the user stops sending queries, then eventually the query rate will drop below the limit, and subsequent queries will be permitted. If the user continues to send queries, and the query rate exceeds the limit by a further 25% (300 queries per hour), then the IP address is permanently blocked. For queries over IPv6 (where an attacker might have access to billions of IP addresses), the enclosing /48 will be blocked.
Experience indicates that is an effective mechanism for preventing abuse of the Whois. The rate limit has been tuned to ensure that legitimate uses of the Whois are allowed, but abusive use of the Whois is restricted to levels which are unappealing for attackers.
GMO will keep a "white list" of IP addresses used by legitimate users of the Whois service, including law enforcement agencies and other research and anti-abuse entities. Registrar access lists will also be incorporated into the white list, and IP addresses registered on ICANN's RADAR system will also be included. Queries from IP addresses that appear on the white list will not be rate-limited. Interested parties can request addition to the white list by contacting GMO’s public customer service team.
The web-based Whois will not implement rate-limiting, but users of this service must complete a CAPTCHA to access Whois records.

26.12.1. Denial-of-Service attacks
The rate-limiting system in place provides protection against DoS and DDoS attacks, as any host that attempts to flood the Whois service with queries will be quickly blocked. However, a DDoS attack could still saturate upstream links requiring filtering at the edges of GMO’s network, as well as their upstream providers. Continuous surveillance and monitoring of the Whois system (see §42) proactively detects these threats. As the Whois service directly queries the primary SRS database, GMO will impose rate-limits on the database backend to prevent an attack against the Whois service from disrupting the SRS.

26.13. Monitoring and Logging
Remote monitoring is used to verify the availability of the service and to record the round-trip times for different queries (warm hit, warm miss). Local monitoring records query volumes.

26.14. Resourcing
As can be seen in the Resourcing Chart found in Appendix 23.2, during the ongoing operations of the registry, GMO will contribute to the development and maintenance of this aspect of the registry system. This team will not work on specific registry subsystems full-time, but a certain percentage of their time will be dedicated to each area.
Additionally, GMO will draw upon CentralNic’s own team of engineers and developers, as described in the FTE resource assignment described in Appendix 23.3. This contribution is slightly less than one full-time position. CentralNic personnel will work closely with GMO during the initial implementation of the registry, and will provide technical support and advice during ongoing operations through Year 3. CentralNic will provide enhancements to the performance and functionality of the registry system to GMO under the terms of the agreement between the two companies.
 
 
 
 
 


27. Registration Life Cycle: provide a detailed description of the proposed registration lifecycle for domain names in the proposed gTLD. The description must:The description of the registration lifecycle should be supplemented by the inclusion of a state diagram, which captures definitions, explanations of trigger points, and transitions from state to state.
If applicable, provide definitions for aspects of the registration lifecycle that are not covered by standard EPP RFCs.
A complete answer is expected to be no more than 5 pages.

NTT Resonant Inc. has chosen GMO Registry, Inc as the registry infrastructure provider for .goo. Any information regarding technical and operational capability of the proposed TLD registry (answers to questions 23 – 44) therefore refers to GMO’s registry infrastructure systems.
 
The lifecycle of a domain in the registry is described in Figure 27.1, and closely follows that of domain names in existing gTLD registries. The lifecycle is described below.

27.1. Available
The domain is not registered. No delegation (or any other records) exist in the DNS, and the Whois system will return a "NOT FOUND" response to queries. An EPP check command will return an "avail" status of 1.

27.2. Registered
A registrar submits an EPP create command or registers the domain name via the Registrar Console. The registration fee is deducted from the registrar's balance. The initial registration period may be any whole number of years between one (1) and ten (10).
For five (5) calendar days after the registration of the domain, the registrar can delete the domain and receive a credit for the registration fee (subject to the Add Grace Period Limits Policy).
While the domain is registered, it is delegated to the specified name servers and will resolve normally. During this time, the registrar may update the domain name's DNS settings, lock statuses and contact associations, and may extend the registration period (subject to a maximum of ten (10) years) by submitting a renew EPP command or using the Registrar Console.
The domain may also be transferred to a different sponsoring registrar. Upon such transfer the domain name is automatically renewed for one year.

27.3. Expired
When the expiry date is reached, the domain name is automatically renewed for a period of one year, and the renewal fee is deducted from the registrar's account.
For forty-five (45) days after the auto-renewal (Auto-Renew Grace Period), the registrar can delete the domain and receive a credit for the renewal fee.

27.4. Redemption Grace Period
Should the registrar delete the domain, the domain enters the Redemption Grace Period. During this period, the domain name will no longer resolve as all delegation information is removed from the zone.
For the first thirty (30) days after receipt of the delete request, the domain is in the "Pending Delete Restorable" state. During this time, the registrar may submit an RGP restore request via EPP or the Registrar Console. The domain is then placed into the "Pending Restore" state.
The registrar must then submit an RGP Restore Report detailing the reason why the restore request has been submitted. If the Restore Report is received within five (5) calendar days of the original restore request, then the domain is restored. However, if the Restore Report is not received within this period, then the domain falls back into the "Pending Delete Restorable" state.

27.5. Redemption Period State Diagram
Figure 27.2 describes the state diagram for domain names in the Redemption Grace Period. This diagram is taken from RFC 3915.

27.6. Pending Delete
Forty (40) days after the receipt of the delete request, the domain leaves the "Pending Delete Restorable" and enters the "Pending Delete" status. The registrar cannot submit a Restore Request during this period.

27.7. Released
Five (5) days after the domain enters the "Pending Delete" status the domain name is purged from the database and is once again available for registration.

27.8. Other Grace Periods
The registry also implements the following grace periods. In general, these grace periods allow registrars to delete domain names following billable transactions and receive a refund.

27.8.1. Add Grace Period
As described above, the Add Grace Period (AGP) is the five (5) calendar days following the initial registration of the domain.

27.8.2. Auto-renew Grace Period
As described above, the Auto-renew Grace Period is the forty five (45) calendar days following the auto-renewal of the domain.

27.8.3. Renew Grace Period
The Renew Grace Period is the five (5) calendar days following the renewal of the domain via an EPP renew command, or via the Registrar Console.

27.8.4. Transfer Grace Period
The Transfer Grace Period is the five (5) calendar days following the successful completion of an inter-registrar transfer.

27.9. Hold Periods
GMO Registry, Inc (GMO) will implement the following hold periods:

27.9.1. Registration Hold Period
The Registration Hold Period will forbid inter-registrar transfers of domain names within sixty (60) days of initial registration.

27.9.2. Transfer Hold Period
The Transfer Hold Period will forbid transfers of domain names within sixty (60) days of a previous inter-registrar transfer. This Hold Period does not affect disputed transfers that are undone by the registry following the outcome of a Transfer Dispute Resolution process.

27.10. Lock Statuses
GMO will permit the following lock statuses for domain names:

27.10.1. clientHold
This status may be set by registrars using an EPP update command, or via the Registrar Console. Domains with this status are removed from the DNS and will not resolve.

27.10.2. clientDeleteProhibited
This status may be set by registrars using an EPP update command, or via the Registrar Console. When set, all attempts by the registrar to delete the domain using an EPP delete command will be refused with EPP response code 2304 (Status Prohibits Operation). Registrars must remove the code using an EPP update command before they can delete the domain.

27.10.3. clientRenewProhibited
This status may be set by registrars using an EPP update command, or via the Registrar Console. When set, all attempts by the registrar to renew the domain using an EPP renew command will be refused with EPP response code 2304 (Status Prohibits Operation). Registrars must remove the code using an EPP update command before they can renew the domain.

27.10.4. clientUpdateProhibited
This status may be set by registrars using an EPP update command, or via the Registrar Console. When set, all attempts by the registrar to update the domain using an EPP update command will be refused with EPP response code 2304 (Status Prohibits Operation), unless the update request frame includes a “rem” element to remove this status. Once the status has been removed, subsequent update commands will succeed.

27.10.5. clientTransferProhibited
This status may be set by registrars using an EPP update command, or via the Registrar Console. When set, all attempts by other registrars to submit a transfer request for the domain using an EPP transfer command, or via the Registrar Console, will be refused with EPP response code 2304 (Status Prohibits Operation). The sponsoring registrar must remove this status before any other registrar can submit a transfer request.

27.10.6. serverHold
This status will be set by GMO in accordance with policy. It cannot be removed by registrars. Domains with this status will be removed from the DNS and will not resolve.

27.10.7. serverDeleteProhibited
This status will be set by GMO in accordance with policy. It cannot be removed by registrars. When set, all attempts by the registrar to delete the domain using an EPP delete command will be refused with EPP response code 2304 (Status Prohibits Operation).

27.10.8. serverUpdateProhibited
This status will be set by GMO in accordance with policy. It cannot be removed by registrars. When set, all attempts by the registrar to update the domain using an EPP update command will be refused with EPP response code 2304 (Status Prohibits Operation).

27.10.9. serverRenewProhibited
This status will be set by GMO in accordance with policy. It cannot be removed by registrars. When set, all attempts by the registrar to renew the domain using an EPP renew command will be refused with EPP response code 2304 (Status Prohibits Operation).

27.10.10. serverTransferProhibited
This status will be set by GMO in accordance with policy. It cannot be removed by registrars. When set, all attempts by the registrar to transfer the domain using an EPP transfer command will be refused with EPP response code 2304 (Status Prohibits Operation).

27.11. Lifecycle Processing
Domain names move through the lifecycle in one of two ways: in real-time as a result of registrar activity, or during daily billing runs.
Billing runs take place once per day. The billing run performs the following batch jobs: The billing runs also perform registrar account management functions such as generation of invoices, sending balance warnings, and generation of internal reports.
27.11.1. Grace Period Processing
Unlike other billing processes, which run once per day, the system that causes domain names to exit the Add, Renew and Auto-Renew Grace Periods runs every sixty (60) seconds. This ensures that domains exit these grace periods exactly 86,400 seconds (times 5 or 45 days) after they entered them.

27.12. Inter-Registrar Transfer Period
When a transfer request is received, the action date of the transfer is set to five (5) calendar days from the moment of the original request. Successful transfers are approved at the end of this period.

27.13. pendingCreate Status
The registry systems supports the "pendingCreate" status for domain names, as described in RFC 5731, §3.3. Domains in this state are fully registered in the database (subsequent create commands would fail with an Object Exists error) but are not present in the DNS.
This status is used when a particular TLD implements a policy whereby registration requests are verified by a third party such as a Sponsoring Organisation or Validation Agent. Following out-of-band review of the request, the registration may be approved or denied.
If a request is denied, then the domain is immediately purged from the registry system, and the registrar notified via email and the EPP message queue. The registrar also receives a credit for the registration fee. If approved, then the pendingCreate status is removed from the domain that begins to resolve.
This status code will not be used unless registry policy requires it.

27.14. Resourcing
As can be seen in the Resourcing Chart found in Appendix 23.2, during the ongoing operations of the registry, GMO will contribute to the development and maintenance of this aspect of the registry system. This team will not work on specific registry subsystems full-time, but a certain percentage of their time will be dedicated to each area.
Additionally, GMO will draw upon CentralNic’s own team of engineers and developers, as described in the FTE resource assignment described in Appendix 23.3. This contribution is slightly less than one full-time position. CentralNic personnel will work closely with GMO during the initial implementation of the registry, and will provide technical support and advice during ongoing operations through Year 3. CentralNic will provide enhancements to the performance and functionality of the registry system to GMO under the terms of the agreement between the two companies.a
 
 
 
 
 


28. Abuse Prevention and Mitigation: Applicants should describe the proposed policies and procedures to minimize abusive registrations and other activities that have a negative impact on Internet users. A complete answer should include, but is not limited to:To be eligible for a score of 2, answers must include measures to promote Whois accuracy as well as measures from one other area as described below.A complete answer is expected to be no more than 20 pages.

In order to safeguard the security and stability of .goo, as well as the Internet at large, NTT Resonant Inc. (the registry) takes abuse very seriously and employs proactive measures to mitigate abusive activities.
In general, the registry’s abuse mitigation strategies fall into the following broad areas:  
28.1. Pre-Verification of Registration Eligibility
.goo is a domain for NTT Resonant Inc. and its stakeholders, and the registry believes that it is important to prevent unqualified registrations in order to keep the TLD space safe and reliable; therefore, the registry will conduct registrant pre-verification in all .goo registration phases.
Registration and management of .goo domain names will be carried out via the .goo dedicated account provided by a .goo accredited registrar. Access to the .goo dedicated account will be limited to the registrants and their authorized administrative contacts, subject to verification of registration eligibility. The verification will be conducted by the registry, and organizations that wish to apply for a .goo dedicated account will be required to provide proof of registration eligibility to the registry via a .goo accredited registrar. Proposed valid forms of documentary proof include, but are not limited to, The registry will conduct verification on a per-registrant basis only. Once verified, the registrant or its authorized administrative contact will have access to the .goo dedicated account, through which it may apply for multiple .goo domain names without further verification, under the condition that the registrant and administrative contact information of an applied-for domain name is identical to that which the registry has verified. If there are any material changes to the verified information, the registrant or administrative contact must notify the registry of the change. Failure to comply with the policies may result in the suspension or cancellation of the .goo dedicated account, and/or the denial, cancellation or transfer of any registration or transaction, as well as the placement of lock, hold or similar statuses on applying-for and/or existing domain names.
The registry believes that the verification will help mitigate abusive activities including abusive registrations as well as promote Whois accuracy.
 
28.2. Draft Abusive Use Policy
The registry defines abuse as any activity that may harm the stability and security of the DNS and Internet, including, but not limited to: The registry reserves the right to deny, cancel or transfer any registration or transaction, or place any domain name on lock, hold or similar status, at its sole discretion, to enforce the policy.
 
28.3. Abuse Public Contact Information
In order to comply with Specification 6.4.1 of New gTLD Agreement, the registry will provide to ICANN its Abuse contact details. The information will include a valid e-mail and mailing address and a primary contact, and the registry will promptly provide to ICANN a notice of any changes to the contact.
Also, the registry will also publish its abuse public contact information on its web site when it publicly releases the .goo domain name registration policies, The abuse public contact will be responsible for handling complaints concerning abusive activities relating to domains registered under the .goo TLD that violate the Abuse Use Policy and require expedited attention. The abuse public contact will be available 24 hours a day 7 days a week. A person who wishes to contact the abuse public contact will be required to submit the Abuse Complaint Form via e-mail or via the online Abuse Complaint Form on the Registry web site.
28.4. Abuse Complaint Form
In order to gather pertinent information about a reported incident, facilitate accurate investigation, and avoid false alarms / positives, the registry will provide an Abuse Complaint form on the registry website. The Abuse complaint form is required at the time a person contacts the abuse public contact and can be submitted online or by email in the format specified on the registry website.
 
28.5. Draft Takedown Procedure
  The registry understands that the Registration Abuse Policies Working Group has been working on developing best practices for registries and registrars addressing the fraudulent use of domain names. The registry will closely follow the working group discussions and documents, with a view of adopting the best practices to enhance abuse mitigation capabilities.
In addition, the registry will participate in security forums to keep track of the latest developments in abuse mitigation best practices and refine our abuse policies and procedures from time to time.
 
28.6.  Orphan Glue Records
The registry’s view on orphan glue records is consistent with the Security and Stability Advisory Committee Comment on Orphan Glue Records
 <http://www.icann.org/en/committees/security/sac048.pdf>. The registry supports the use of orphan glue records for legitimate purposes. Upon receiving a complaint relating to an orphaned glue record used in connection with malicious activities, the registry will verify and take corrective actions in accordance with its takedown procedures.
 
28.7. Resourcing Plans
As can be seen in the Resourcing Chart found in Appendix 23.2, during the ongoing operations of the registry, GMO will contribute to the development and maintenance of this aspect of the registry system. This team will not work on specific registry subsystems full-time, but a certain percentage of their time will be dedicated to each area.
Additionally, GMO will draw upon CentralNic’s own team of engineers and developers, as described in the FTE resource assignment described in Appendix 23.3. This contribution is slightly less than one full-time position. CentralNic personnel will work closely with GMO during the initial implementation of the registry, and will provide technical support and advice during ongoing operations through Year 3. CentralNic will provide enhancements to the performance and functionality of the registry system to GMO under the terms of the agreement between the two companies.
 
Abuse mitigation and response will be included in the registry operating functions outsourced to backend provider, GMO Registry. The company will adopt abuse policies and procedures developed by GMO Registry, and GMO Registry shall act as the abuse point of contact for the TLD. During ongoing operation, abuse handling will be primarily the responsibility of the Trademark Protection Officers. (Please see Appendix 23.2 of the original application). This may be up to one FTE employee of GMO Registry. The company expects that with only a few hundred domain name registrations forecast in the first 3 years that abuse handling requirements would be minimal. 
 
 
 
 
 


29. Rights Protection Mechanisms: Applicants must describe how their registry will comply with policies and practices that minimize abusive registrations and other activities that affect the legal rights of others, such as the Uniform Domain Name Dispute Resolution Policy (UDRP), Uniform Rapid Suspension (URS) system, and Trademark Claims and Sunrise services at startup.
A complete answer should include:>To be eligible for a score of 2, answers must also include additional measures specific to rights protection, such as abusive use policies, takedown procedures, registrant pre-verification, or authentication procedures, or other covenants.
A complete answer is expected to be no more than 10 pages.

NTT Resonant Inc. (the registry) is committed to implementing and adhering to any rights protection mechanisms that may be mandated from time to time by ICANN, as required by Specification 7 of the New gTLD Agreement.
In order to minimize abusive activities and protect the legal rights of others, the registry will adopt the following policies and practices:  
29.1. Pre-Verification of Registration Eligibility
Since .goo is a domain for NTT Resonant Inc. and its stakeholders, it is important to prevent unqualified registrations in order to maintain a safe and trusted TLD space, as well as to protect the legal rights of others; therefore, the registry will conduct registrant pre-verification in all .goo registration phases.
Registration and management of .goo domain names will be carried out via the .goo dedicated account provided by a .goo accredited registrar. Access to the .goo dedicated account will be limited to the registrants and their authorized administrative contacts, subject to verification of registration eligibility. The verification will be conducted by the registry, and organizations that wish to apply for a .goo dedicated account will be required to provide proof of registration eligibility to the registry via a .goo accredited registrar. Proposed valid forms of documentary proof include, but are not limited to, The registry will conduct verification on a per-registrant basis only. Once verified, the registrant or its authorized administrative contact will have access to the .goo dedicated account, through which it may apply for multiple .goo domain names without further verification, under the condition that the registrant and administrative contact information of an applied-for domain name is identical to that which the registry has verified. If there are any material changes to the verified information, the registrant or administrative contact must notify the registry of the change. Failure to comply with the policies may result in the suspension or cancellation of the .goo dedicated account, and/or the denial, cancellation or transfer of any registration or transaction, as well as the placement of lock, hold or similar statuses on applying-for and/or existing domain names.
 
29.2. Sunrise Registration Process
Before any registration of .goo domain name registration processing starts, Sunrise registration process using the Trademark Clearinghouse required by ICANN will be available for trademark holders.
The registry will establish and publish a set of Sunrise Eligibility Requirements (SERs) and adopt a Sunrise Dispute Resolution Policy (SDRP). SERs and SDRP will be applicable to all .goo domain names registered during the Sunrise Registration and all .goo TLD registrars and registrants must agree to abide by the SERs and SDRP
 
29.3. Sunrise Eligibility Requirements
In accordance with the section entitled “Trademark Clearinghouse” of the Application Guidebook (January 11, 2012 version), .goo SER will at least include  
29.4. Acceptable Domain Name Strings during the Sunrise Registration Process
The domain name strings applied for during the Sunrise registration process must be exactly identical to the applicant’s trademark and be in the Trademark Clearinghouse database. Exceptions (i.e. for trademarks that contain special characters, spaces, punctuations, images, the word goo, etc.) will be developed by the registry before the registration phase opens.
 
29.5. Other Rules for Sunrise Registration Process  
29.6. Sunrise Dispute Resolution Policy
As required by ICANN, proposed .goo SDRP will allow challenges based on at least the following four grounds:  
 
29.7. Trademark Claims Service
As is required by ICANN, the registry is committed to implementing the Trademark Claims service for marks in the Trademark Clearinghouse.
Please Note: Rules and procedures will be determined as soon as the Trademark Claims Service is finalized by ICANN.
The registry will run the process for at least 60 days after the general registration opens. However, the registry may revise the length of this period if ICANNN requirements are amended.
 
29.8. URS System
The registry is committed to adopting and abiding by the URS System for trademark owners who seek a rapid system to take down domain names which infringe on their rights. All .goo TLD registrars and registrants must agree to abide by the URS Systems.
 
29.9. UDRP
In addition to the URS system, UDRP will be applicable to all .goo domain name registrations and all .goo registrars and registrants must agree to be bound by UDRP.
 
29.10. Abusive Use Policy
In addition to the policies and practices described in this section, the registry sets forth the Abusive Use Policy to minimize abusive activities. Not all abusive activities necessarily affect rights but some abusive activities do affect the rights when the activities are in conjunction with abusive registrations. A description of the policy and takedown procedures is provided in question 28.
 
29.11. Resourcing Plans
As can be seen in the Resourcing Chart found in Appendix 23.2, during the ongoing operations of the registry, GMO will contribute to the development and maintenance of this aspect of the registry system. This team will not work on specific registry subsystems full-time, but a certain percentage of their time will be dedicated to each area.
Additionally, GMO will draw upon CentralNic’s own team of engineers and developers, as described in the FTE resource assignment described in Appendix 23.3. This contribution is slightly less than one full-time position. CentralNic personnel will work closely with GMO during the initial implementation of the registry, and will provide technical support and advice during ongoing operations through Year 3. CentralNic will provide enhancements to the performance and functionality of the registry system to GMO under the terms of the agreement between the two companies.
 
 
 
 
 
 


30A. Security Policy: provide a summary of the security policy for the proposed registry, including but not limited to:To be eligible for a score of 2, answers must also include:A summary of the above should be no more than 20 pages. Note that the complete security policy for the registry is required to be submitted in accordance with 30(b).

30(a).1. Introduction
NTT Resonant Inc. has delegated all technical and information processing facilities for .goo to GMO Registry, Inc (GMO). Neither the Applicant, nor any of its officers and staff, nor any of its affiliates, have any access to, or control over, the information processing facilities or critical registry services for .goo, which are operated in their entirety by GMO. Therefore, the response to this question focuses primarily on GMO’s security policies.
The Information Security Management System (ISMS) developed by CentralNic for the registry system used by GMO has been certified against EIC/ISO 27001:2005 by Lloyd's Register Quality Assurance (LRQA), a UKAS accredited certification body. A copy of the certificate issued by LRQA is included in Appendix 30(a).1.
 The ISMS and supporting documents, including the Access Control Policy and others, will be used as the basis for the information security policy for the registry being established by GMO.

30(a).2. Security Policy
GMO promotes a culture of security throughout the whole organization based on the nine generally accepted principles from the OECD's guidelines for the Security of Information Systems and Networks.
In establishing a new registry system for .goo and others, GMO Registry will draw upon the expertise and experience of CentralNic to develop its security policy to meet its obligations as a gTLD Registry Operator. GMO will establish a security policy for .goo based on CentralNic’s ISO 27001-certified security policy, with a view to achieving ISO 27001 certification in the future.

30(a).3. Augmented Security Levels
GMO believes that .goo requires no additional security levels above those expected of any gTLD registry operator. Nevertheless, GMO will operate .goo to a high level of security and stability in keeping with its status as a component of critical Internet infrastructure.
Registry systems are hardened against attack from external and internal threats. Access controls are in place and all systems are monitored and audited to mitigate the risk of unauthorised access, distribution or modification of sensitive data assets. The Authoritative DNS System has been designed to meet the threat of Distributed Denial-of-Service (DDoS) attacks by means of over-provisioning of network bandwidth, and deployment of Shared Unicast ("Anycast") addresses on nameservers. Whois services have been designed with built-in rate limiting and include mechanisms for protection of personal information. The stability of the registry is supported by use of high-availability technologies including a "hot" Disaster Recovery site in San Jose, United States, as well as a backup provider relationship with CentralNic in the United Kingdom.

30(a).4. Commitments to Registrars
GMO will make the following commitments to .goo registrars:
30(a).5. Access Controls
GMO will operate a comprehensive Access Control Policy for the registry system. For example, the web-based Staff Console which will be used to administer the SRS and manage registrar accounts will support a total of ten different access levels, ranging from "Trainee", who have read-only access to a subset of features, to "System Administrator" who have full access to all systems.
Underlying server and network infrastructure will also be subjected to access control. A centralised configuration manager will be used to centrally control access to servers. Individual user accounts will be created, managed and deleted via the configuration server. Access to servers will be authenticated by means of SSH keys: only authorised keys may be used to access servers. Operations personnel can escalate privileges to perform administration tasks (such as updating software or restarting daemons) using the "sudo" command which is logged and audited as described below.
Only operations personnel will have access to production environments. Development personnel will be restricted to development, staging and OT&E environments.

30(a).6. Security Enforcement
Security controls will be continually monitored to ensure that they are enforced. Monitoring will include use of intrusion detection systems on firewalls and application servers. Attempted breaches of access controls (for example, port scans or web application vulnerability scans) will trigger NOC alerts and may result in the execution of the Security Incident Response Policy (see below).
 
30(a).7. Logging and Monitoring
GMO will operate a centralised logging and monitoring system (see §42), analyzing access logs in order to generate access reports which will then be reviewed by NOC personnel. This will include access to servers via SSH, to web-based administration systems, and to security and networking equipment. Unexpected access to systems will be investigated with a view to correcting any breaches and/or revoking access where appropriate.

30(a).8. Security Incident Response Policy
GMO will operate a Security Incident Response Policy which will apply to all events and incidents as defined by the policy, and to all computer systems and networks operated by GMO.
The Policy will provide a mechanism by which security events and incidents are defined (as observable change to the normal behaviour of a system attributable to a human root cause). It will also define the conditions under which an incident may be defined as escalated (when events affect critical production systems or requires that implementation of a resolution that must follow a change control process) and emergencies (when events impact the health or safety of human beings, breach primary controls of critical systems, or prevent activities which protect or may affect the health or safety of individuals).
The Policy will establish an Incident Response Team which regularly reviews status reports and authorises specific remedies. The IRT will conduct an investigation which seeks to determine the human perpetrator who is the root cause for the incident. Very few incidents will warrant or require an investigation. However, investigation resources like forensic tools, dirty networks, quarantine networks and consultation with law enforcement may be useful for the effective and rapid resolution of an emergency incident.
The Policy will make use of GMO’s support ticketing and bug tracking systems to provide a unique ID for the event, and means by which the incident may be escalated, information may be reported, change control processes put into effect, and ultimately resolved. The Policy will also describe the process by which an incident is escalated to invoke an Emergency Response, which involves Lock-Down and Repair processes, monitoring and capturing of data for forensic analysis, and liaison with emergency services and law enforcement as necessary.

30(a).9. Role of the Network Operations Centre (NOC)
In addition to its role in managing and operating GMO’s infrastructure, the NOC plays a key role in managing security. The NOC responds to any and all security incidents, such as vulnerability reports received from registrars, clients and other stakeholders; monitoring operator and security mailing lists (such as the DNS-OARC lists) to obtain intelligence about new security threats; responding to security-related software updates; and acting upon security alerts raised by firewall and intrusion detection systems.

30(a).10. Information Security Team
GMO will maintain an Information Security Team (IST) to proactively manage information security. The IST will be a cross-functional team from relevant areas of GMO and parent-company GMO Internet. These key members of staff will be responsible for cascading rules, regulations and information to their respective departments. They will also be the first port of call for their departmental staff to report potential security incidences and breaches. The IST will be members of an internal email group used to co-ordinate and discuss security related issues.
The IST will comprise the CEO, CTO, Operations Manager, Senior Operations Engineer and Security Engineer.
IST responsibilities will include:
30(a).11 Auditing and Review
ISO 27001 includes processes for the auditing and review of security systems and policies. Audits are performed annually by an independent assessor. GMO’s IST will periodically review the ISMS and conduct gap analyses, identifying areas where performance does not comply with policy, and where the Risk Assessment has identified the need for further work.

30(a).12. Testing of Controls and Procedures
GMO will conduct bi-annual penetration tests of its registry systems to ensure that access controls are properly enforced and that no new vulnerabilities have been introduced to the system. Penetration tests will include both "black box" testing of public registry services such as Whois and the Registrar Console, "grey box" testing of authenticated services such as EPP, and tests of physical security at GMO’s offices and facilities.
GMO will retain the services of a reputable security testing company. The results of this test will be used in annual reviews and audits of the ISMS.

30(a).13. GMO Security Policies
The following policies relate to GMO’s non-technical facilities such as its offices, rather than to the .goo registry system.
30(a).13.1. Controls on Confidential Data
 
Data that relate to .goo are only accessible by authorized staff. Access to the system is via keys and passwords, no other staff can access the server and cabinets which store backups and confidential physical documents.
 
30(a).13.2. Storage of Records
 
Physical documents will be placed under lock and key accessible only to authorized persons. Regular auditing ensures that all information is secure.
 
Soft-copy data will be kept in a secured server with encryption that will ensure that data is not accessible to any third party. The server will be isolated from the rest of the network at all times to ensure that it is not accessible except for authorized access.
 
 
30(a).13.3. Storage of Credentials
 
Credentials (such as usernames and passwords used to access third-party systems) are stored in a secure online vault application, which uses PKI infrastructure to securely share items with specific users.
 
 
30(a).13.4. Logging of Access
 
Access logs are monitored in a regular basis, all logins are recorded as well as a log sheets that lists the specific times that systems were accessed and the person that accessed the system.
 
 
30(a).13.5. Physical Access Controls
 
Access to GMO’s office is controlled by security gates at the main entrance as well as the sub-entrance. All security gates, as well as the entrances to offices on each floor are secured with contactless IC cards, and access can be restricted to specific floors using the IC card. Visitors receive temporary IC cards by registering at the reception. Human security personnel are located at the gate 24x7.
 
 
30(a)13.6. Physical Security
 
 
30(a).13.6.1. Buildings
   
30(a).13.6.2. Offices
   
 
30(a).13.6.3. Computer Equipment
   
 
30(a).13.6.4. Network Equipment and Infrastructure
   
 
30(a).13.6.5. Portable Media
   
 
30(a).13.6.6. Physical Documents
   
 
30(a).13.7. Network Access Controls
   
 
30(a).13.8. Malware
   
 
30(a).13.9. User Accounts and Passwords
   
 
30(a).13.10. Communications with Stakeholders
   
 
 



© Internet Corporation For Assigned Names and Numbers.