ICANN New gTLD Application

New gTLD Application Submitted to ICANN by: GMO Registry, Inc.

String: TOKYO

Originally Posted: 13 June 2012

Application ID: 1-890-25253


Applicant Information


1. Full legal name

GMO Registry, Inc.

2. Address of the principal place of business

Cerulean Tower, 26-1 Sakuragaoka-cho, Shibuya-ku,
Tokyo 150-8512
JP

3. Phone number

+81 3 456 1601

4. Fax number

+81 3 3780 5239

5. If applicable, website or URL

http:⁄⁄www.gmoregistry.com

Primary Contact


6(a). Name

Mr. Hiroya TSUKAHARA

6(b). Title

Representative Director and CEO

6(c). Address


6(d). Phone Number

+81 3 5456 1601

6(e). Fax Number

+81 3 3780 2611

6(f). Email Address

newgtld@gmoregistry.com

Secondary Contact


7(a). Name

Mr. Yoshitake TAMURA

7(b). Title

Director

7(c). Address


7(d). Phone Number

+81 3 5456 1601

7(e). Fax Number

+81 3 3780 5239

7(f). Email Address

info@gmoregistry.com

Proof of Legal Establishment


8(a). Legal form of the Applicant

Corporation

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

The formation, organization, operation and management of companies are governed by the provisions of the “Companies Act” as set forth by the Ministry of Justice of Japan.
(Reference : http:⁄⁄law.e-gov.go.jp⁄htmldata⁄H17⁄H17HO086.html)

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.

GMO Internet, Inc.

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


Applicant Background


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

Hirokatsu OhigashiOutside Director
Hiroya TsukaharaRepresentative Director and CEO
Hiroyuki NishiyamaDirector
Masashi YasudaAuditor
Masatoshi KumagaiChairperson of the Board of Directors
Tadashi ItoDirector
Yoshitake TamuraDirector
Yusuke AdachiDirector

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

Hirokatsu OhigashiOutside Director
Hiroya TsukaharaRepresentative Director and CEO
Hiroyuki NishiyamaDirector
Masashi YasudaAuditor
Masatoshi KumagaiChairperson of the Board of Directors
Tadashi ItoDirector
Yoshitake TamuraDirector
Yusuke AdachiDirector

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

GMO Internet, 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.

TOKYO

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


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


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


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


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


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


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


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

Attachments are not displayed on this form.

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


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


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

GMO Registry, Inc. (the Applicant) has conducted technical analysis on the applied-for string, and concluded that there are no known potential operational or rendering issues associated with the string.

The following sections discuss the potential operational or rendering problems that can arise, and how GMO Registry mitigates them.

1. Compliance and Interoperability

The applied-for string conforms to all relevant RFCs, as well as the string requirements set forth in Section 2.2.1.3.2 of the Applicant Guidebook.


2. Mixing Scripts

If a domain name label contains characters from different scripts, it has a higher likelihood of encountering rendering issues. If the mixing of scripts occurs within the top-level label, any rendering issue would affect all domain names registered under it. If occurring within second level labels, its ill-effects are confined to the domain names with such labels.

All characters in the applied-for gTLD string are taken from a single script. In addition, GMO Registryʹs IDN policies are deliberately conservative and compliant with the ICANN Guidelines for the Implementation of IDN Version 3.0. Specifically, GMO Registry does not allow mixed-script labels to be registered at the second level, except for languages with established orthographies and conventions that require the commingled use of multiple scripts, e.g. Japanese.


3. Interaction Between Labels

Even with the above issue appropriately restricted, it is possible that a domain name composed of labels with different properties such as script and directionality may introduce unintended rendering behavior.

GMO Registry adopts a conservative strategy when offering IDN registrations. In particular, it ensures that any IDN language tables used for offering IDN second level registrations involve only scripts and characters that would not pose a risk when combined with the top level label.


4. Immature Scripts

Scripts or characters added in Unicode versions newer than 3.2 (on which IDNA2003 was based) may encounter interoperability issues due to the lack of software support.

GMO Registry does not currently plan to offer registration of labels containing such scripts or characters.


5. Other Issues

To further contain the risks of operation or rendering problems, GMO Registry currently does not offer registration of labels containing combining characters or characters that require IDNA contextual rules handling. It may reconsider this decision in cases where a language has a clear need for such characters.

GMO Registry understands that the following may be construed as operational or rendering issues, but considers them out of the scope of this question. Nevertheless, it will take reasonable steps to protect registrants and Internet users by working with vendors and relevant language communities to mitigate such issues.

- missing fonts causing string to fail to render correctly; and
- universal acceptance of the TLD;

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


Mission/Purpose


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

Tokyo, the capital city of Japan, has the highest GDP and the largest urban area population of any city in the world (United Nations, 2010).

The city is recognized as a world leader in technology and precision manufacturing, and its wholesale and retail sectors are renowned for quality, luxury and high-end products. Tokyo is at the center of both traditional and modern Japanese arts including drama, music, fine arts, anime, design, multi-media, and literature. The city is also home to the largest number of cultural assets in Japan and has the most Michelin star restaurants of any city in the world.

The purpose of .TOKYO is to promote Tokyo as a city, establish a unified online presence, and provide an opportunity for citizens, corporations, cultural institutions and community groups to link their identities to the city’s trusted and high profile brand. By bringing together high quality and informative content under a single TLD, the Applicant aims to establish .TOKYO as a platform to effectively deliver Tokyo related information to Internet users worldwide. The Applicant believes this in turn will benefit economy, industry, culture and community in Tokyo and make a valuable contribution to sectors as diverse as commerce, sport and tourism. The Applicant also hopes that through further raising the city’s profile on a global scale, it will contribute to an increased sense of pride and responsibility among the citizens and corporations of Tokyo. At the same, the Applicant believes it is important to achieve widespread registration and usage of .TOKYO in order to support these goals, and therefore domain name registration eligibility will be open to individuals and entities worldwide.

Furthermore, the Applicant hopes to see the current new gTLD application round produce multiple new geographic TLDs representing city names, and to be able to make a contribution to establishing the “city TLD” as a new genre of TLDs.

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

i.	What is the goal of your proposed gTLD in terms of areas of specialty, service levels, or reputation?

As a distinctive TLD representing Tokyo, .TOKYO provides a strong context and association for the domain names registered under it. As such, the Applicant expects .TOKYO to bring about expectations of increased marketing and branding values. The goal of the TLD in this respect is to build a high quality and meaningful domain name space to complement the inherent .TOKYO advantages: direct, simple, easy-to-understand, and memorable.

The Applicant believes that .TOKYO will bring about tangible benefits to the following groups of stakeholders:

For .TOKYO registrants: a namespace that effectively provides information on Tokyo, as well as businesses and services offered by the registrants.

For Internet users: a namespace where Internet users can discover new information about Tokyo and communicate with entities in the city in a safe and productive way.

For others: a TLD that contributes to growth of Tokyo.

Service Level
Registrants
Registration will be completely open in order to allow not only citizens and corporations of Tokyo, but also any individual or entity regardless of geographic location to register names in the TLD. The Applicant intends to price .TOKYO in a range reasonable enough to ensure it is universally accessible but not so low that it risks damaging its value as a TLD.

Promotion
The Applicant is planning to actively run promotions, rebate programs, and marketing programs.

Operation
The Applicant aims to operate the TLD in a secure and stable manner, adopting industry best practices where applicable. The Applicant’s operational goals are to have DNS load dispersion that is resistant to DDoS attacks, industry-leading level of Whois information change and DNS record change reflection time, substantial registrar support, and abuse window operation 24 hours a day, 365 days a year. The Applicant will also implement proven security measures at every level of the registry business and technical operation to provide maximum protection for its stakeholders. This includes stringent security policies and procedures, as well as comprehensive abuse handling mechanisms to mitigate security threats to the TLD. In addition, the Applicant will strive to provide an outstanding level of technical and operational support to the registrars.

Reputation
The Applicant aims to achieve a reputation for .TOKYO as a namespace that is trusted, safe, secure, relevant and enjoyable, in addition to widely used and well recognized.

In order to maintain high quality content and to avoid diminishing the reputation of Tokyo, the Applicant will develop a set of abuse policies and takedown procedures to handle abuse usage in a timely and appropriate manner. In addition, the Applicant will publish an information page on its website describing the recommended ways to use the TLD. The information page will include best practices for web contents and a list of prohibited activities under the TLD. The Applicant believes that the information page will help registrants understand the purpose of the TLD, preserve the characteristics of .TOKYO, and help mitigate abusive activities.


ii. What do you anticipate your proposed gTLD will add to the current space, in terms of competition, differentiation, or innovation?

While .TOKYO is a gTLD, as a city TLD it also shares some characteristics with ccTLDs. The Applicant believes that because .TOKYO differs from existing gTLDs, sTLDs, and ccTLDs, it promotes competition and encourages differentiation benefitting domain name registrants, Internet users, business, and the domain space.

The Applicant plans to leverage the characteristics “direct”, “simple”, “easy-to-understand”, and “memorable” and differentiate .TOKYO through the following activities;
- promotion and support of high quality websites;
- innovative marketing and outreach campaigns; and
- ensuring strong security and stability.
The Applicant believes that this will contribute to reducing cases of abusive use and help foster the development of a high quality namespace.

Local Identification with Brand
As a city TLD that directly represents a ʺplaceʺ, .TOKYO is expected to have brand appeal in the local market above and beyond .COM and .JP. The Applicant believes that the ability to link the registrant’s brand with the established, positive and high-profile image of Tokyo will benefit domain users and Internet users alike.

.TOKYO vs .JP
Outside of Japan, the countryʹs ccTLD has never been widely adopted due to high registration fees and limitations that require registrants to have an address in Japan. The Applicant believes that .TOKYO will be an attractive alternative to .JP for businesses and individuals who have been previously deterred by the obstacles to establishing a Japan web presence with .JP.
As a ccTLD, even within Japan, usage of .JP is low. Compared with German ccTLD, .DE that has over 14.5 million registered domain names, .JP has just 1.2 million registrations. This means that in Germany one person in every five has a .DE registration while in Japan the ratio is one in 105. Domain name registrations in .TOKYO will be offered at a lower price point than .JP, and for the first time there will be competition in the “Japanese TLD” market. The Applicant believes this will benefit both the end user and the Internet community as a whole in Japan.

.TOKYO vs .COM
While it is expected that the branding power of .COM will remain strong, the Applicant anticipates that in Japan and particularly in Tokyo, registrants may choose .TOKYO over .COM for its availability, relevance and local brand.

iii. What goals does your proposed gTLD have in terms of user experience?

The Applicant will endeavor to achieve the following goals relating to user experience:
1. Internet users find that the services and contents associated with .TOKYO domain names are relevant, and of high quality;
2. Internet users discover new things about Tokyo; and
3. Internet users are not exposed to abusive or malicious content.


iv. Provide a complete description of the applicant’s intended registration policies in support of the goals listed above.

Plans for .TOKYO domain name registration policies that support the stated goals are as follows. All .TOKYO TLD registrars and registrants must agree to abide by the policies. Failure to comply with the policies may result in denial, cancelation or transfer of any registration or transaction, or domain names being placed on lock, hold or similar status.

1. Scope of Registration Eligibility
The Applicant believes that broad registration and usage of .TOKYO is essential to the goal of promoting Tokyo as a brand and establishing the namespace as a platform for the effective delivery of Tokyo related information to Internet users worldwide. Therefore, domain name registration in the .TOKYO TLD will be open to all.

2. Recommended Usage of the TLD
The Applicant will recommend that registrants incorporate information related to Tokyo on websites in the .TOKYO space. Information about best practices and prohibited usage will be published on the Applicant’s website. Seeking to ensure that .TOKYO delivers high quality Tokyo related content supports the Applicant’s objective of making a positive contribution to the economy, industry, culture and community in Tokyo.

3. Draft Abusive Use Policy
The Applicant defines abuse as any activity that may harm the stability and security of the DNS and Internet, including, but not limited to:

- Illegal or fraudulent activities;
- Phishing;
- Pharming;
- Using or distributing malicious software (malware);
- Sending unsolicited bulk messages (spam);
- Posting, trading, or exchanging information that harms minors;
- Posting, trading, or exchanging child pornography;
- Posting information that encourages illegal acts, crimes, murders, or suicides;
- Posting information that is offensive to public order or morals; and
- Posting information that harms the national interest or reputation of Japan including Tokyo.

The Applicant 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.

In addition, the Applicant intends to set up an abuse support window (abuse report form and abuse support window) for .TOKYO that will be operated 24 hours a day, 365 days.

In case an abuse use is reported, the Applicant will promptly take appropriate measures in accordance with the suspension flow provided separately (Please refer to Question 28).

4. Accuracy of Registration Information
.TOKYO registrants are obligated to provide and maintain accurate, complete, and current registration information (Whois information).

Failure to comply with this policy may result in the domain name registration being denied, cancelled, or transferred; the Registry Operator shall also be entitled, in such cases, to delete any such domain names, or place them on lock, hold, or similar status.

5. ICANN Policies
The Applicant will adopt and comply with the Uniform Rapid Suspension System, Uniform Domain Name Dispute Resolution Policy, and all other ICANN policies, regulations, rules (collectively the “ICANN policies”), and all .TOKYO domain name registration will be subject to ICANN policies.

6. Website Best Practices Information Page
In order to help .TOKYO domain name registrants understand the purpose of the TLD, clearly publicize usage restrictions of the TLD, and encourage registrants to use .TOKYO domain names in an appropriate manner, the Applicant will publish an information page on its website describing recommended ways to use .TOKYO domain names. The information page is for information purposes only and will include best practices for web contents and a list of prohibited activities under the TLD.

All .TOKYO registrars will be required to place a link to the information page on their website or include it in domain name registration⁄renewal confirmation emails sent to the registrants.

Reserved Domain Names
The names of wards, cities, towns and villages in Tokyo, strings related to tourism and transportation in Tokyo, and other names related to the public interest will be reserved initially. These names may be released and used to promote Tokyo prefecture and activate the economy, industries and culture of Tokyo. The list of reserved domain names shall be revised upon request of the Tokyo Metropolitan Government.


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

.TOKYO will comply with the applicable laws of Japan and regulations of respective governments, as well as applicable ICANN consensus policies. As part of its responsibility as registry operator of the TLD, the Applicant will exercise due care to protect all information it receives from registrants or users through registrars, and will not disclose such information to any third party, with the exception of public Whois data.

The Applicant does not provide any additional measures beyond its obligation as a registry operator. The Applicant places no restrictions on the use of Whois proxy services, to the extent permissible by law.

Describe whether and in what ways outreach and communications will help to achieve your projected benefits.

Communication with Registrars
In order to achieve the projected benefits, .TOKYO must gain substantial mindshare among Internet users. The Applicant believes that the primary method of increasing recognition and registration numbers in the TLD is to gain strong support from .TOKYO registrars. For that reason, the Applicant intends to:
 Maintain regular communication with registrars;
 Attend ICANN meetings and domain name⁄Internet related events and have face to face meetings with registrars; and
 Organize events for registrars
Feedback from registrars will be then taken into account, and integrated into public relations and marketing activities that the Applicant organizes where appropriate.

Website Contests
Website contests will be held for websites using .TOKYO domain names. Events will be held on an irregular basis incorporating a wide range of themes such as web design contests aimed at promoting Tokyo culture and creativity, and informative sightseeing website contests aimed at tourism development. The objective of such contests is not only to encourage .TOKYO domain name registrants to create higher quality websites, but also to broaden recognition of .TOKYO. The top scoring websites will be actively promoted as use cases to further increase the profile of the TLD.

Briefing Sessions⁄Events Organized by the Applicant
The Applicant is planning to have domain related briefing sessions in Tokyo for registrars and resellers because it believes that close communications and industry networking, as well as the exchange of information on registry statistics, policies and technologies, is important to continually improve quality and boost number of registrations in the .TOKYO namespace. In addition, the Applicant is planning to hold events for registrars during the ICANN meetings to communicate and exchange ideas with registrars.

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

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

Multiple applications for a particular domain name for general registration will be resolved on a first-come-first-served basis as are current gTLDs. However, multiple applications for a particular domain name during the .TOKYO initial launch phase will be resolved as follows:

Sunrise Registration Process
- Auction

Priority Registration Process
- First-come-first-served

Landrush Process
- Auction

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

In order to encourage new registrations and renewals of .TOKYO domain names, the Applicant will run campaigns or rebate programs from time to time. The Applicant believes it is important to run campaigns that meet the needs of registrars; therefore, it will exchange ideas with registrars and make an effort to run campaigns that reflect registrar input. The Applicant promises equal treatment for all .TOKYO registrars.

The planned campaigns⁄rebate programs are as follows:

New Registration Promotion
This is a promotion that provides discounts on first year registration fees of new domain names registered during a predetermined period. The discount will be provided in the form of a rebate credit to the registrar’s account at the end of the campaign period. Registrars interested in the promotion will need to sign up and may be required to deliver the benefit to registrants in some way (i.e. provide registrants with discounts on new registrations).

Bulk Registration Rebate Program
This is a promotion that provides a volume discount on the first year registration fee of new domain names registered during a predetermined period. The amount of rebate will depend on the volume of the new registrations made during the campaign. The discount will be provided in the form of a rebate credit to the registrar’s account, at the end of the campaign period. Registrars interested in the promotion will need to sign up.

Co-Marketing Program
This program is aimed at expanding recognition of the TLD whereby the Applicant will bear part of the marketing cost of promotions relating to the TLD, conducted by registrars. All registrars interested in the program will be required to sign up and discuss details of the marketing plan in advance with the Applicant.

Community-based Designation


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

No

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


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


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


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


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


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

Attachments are not displayed on this form.

Geographic Names


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

Yes

Protection of Geographic Names


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

GMO Registry, Inc. (the Applicant) will comply with Specification 5 “Schedule of Reserved Names at the Second Level in gTLD Registries” of the ICANN New gTLD Agreement. In particular, names covered under the Country and Territory Names section of the said schedule shall be initially reserved on the second level. The names are:

- the short form (in English) of all country and territory names contained on the ISO 3166-1 list, as updated from time to time, including the European Union, which is exceptionally reserved on the ISO 3166-1 list, and its scope extended in August 1999 to any application needing to represent the name European Union 〈http:⁄⁄www.iso.org⁄iso⁄support⁄country_codes⁄iso_3166_code_lists⁄iso-3166-1_decoding_table.htm#EU〉;
- the United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardization of Geographical Names, Part III Names of Countries of the World; and
- the list of United Nations member states in 6 official United Nations languages prepared by the Working Group on Country Names of the United Nations Conference on the Standardization of Geographical Names;

At a later time, the Applicant may propose that ICANN release specific country and territory names, subject to the registry reaching agreement with the applicable government(s), the Governmental Advisory Committee (GAC) review and approval by ICANN. Rules and procedures for the release of such names will be agreed upon between ICANN and the Applicant.

The Applicant is considering the following procedures for releasing specific country and territory names, subject to ICANN approval:

1. In order for specific country and territory names to be released and become available for .TOKYO stakeholders to register, the Applicant shall submit a proposal letter to ICANN and the GAC including, at minimum, the following:
A. The list of country and territory names which the registry requests for release; and
B. Purpose of releasing the names listed above;
2. ICANN and the GAC review the proposal letter and inform of the proposal to the relevant government(s);
3. Each of the relevant governments takes the following action:
A. If the government approves or does not object to the proposal, it replies with its decision of “approval” or “non-objection” by a due date set and agreed upon by ICANN, the GAC, and the Applicant; or
B. If the government does not approve the proposal, it replies with a “non-approval” decision by a due date set and agreed upon by ICANN, the GAC, and the Applicant.
4. If a reply is not received by the due date agreed upon by ICANN, the GAC and the Applicant, or the government replied with an “approval” or “non-objection” decision, the names may be released for registration.
5. In case the government replied with a “non-approval” decision, the government and the Applicant may enter negotiation to attempt to reach agreement, and only upon reaching agreement shall the names be released.
6. Potential registrants of the names shall send registration requests to the Applicant. The request must include the following information:
A. Domain name(s) the registrantt wishes to register;
B. A pledge the registrant understands the purpose and rules of the domain name registration and use included in the proposal letter described 1.A. above; and
C. A pledge the registrant abides by the purpose and rules of the domain name registration and use included in the proposal letter described 1.A. above;
7. The Applicant reviews the request and checks availability of the requested name. In case the Applicant approves the request, it issues a “code.”
Note: The availability check is conducted to see whether the requested domain name has been already requested and registered by another registrant.
8. Using the “code,” the registrant requests the domain name registration through a .TOKYO accredited registrar.

In addition to the reserved geographic names specified by ICANN, the Applicant intends to initially reserve the following geographic names at the second level in .TOKYO TLD:
- Names of wards, cities, towns, and villages in Tokyo; and
- Other geographic names required by the respective government(s)

As the responsible use of these names is in the public interest, methodology to release these names will be determined by the respective government(s) and the Applicant. The list of the reserved geographic names will be posted at the registry website and it shall be revised upon a request made by the respective government(s).

Names of Wards, Cities, Towns, and Villages in Tokyo
The names reserved in this category are determined based on the ward, city, town, and village names listed in “Municipalities within Tokyo” on the Tokyo Metropolitan Government website at http:⁄⁄www.metro.tokyo.jp⁄ENGLISH⁄LINKS⁄links1.htm. All names listed below will be reserved:

- Full names of wards, cities, towns, and villages: ward, city, town, and village names and ward (ku in Japanese), city (shi in Japanese), town (machi in Japanese), or village (mura in Japanese) are connected with a hyphen
- i.e. Chiyoda-ku, Kiyose-shi, Mizuho-machi, Hinohara-mura
- names of the wards, cities, towns and villages with ku, shi, machi, and mura without a hyphen in between
- i.e. Chiyodaku、Kiyoseshi、Mizuhomura、Hinoharamura
- the short form of ward, city, town, and village names without hyphen (-) and “ku,” “shi,” “machi,” or “mura”
- i.e. Chiyoda, Kiyose, Mizuho, Hinohara

Other Geographic Names
Geographic names that the respective government(s) to reserve from registrations at the second level in .TOKYO TLD will be initially reserved.

Registry Services


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

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:
• Uniform Domain Name Dispute Resolution Policy
• Inter-Registrar Transfer Policy
• Whois Marketing Restriction Policy
• Restored Names Accuracy Policy
• Expired Domain Deletion Policy
• AGP Limits Policy

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 .TOKYO 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:
• Senior Technical Developer x 2
• Technical Developer x 3
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.

Demonstration of Technical & Operational Capability


24. Shared Registration System (SRS) Performance

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 .TOKYO 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)

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:
• 5730 - Base Protocol
• 5731 – Domain Objects
• 5732 - Host Objects
• 5733 - Contact Objects
• 5734 - TCP Transport
• 3735 - Extension Guidelines
• 3915 - RGP Extension
• 5910 - DNSSEC Extension

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:
• domains (RFC 5731)
• host objects (RFC 5732)
• contact objects (RFC 5733)

25.1.2. Commands supported
GMO will support the following EPP commands:
• ⟨hello⟩ - retrieve the “greeting” from the server
• ⟨login⟩ and “logout” - session management
• ⟨poll⟩ - message queue management
• ⟨check⟩ - availability check
• ⟨info⟩ - object information
• ⟨create⟩ - create object
• ⟨update⟩ - update object
• ⟨renew⟩ - renew object
• ⟨delete⟩ - delete object
• ⟨transfer⟩ - manage object transfer

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:create⟩command. 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:
• approved inbound transfer
• rejected inbound transfer
• new outbound transfer
• cancelled outbound transfer
• approved or rejected domain registration request (where TLD policy requires out-of-band approval of ⟨domain:create⟩ requests)

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:
• Net::EPP, a general purpose EPP library for Perl. See http:⁄⁄code.google.com⁄p⁄perl-net-epp⁄
• Preppi, a graphical EPP client written in Perl. See https:⁄⁄www.centralnic.com⁄company⁄labs⁄preppi
• Net_EPP, a PHP client class for EPP. See https:⁄⁄github.com⁄centralnic⁄php-epp
• Simpleepp, a Python client class for EPP. See https:⁄⁄bitbucket.org⁄milosn⁄simpleepp
• tx-epp-proxy, a EPP reverse proxy for shared-nothing client architectures written in Python. See https:⁄⁄bitbucket.org⁄milosn⁄tx-epp-proxy
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

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:
• Domain ROID
• Domain Name
• Domain U-label (if IDN)
• Creation Date
• Last Updated
• Expiration Date
• EPP status codes
• Registrant Contact Information
• Administrative Contact Information
• Technical Contact Information
• Billing Contact Information (if any)
• Sponsoring Registrar ID
• Sponsoring Registrar Contact Information
• DNS servers (if any)
• DNSSEC records (if any)
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:
• PENDING CREATE - a ⟨domain:create⟩ command has been received through the SRS, but the registration has not yet been finalised as an out-of-band review process has not yet been completed.
• ADD PERIOD - the domain is in the Add Grace Period
• CLIENT HOLD - the registrar has added the clientHold status
• DELETE PROHIBITED - this may be present if the domain has either clientDeleteProhibited or serverDeleteProhibited (or both)
• INACTIVE - the domain has no DNS servers
• PENDING DELETE - the domain has left the Redemption Grace Period and is scheduled for deletion
• PENDING DELETE RESTORABLE - the domain is in the Redemption Grace Period
• PENDING RESTORE - a restore request has been received, but the Restore Report has not been received
• PENDING TRANSFER - there is an active inter-registrar transfer for the domain
• RENEW PERIOD - the domain is either in the Renew Grace Period or the Auto-Renew Grace Period
• RENEW PROHIBITED - this may be present if the domain has either clientRenewProhibited or serverRenewProhibited (or both)
• SERVER HOLD - the registry has added the serverHold status
• TRANSFER PERIOD - the domain is in the Transfer Grace Period
• TRANSFER PROHIBITED - this may be present if the domain has either clientTransferProhibited or serverTransferProhibited (or both)
• UPDATE PROHIBITED - this may be present if the domain has either clientUpdateProhibited or serverUpdateProhibited (or both)
• OK - present if none of the above apply.
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:
• Contact ID
• Sponsoring Registrar
• Creation Date
• Last Updated Date
• EPP Status Codes
• Contact Name
• Organisation
• Street Address (1-3 fields)
• City
• State⁄Province
• Postcode
• Country Code (2 character ISO-3166 code)
• Phone number (e164a format)
• Fax number (e164a format)
• Email address
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:
• DELETE PROHIBITED - present if the contact object has either clientDeleteProhibited or serverDeleteProhibited (or both)
• TRANSFER PROHIBITED - present if the contact object has either clientTransferProhibited or serverTransferProhibited (or both)
• UPDATE PROHIBITED - present if the contact object has either clientUpdateProhibited or serverUpdateProhibited (or both)
• PENDING TRANSFER - there is an active inter-registrar transfer for the contact object
• LINKED - the contact object is associated with one or more domain names. A LINKED contact object automatically has the DELETE PROHIBITED status

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:
• Server Name
• IPv4 address (if any)
• IPv6 address (if any)
• EPP status codes
• Sponsoring Registrar
• Creation Date
• Referral URL (if any)
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:
• INACTIVE - the host is not associated with any domain names
• LINKED - the host is associated with one or more domain names
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:
• domain name (partial match)
• registrant name, organisation, address, email
• administrative, technical and billing contact information
• Nameservers
• Nameserver IPv4⁄IPv6 address
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

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:
• auto-renewal of expired domains
• processing of domains in the RGP state (from restorable to not restorable, checking for missing restore reports, etc)
• purging of domains scheduled for deletion
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.

28. Abuse Prevention and Mitigation

In order to safeguard the security and stability of .TOKYO, as well as the Internet at large, GMO Registry, 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:
• developing and publishing a set of comprehensive abuse policies including clear definitions of abusive activities;
• establishing and publishing a single abuse point of contact to address and resolve abuse complaints at registry startup and on an ongoing basis;
• developing procedures for handling complaints, including takedown requests, in a timely manner; and
• publishing Website Best Practices Information Page to introduce website best practices and prohibited activities under the TLD.

28.1. 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:
• Illegal or fraudulent activities;
• Phishing;
• Pharming;
• Using or distributing malicious software (malware);
• Sending unsolicited bulk messages (spam);
• Posting, trading, or exchanging information that harms minors;
• Posting, trading, or exchanging child pornography;
• Posting information that encourages illegal acts, crimes, murders, or suicides;
• Posting information that is offensive to public order or morals; and
• Posting information that harms the national interest or reputation of Japan including the respective prefecture and city.
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.2. 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 the registry publicly releases the .TOKYO domain name registration policies. The abuse public contact will be responsible for handling complaints concerning abusive activities relating to domains registered under the .TOKYO TLD that violate the Abusive 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.3. 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.4. Draft Takedown Procedure
• Complaint is submitted using the abuse complaint form via email or the registry web site;
• Upon receiving a complaint, the registry’s operational and registrar support team will
• assign a ticket number
• review complaint form
• request additional information if complaint form is deemed insufficient to carry out effective investigation
• investigate the complaint to verify accuracy, and to record proof of abuse
• based on the nature of the abuse, assign level of severity: normal or emergency
• Emergency: the registry will suspend the domain name in question and close the complaint ticket. At the same time, it will open a ticket to inform the sponsoring registrar of the suspension along with the reason.
• Normal: open a ticket to inform the sponsoring registrar to take corrective actions. The registrar must inform the registry of actions taken. If the registrar does not take any action (that includes no response from the registrar) within a reasonable timeframe, the registry will suspend the domain name in question and close the complaint ticket.
• If the domain name was suspended by the registry, and the situation is remedied by the registrant, the registrar will contact the registry via the ticket number. Our operational and registrar support team will verify that the issue has indeed been remedied and re-enable the domain name, closing the ticket.
• All actions by the operational and registrar support team will be logged
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 its abuse policies and procedures from time to time.
28.5. Website Best Practices Information Page
In order to have high quality contents on websites in the .TOKYO name space, the registry believes that it is important to mitigate abusive activities on the websites.
In addition to the mitigation mechanism described above, the registry will publish an information page on its website. The information page will include a list of prohibited activities under the TLD as well as best practices for web contents. The registry believes that the information page would help registrants understand the purpose of the TLD, clearly publicize usage restrictions of the TLD, and help mitigate abusive activities.
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.

29. Rights Protection Mechanisms

GMO Registry, Inc. (the Applicant) 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 Applicant will adopt the following policies and practices:


• Sunrise Registration Process
• Priority Registration Process
• Trademark Claims Service
• Uniform Rapid Suspension (URS) System
• Uniform Domain Name Dispute Resolution Policy (UDRP)
• Abusive Use Policy
• Website Best Practices Information Page


29.1.Sunrise Registration Process
Before any registration of .TOKYO domain name registration processing starts, Sunrise registration process using the Trademark Clearinghouse required by ICANN will be available for trademark holders.

The Applicant will establish and publish a set of Sunrise Eligibility Requirements (SERs) and adopt a Sunrise Dispute Resolution Policy (SDRP). SERs and SDRP will be applied to all .TOKYO domain names registered during the Sunrise Registration and all .TOKYO registrars and registrants must agree to abide by the SERs and SDRP.

29.2.Sunrise Eligibility Requirements
In accordance with the section entitled “Trademark Clearinghouse” of the Application Guidebook (January 11, 2012 version), .TOKYO SER will at least include
• Acceptable marks:
o nationally or regionally registered and for which proof of use (which may be a declaration and a single specimen of current use) was submitted to, and validated by, the Trademark Clearinghouse;
o that have been court-validated; or
o that are specifically protected by a statute or treaty currently in effect and that was in effect on or before 26 June, 2008
• representation that all provided information is true and correct;
• provision of data sufficient to document rights in the trademark; and
• the registrant of the domain name must be the owner of a corresponding registered mark in the Trademark Clearinghouse.

29.3.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 Tokyo, etc.) will be developed by the registry before the registration phase opens.

29.4.Other Rules for Sunrise Registration Process
• The Sunrise Registration Process will be run for at least 30 days which is the period required by ICANN. However, the registry may run the process longer if it is recommended by the Tokyo Metropolitan Government.
• During the Sunrise Registration Process, a domain name can be registered for 2-10 years.
• Multiple validated applications for the same domain name will be resolved by auctions.
• Deletion, renewal, and transfer of a Sunrise domain name will be prohibited for 60 calendar days after the domain name is successfully registered.

29.5.Sunrise Dispute Resolution Policy
As required by ICANN, proposed .TOKYO SDRP will allow challenges based on at least the following four grounds:
• at the time the challenged domain name was registered, the registrant did not hold a trademark registration of national effect (or regional effect) or the trademark had not been court-validated or protected by statute or treaty;
• the domain name is not identical to the mark on which the registrant based its Sunrise registration;
• the trademark registration on which the registrant based its Sunrise registration is not of national effect (or regional effect) or the trademark had not been court-validated or protected by statute or treaty; or
• the trademark registration on which the domain name registrant based its Sunrise registration was not issued on or before the effective date of the Registry Agreement and was not applied for on or before ICANN announced the applications received.


29.6.Priority Registration Process for Registered Companies and Organization in Tokyo
.TOKYO TLD is for the region of Tokyo and the Applicant believes that it is important that business owners in Tokyo should be offered an opportunity to secure their identities in the TLD space on a priority basis in order to reduce chances of abusive registrations. Therefore, the Applicant will offer a priority registration process for owners of legally registered companies and organizations in Tokyo.

29.7.Eligibility Requirements for Priority Registration
The Applicant will establish and publish a set of Eligibility Requirements for Priority Registration and Priority Registration Dispute Resolution Policy. Eligibility Requirements for Priority Registration and Priority Registration Dispute Resolution Policy will be applicable to all .TOKYO domain names registered during the Priority Registration phase and all .TOKYO TLD registrars and registrants must agree to abide by the Eligibility Requirements and Dispute Resolution Policy.

.TOKYO Eligibility Requirements for Priority Registration will at least include
• legally registered companies and organizations registered in Tokyo, Japan are eligible to apply for domain names during the Priority Registration;
o the company registrations must be registered on or before XX⁄XX⁄XX (TBD) and valid at the time of the domain name application is submitted;
• the registrant of the domain name must correspond with the name of the registered company or organization; and
• representation that all provided information is true and correct.

The region of Tokyo is Tokyo’s 23 wards and cities, towns, and villages in Tokyo listed in the ʺMunicipalities within Tokyo” published by Tokyo Metropolitan Government at http:⁄⁄www.metro.tokyo.jp⁄ENGLISH⁄LINKS⁄links1.htm

Japanese Version: http:⁄⁄www.metro.tokyo.jp⁄LINK⁄link1.htm

29.8.Acceptable Domain Name Strings during the Priority Registration Process
Domain name strings applied for during the Priority Registration process must be exactly identical to the Romanized name of the applicant’s company or organization (exceptions are listed below).
• If the company or organization name contains Roman strings, those strings must appear in the applied for domain name without modification.
• If the company or organization name contains Arabian numerals, those numerals may be used without modification, transliterated into Japanese, or translated into English.
• If the company or organization name contains Katakana (カタカナ in Japanese,) the Katakana may be Romanized or translated into English.
• If the company or organization name contains a special character “&”, it can be spelled out or replaced by “- (hyphen)“.
• Other special rules (i.e. for company or organization name contains special characters, spaces, punctuations, the word Tokyo etc.) will be developed by the registry before the registration phase opens.

29.9.Proof of Requirements
All applicants during the Priority registration process will be required to prove the companies or organizations are legally established in Tokyo by submitting a copy of their company registration (Tokibo in Japanese) electronically at the time of .TOKYO domain name registration. The registry and⁄or a verification company appointed by the registry will validate the submitted copy of the company registration before the applied domain name is allocated (registered). The registry or verification company may ask for additional information⁄document (i.e. proof of use) if necessary.

29.10.Other Rules for Priority Registration Process
• The Priority Registration Process is planned to run between the Sunrise Registration Process and general registration.
• The Priority Registration Process is planned to be run for 30 days. However, the registry will run the process longer if it is recommended by the Tokyo Metropolitan Government.
• During the Priority Registration Process, a domain name can be registered for 2-10 years.
• Multiple validated applications for the same domain names will be resolved on a first-come-first-served basis during the process.
• Deletion, renewal, and transfer of a domain name registered during the Priority Registration Process will be prohibited for 60 calendar days after the domain name is successfully registered.

29.11.Priority Registration Dispute Resolution Policy
In order to provide an opportunity for people who wish to dispute potential violations of the eligibility requirements for Priority Registration, the registry will establish a dispute resolution policy mechanism for Priority Registration. Alternatively, the registry may provide a public complaint service to allow third parties to make a complaint regarding potential violations of the eligibility requirements for Priority Registration process. Priority Registration Dispute Resolution Policy will be applicable to all .TOKYO domain names registered during the Priority Registration and all .TOKYO TLD registrars and registrants must agree to abide by the policy.

The Priority Registration Dispute Resolution Policy is proposed to allow complaints based on the following grounds:
• at the time the domain name was registered, the company or organization was not registered in Tokyo;
• the registration of the company or organization on which the Priority Registration was based was not registered on or before the cut-off date;
• the domain name is not identical to the name of the company or organization on which the Priority Registration was based; or
• the registrant of the domain name is not the owner of the registered company or organization on which the Priority Registration was based.


29.12.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 general registration opens. However, the registry may revise the length of this period if ICANNN requirements are amended or it is recommended by the Tokyo Metropolitan Government.

29.13.URS System
The Applicant 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 .TOKYO TLD registrars and registrants must agree to abide by the URS System.

29.14.UDRP
In addition to the URS System, UDRP will be applied to all .TOKYO domain name registrations and all .TOKYO registrars and registrants must agree to be bound by UDRP.

29.15.Abusive Use Policy
In addition to the policies and practices described in this section, the Applicant 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.16.Website Best Practices Information Page
In addition to the mitigation mechanism described above, the Applicant will publish an information page on its website. The information page will include a list of prohibited activities under the TLD as well as best practices for web contents. The Applicant believes that the information page will help registrants understand the purpose of the TLD, clearly publicize usage restrictions of the TLD, and help mitigate abusive activities. All .TOKYO registrars will be required to place a link to the information page on their website or include it in domain name registration⁄renewal confirmation emails sent to the registrants.

The Applicant believes that the information page will help registrants understand the purpose of the TLD, assure the usage characteristics of the TLD, and help mitigate abusive activities.
29.17. 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.

30(a). Security Policy: Summary of the security policy for the proposed registry

30(a).1. Introduction
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 .TOKYO 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 .TOKYO 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 .TOKYO requires no additional security levels above those expected of any gTLD registry operator. Nevertheless, GMO will operate .TOKYO 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 .TOKYO registrars:
• The SRS will be operated in a secure manner. Controls will be in place to prevent unauthorised access and modification of registry data.
• The Whois service will prevent unauthorised bulk access to domain name registration data, and provide tools to protect personal information.
• The DNS system will be designed to provide effective defence against DDoS attacks. The registry will proactively monitor the DNS system to provide early warning against threats to the stability of .TOKYO.
• The DNSSEC system will be operated in accordance with best practices and recommendations as described in the relevant RFC documents (described in §43).
• Security incidents reported by registrars, registrants and other stakeholders will be acted upon in accordance with the Security Incident Response Policy (see below).
• Security vulnerabilities reported to the registry will be acknowledged and remediated as quickly as possible.
• Registrars will be promptly notified of all incidents that affect the security and stability of the registry system and their customers, and will be kept informed as incidents develop.

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:
• Review and monitor information security threats and incidents.
• Approve initiatives and methodologies to enhance information security.
• Agree and review the security policy, objectives and responsibilities.
• Review client requirements concerning information security.
• Promote the visibility of business support for information security company-wide.
• Manage changes to 3rd party services that may impact on Information Security
• Perform internal audits with the assistance of qualified consultants.

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 .TOKYO registry system.
30(a).13.1. Controls on Confidential Data

Data that relate to .TOKYO 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

• Security, Access Control and CCTV
• Cameras installed at every entrance and at the perimeter of the facility
• Security access control is centralized
• Fence surrounds the facility backed up by security patrols.
• Logbook at entrance for records of all entrances into the Premises

30(a).13.6.2. Offices

• Proximity card with pin grants access to authorized personnel only.
• Cameras installed at every entrance into the building


30(a).13.6.3. Computer Equipment

• Proximity card with pin grants access to authorized personnel only.
• Every user has a designated workstation with monitored network access.
• Each workstation, laptop and tablet is password protected, and all passwords are changed regularly in line with policy.


30(a).13.6.4. Network Equipment and Infrastructure

• Equipment is located in a secured area that has an electric door with Logbook at the entrance for records of entry into the data centre.
• No staff are allowed to access equipment except authorized engineers
• Proximity card with pin grants access to authorized personnel only.
• All network infrastructure is secured in trunking and conduits, routine maintenance ensures that trunking is well secured and intact
• Wireless transmitters are placed beyond reach and well secured in braces.


30(a).13.6.5. Portable Media

• Staff are assigned USB sticks that are only authorized for internal storage and transfers.
• No portable media that belongs to company is allowed outside without express permission


30(a).13.6.6. Physical Documents

• Each business unit has a designated cabinet where they keep documents under lock and key
• All company documents are required to be filed and archived as necessary in chronological order.
• Access to these files is restricted to the said business unit unless by express authorization from the unit manager


30(a).13.7. Network Access Controls

• Network equipment is located in a secured area that has an electric door with Logbook which records all entry into the data centre.
• No staff are allowed to access equipment except authorized engineers
• All workstations, laptops, tablets, and printers are configured not to allow access to network settings except to the network administrator.
• Firewalls, routers and all network equipment have secured passwords that are changed regularly
• Each business unit has its own VPN which restricts users from access beyond their own VPN
• Users have access times and tickets which ensure that no one can access devices except during authorized hours.


30(a).13.8. Malware

• Staff are not allowed to access websites that are not work related and an access log for each PC is produced periodically to check this.
• Scanning for malware is required for media from outside of the organization before it can be used.
• Email file attachments, including compressed files (e.g., .zip files), must be saved to local drives or media and scanned before they are opened.
• The sending or receipt of certain types of files (e.g., .exe files) via email is prohibited and certain additional file types are blocked for a period of time in response to an impending malware threat.
• Use of unnecessary software, such as user applications that are often used to transfer malware (e.g., personal use of external instant messaging, desktop search engine, and peer-to-peer file sharing services), and services that are not needed or duplicate the organization-provided equivalents (e.g., email) and might contain additional vulnerabilities that could be exploited by malware is restricted or forbidden.
• The use of administrator privileges by users is restricted, which limits the privileges available to malware introduced to systems by users.
• Systems must be kept up-to-date with OS and application upgrades and patches
• The use of removable media (e.g., floppy disks, compact discs, USB flash drives) is restricted, particularly on systems that are at high risk of infection.
• The types of preventive software (e.g., antivirus software, spyware detection, and removal utilities) required for each type of system (e.g., file server, email server, proxy server, workstation, personal digital assistant [PDA]) and application (e.g., email client, Web browser) are specified, and the high-level requirements for configuring and maintaining the software are listed.
• Access to other networks (including the Internet) is permitted only through organization-approved and secured mechanisms
• Firewall configuration changes must be approved through a formal process
• The types of mobile code may be used from various sources (e.g., internal Web servers, other organizations’ Web servers) is specified.
• The use of mobile devices on trusted networks is restricted.
• All workstations, laptops and servers are installed with antivirus software which automatically updates virus signature files to detect malicious software.


30(a).13.9. User Accounts and Passwords

• All the devices that are connected to the network are accessed via a domain logon which mean that they must connect to a domain and cannot be accessed as standalones except during repairs and maintenance by authorized staff.
• Users are not allowed to have the same password on multiple systems.
• Account Lockout Policy settings disable accounts after a specific number of unsuccessful logins. Disabled accounts can then be restored by the system administrator after proper explanation of the reasons why account was disabled.
• The system has an enforceable password history to ensure that all new passwords are unique, also there is a maximum password age after which the user is required by the system to automatically change passwords.
• Passwords must meet complexity requirements, i.e. contain uppercase, lowercase, numerals, non-alphanumeric and Unicode characters. This ensures that all passwords are strong enough.
• All accounts and devices connected to specific domains are subject to a routine audit to ensure that vulnerabilities and illegal attempts to log in are mitigated and assessed.


30(a).13.10. Communications with Stakeholders

• GMO has in place mechanisms to enable unrestricted access to the local law enforcement officers that are in proximity to the organizations offices.
• GMO will establish a code of communication and format with which to reach ICANN as the authority , these communications will include mandatory routine communications required between the registry and ICANN as per normal registry operations
• In conjunction to above normal operations, GMO intends to communicate to ICANN in cases where there is need for urgent mitigation measures arising from issues related to running of registry, conflicts and all other issues that may arise in the course of normal business.
• GMO will keep a log of all relevant emails, fax and telephone numbers to be used appropriately for each communication.
• Alternative ways to complete all remittances have been made in advance should the normal authorized channels be unavailable due to unavoidable circumstances to ensure that all regular operations are sustained.
• In cases where such measures cannot be carried out completely, appropriate notifications shall be made to ICANN or any other affected persons in advance to explain failure to perform the regular actions thereof via email.



© Internet Corporation For Assigned Names and Numbers.