Application Preview

Application number: 1-1042-13015 for GREE, Inc.

Generated on 11 06 2012


Applicant Information


1. Full legal name

GREE, Inc.

2. Address of the principal place of business


3. Phone number

+81 3 5770 9500

4. Fax number

+81 3 5700 9600

5. If applicable, website or URL

http:⁄⁄www.gree.co.jp⁄

Primary Contact


6(a). Name

Mr. Yasuhiko Hasegawa

6(b). Title

Director ⁄ General Counsel

6(c). Address


6(d). Phone Number

+81 3 5770 9411

6(e). Fax Number

+81 3 5770 9600

6(f). Email Address

[email protected]

Secondary Contact


7(a). Name

Mr. Hirokatsu Ohigashi

7(b). Title

Executive Director

7(c). Address


7(d). Phone Number

+81 3 5456 1601

7(e). Fax Number

+81 3 3780 5239

7(f). Email Address

[email protected]

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.

Not Available

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

Tokyo_Stock_Exchange

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


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


Applicant Background


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

Kiyohito HamadaAuditor
Kotaro YamagishiExecutive Vice President
Masaki FujimotoSenior Vice President and Chief Technical Officer
Naoki AoyagiSenior Vice President and Chief Financial Officer
Takeshi NatsunoMember of the Board of Directors
Toru NagasawaAuditor
Toshitake AmamiyaMember of the Board of Directors
Yoshikazu TanakaFounder and Chief Executive Officer
Zenichiro TanakaAuditor

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

Kiyohito HamadaAuditor
Kotaro YamagishiExecutive Vice President
Masaki FujimotoSenior Vice President and Chief Technical Officer
Naoki AoyagiSenior Vice President and Chief Financial Officer
Takeshi NatsunoMember of the Board of Directors
Toru NagasawaAuditor
Toshitake AmamiyaMember of the Board of Directors
Yoshikazu TanakaFounder and Chief Executive Officer
Zenichiro TanakaAuditor

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

Yoshikazu TanakaFounder and Chief Executive Officer

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.

gree

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.

Not Available

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 (the backend registry) 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 behaviour.

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.

GREE, Inc. (hereafter ʺthe company”) operates the SNS community, GREE as well as an Internet Media business and has done so since it was first established.
GREE began from the passion and principle that “We can make the world a better place through the power of the Internet.” Since the day we started, we have been exploring the new potential of the Internet and working to provide innovation as soon as possible, to as many people as possible. The changes the Internet will have on the world have only just begun. There is infinite potential that remains to be discovered. To bring this potential into the world, GREE will continue to put our passion and principle into action, in order to provide enjoyment and happiness to our usersʹ lives and make our society more open and convenient.

.gree will be a domain for the SNS community GREE (hereafter “the community”), the company GREE, and our stakeholders. The primary purpose of .gree is to consolidate the various domain names held by the GREE SNS community, the company, and its stakeholders under a single TLD. In addition, the company aims to achieve the following goals.
1. Alleviating user confusion and improving convenience for Internet users
The company has registered many domain names under various gTLDs and ccTLDs not only for actual use but also as a defensive measure to protect the community and the company trademarks. Despite these efforts, there are still many domain name registrations and websites that infringe the trademark rights of GREE, Inc. and the community. As a result, Internet users can have difficulty differentiating bona fide websites from fraudulent ones. Positioning .gree as the official domain for the company and the community, and unifying the company’s and the community’s web presence under .gree, would provide easy access and interaction which we believe would reduce confusion and improve user experience.

2. Marketing ⁄ Branding
Since .gree is a brand new TLD that directly represents the community⁄brand name, the company expects it to be a highly effective marketing and branding tool. The company believes that .gree will not only reinforce the GREE brand on the Internet, but also attract people to the website because .gree domain names make it easier for both members of the GREE community and Internet users in general to access information related to the company and community. We believe that this will help contribute to growth and development of the community.

3. Simplifying domain name management
The third purpose in applying for .gree is to simplify the management of domain names the company has registered. As stated earlier, the company has many GREE related domain names under the various TLDs, and in managing these domain names, we are forced to deal with different registration and operation rules, log-in systems, etc. Acquiring .gree will make it possible to manage domain names under a single rules and systems umbrella. As a result, community members will be able to use the company’s services with confidence, and managing domain names will be safer and easier than ever before for .gree stakeholders.

18(b). How proposed gTLD will benefit registrants, Internet users, and others

Specialty
.gree is a TLD for the SNS community GREE, the company, and its stakeholders (companies listed in the annual securities report of GREE, Inc.). The .gree domain is different from other TLDs in that second level domain name registrations will not be open to the public. Registration will be restricted to the company, its stakeholders, and the SNS community GREE. We expect .gree to be a more powerful marketing and branding tool for the community than any other TLD before. Registrants of .gree domain names will be among the first to benefit from the value of a TLD that represents the community and the brand. Also, all information sent or published from .gree will be “officially” information from the community or the company, and that means it is dependable. Because .gree directly expresses the name of the community, it is easy to remember and associate with community activities and services. The company hopes that the .gree character string will be easy to understand, easy to remember and that people recognize it as trustworthy.

Service Levels
In terms of service levels, the company aims to operate the .gree TLD in a secure and stable manner, adopting industry best practices where applicable.
The registry’s operational goals are to have DNS load dispersion that is resistant to DDoS attacks, an 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 registry will also implement proven security measures at every level of the .gree business and technical operation to provide maximum protection of the SNS community GREE, and .gree stakeholders. This includes stringent security policies and procedures, as well as comprehensive abuse handling mechanisms to mitigate security threats to the TLD.

Reputation
Aims for the reputation of .gree are
1. for .gree to become well recognized as GREE’s official TLD, and
2. for the .gree name space to become one which Internet users can access with confidence.

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

GREE, Inc. believes that company⁄brand name TLDs such as .gree will promote competition, differentiation, and innovation for domain name registrants, Internet users, and business.

.gree is a new type of TLD in that the top-level string, not the second level, represents the community name. It has several important elements of a good Internet address: it is direct, simple, easy-to-understand, and memorable. As well as community protection, the company believes these same elements will have a strong marketing and branding impact that will also contribute to community growth and development.

The existence of this kind of differentiated TLD will encourage domain name registrants to consider the top-level as well as the second level when choosing an appropriate identity on the Internet. Also, registries and registrars will be encouraged to differentiate in terms of services, operations, systems, pricing, support, etc., promoting positive competition, differentiation, and innovation.

In addition, .gree is different from existing TLDs because it will be only available to limited registrants. With restrictive rules and comprehensive abuse handling processes, the company expects minimal abusive domain name registrations in the .gree name space. This means that information provided via .gree will be reliable and Internet users will be able to enjoy the name space with confidence. .gree will deliver unprecedented trust to Internet users, which the company believes will spur further positive competition and innovation in the industry.

Going forward, in order to encourage growth and development of the community through .gree, registrations will be accepted from community members working together with the company. This type of registration will be called a “Community member participant” registration. Please refer to Question 18 (a) iv for details. The company expects to see dynamic innovation in the community not only from the operational side but also through the cooperation of approximately 190 million members.

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

In terms of user experience, .gree aims to provide a name space recognized by community members and Internet users in general as one that:
1. provides access to GREE related information safely and effectively,
2. facilitates discovery of new things about GREE, and
3. is meaningful and trustworthy.

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

In order to achieve the goals stated above, the plans for .gree domain name registration policies are as follows. All .gree 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 being placed on lock, hold or similar status.

1. Registration Eligibility
The company considers the primary objective of .gree to be protecting the GREE community and maintaining a trusted reputation. We believe that allowing registrations on the basis of membership in the community alone would not benefit the community and would open the TLD to increased risk of abusive use. Further, an important feature of the GREE community is anonymity. Permitting individual members to register domain names poses the difficulty of striking an appropriate balance between member anonymity and Whois publishing responsibility. However, future growth and development of the community depends on the participation and cooperation of members. Therefore the company will adopt the following registration policy to allow for community members to register domain names, in addition to the operators of the community.

Domain Name Registration Categories
Domain name registration will be divided into the following two types.
A. GREE SNS community operator registration
B. GREE SNS community member participant registration
It is anticipated that allowing registrations in Category A (operational side of the community) as well as Category B (community members) will contribute to development and vitalization of the community.

A. GREE SNS Community Operator Registration
Domain names registered in this category must be registered solely by an entity that contributes to operation of the community. A community operator must be one of the following.
- GREE, Inc.
- Companies listed in the annual securities report of GREE, Inc.
- Contributors to the operation of GREE

Important Note: No individual-basis registrations will be allowed. In other words, the board members, employees, and contract staff of the companies listed above are not permitted to be registrants of .gree domain names.

B. GREE SNS Community Member Participant Registration
Domain names registered in this category must be registered by a community operator in conjunction with a community member. Community members who wish to register a domain name under this category will be required to undergo evaluation. The evaluation will seek to determine whether the applied for domain name would benefit the community. For evaluation purposes, applicants must submit a proposal to GREE, Inc. addressing at minimum the following four points.

- The domain name being applied for
- Purpose of applied for domain name registration
- Specific intended content restriction and use of the applied for domain name
- Reason the applied for domain name registration would benefit the community

Community members whose evaluations are successful will operate the applied for domain in partnership with the company and in accordance with the submitted proposal.

Domain names registered under .gree as GREE SNS Community Member Participant registrations are intended to benefit the community as a whole, not individual community members. For this reason, the registrant shall be GREE, Inc. and all other associated information on Whois shall be the company or an outsourcing partner appointed by the company.

2. Verification of Registration Eligibility
Registration and management of .gree domain names will be via the .gree dedicated account provided by a .gree accredited registrar. Access to .gree dedicated accounts will be limited to the registrants and their authorized administrative contacts, subject to verification of registration eligibility. The verification will be conducted by the registry, and organizations that wish to apply for a .gree dedicated account will be required to provide proof of registration eligibility to the registry via a .gree accredited registrar. All .gree domain name registration phases are subject to the verification. Proposed valid forms of documentary proof include, but are not limited to,
* company seal (registered or unregistered)
* signature of management staff

The registry will conduct verification on a per-registrant basis only. Once verified, a registrant or its authorized administrative contact will have access to the .gree dedicated account, through which it may apply for multiple .gree domain names without further verification, under the condition that the registrant and administrative contact information of an applied-for domain name are identical to the ones the registry has verified. If there are any material changes to the verified information, the registrant or administrative contact must notify the registry of the change.

3. Restrictions on Domain Name Strings
In order to achieve the objectives described above, the company will limit registration to domain names associated with the company, its stakeholders and the community (eg. Service or event names).

4. Whois Accuracy
The registry believes that it is important to keep and publish correct Whois data; registrants will be required to provide and maintain accurate, complete and current Whois data. In addition, no Whois protection service of any kind will be allowed.

5. Content Restrictions
Website content under .gree domain names shall be exclusively related to the company, stakeholders and community. All content must uphold the trust and security of the community.

6. Registration Policy Compliance Dispute Resolution Policy
The registry will also develop a Registration Policy Compliance Dispute Resolution Policy so as to allow third parties to file complaints against purported violations of the policies. Complaints may be filed on at least the following bases:
- eligibility
- name selection
- content and use

Complaints may be filed to the registry directly, will be handled by the registry or a registry-appointed company.

After receiving a complaint, the registry or the appointed company will investigate claim. If the claim is valid, and depending on the nature of the violation, the complaint will be resolved by one or more of the actions from the following non-exhaustive list:
- working with the registrant to remedy the situation
- referral of the matter to the abuse point of contact
- suspending, deleting or locking the domain name in question

7. 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; and
- Posting information that is offensive to public order or morals.

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.

In addition, the registry intends to set up an abuse support window (abuse report form and abuse support window) for .gree operating 24 hours a day, 365 days a year to be able to provide prompt responses to abuse activities.

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


8. Uniform Rapid Suspension (URS) System
The Registry is committed to adopting and abiding by the URS System for trademark owners who seek a rapid system to take down domain names which infringe on their rights.

9. Uniform Domain Name Dispute Resolution Policy (UDRP)
UDRP is applicable to all .gree domain name registrations.

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.

.gree will comply with the applicable laws of Japan, as well as applicable ICANN consensus policies. As part of its responsibility as the registry operator of the .gree TLD, the registry 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 .gree registration policies only allow registrations by companies and not individuals. As such, the registry will publish on Whois all information required by ICANN as it regards all required information as public. The registry believes that it is important to maintain Whois data accuracy, and no Whois protection service of any kind will be allowed.

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

.gree is intended exclusively for the GREE community, company and its stakeholders. Therefore, the company will direct its outreach and communications efforts towards raising awareness of the .gree identity among Internet users. The company will also consider calling for GREE SNS community member participation registrations via the community and its corporate web site to encourage further development of the community. In addition, by consolidating GREE community related domain names under the .gree umbrella, GREE, Inc. hopes to gain mindshare of the .gree TLD among users, thereby contributing to the projected benefits stated above.

18(c). Describe operating rules to eliminate or minimize social costs or financial resource costs, various types of consumer vulnerabilities.

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 all registration phases will be resolved on a first-come-first-served basis.

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

.gree will not be available to the general public, so the registry is not planning to offer cost benefits for registrants. The registry promises equal treatment for all .gree registrars.

iii. Note that the Registry Agreement requires that registrars be offered the option to obtain initial domain name registrations for periods of one to ten years at the discretion of the registrar, but no greater than ten years. Additionally, the Registry Agreement requires advance written notice of price increases. Do you intend to make contractual commitments to registrants regarding the magnitude of price escalation? If so, please describe your plans.

The registration period for .gree domain names is as follows:

General Registration
* Minimum of 1 year and maximum of 10 years (but no greater than 10 years)

All Phases other than General Registration Phase
* Minimum of 2 years and maximum of 10 years (but no greater than 10 years)

The registry will provide an advance written notice of price increases as required by the Registry Agreement. The registry is not intending to make contractual commitments to registrants regarding the magnitude of price escalation.

Community-based Designation


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

Yes

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

Community Name
GREE

Community Structure, Establishment and Recognition among Internet Users
The GREE community is well known as a community of GREE SNS users. Founder and operator GREE, Inc. was established in December 2004 when the community began to thrive.

Founding and Operating Entity
GREE, Inc, a company incorporated under the laws of Japan

Community Membership Structure
GREE community membership is free. Members are required to meet the following conditions:
-Agree to the Terms of Use required to receive services
-Provide certain personal information including a valid email address
-Possess a mobile device
In principle, anyone who meets the above criteria is eligible to become a member. However, the following measures aim to prevent abusive use and other issues.
-Verification of email address associated with mobile device (Verification email sent to address associated with userʹs mobile device.)
-Notification of usage etiquette and prohibited behavior
-Expulsion of users who violate community rules
GREE members have access to an extensive line up of free and paid premium services.

Community Size (Membership and Location) and Potential
Current Membership
Membership in the GREE community has grown steadily since the service was launched. In March 2007 the community had 1 million members. By April 2009 membership had grown 10-fold to exceed 10 million in approximately 2 years. After OpenFeint joined the GREE group, in December 2011 total membership reached 189.2 million. As the same time, market value of GREE, Inc.was over JPY600 billion (USD7,730 million).

Going forward the company expects continued growth.

This data shows growth in GREE Group membership between April and December 2011
(180% growth in 9 months)
Apr-11	105,000,000
May-11	113,000,000
Jun-11	123,000,000
Jul-11	134,000,000
Aug-11	145,000,000
Sep-11	155,000,000
Oct-11	162,000,000
Nov-11	174,000,000
Dec-11	189,200,000
Please see the diagram http:⁄⁄gmoregistry.co⁄gree⁄user.pdf

As seen above, membership growth is strong. Between April and December of 2011 membership approximately doubled to 189.2 million. Given the current growth trend we are confident the community will continue to expand. 

Global Expansion
In January 2011 GREE International, Inc. was established marking the beginning of a concerted effort to expand the community beyond Japan. The company has actively expanded the community through acquisitions and partnerships as outlined below.

-Acquisition of OpenFeint
In terms of both user base and game content, OpenFeint is one of the largest gaming networks in North America. The OpenFeint brand, user base, social platform and social media have been integrated with GREE in Japan to form GREE Platform. The integrated content platform is targeted to global markets.

-Business partnership with China’s leading Internet services provider, Tencent
Tencent operates the largest online community in China with 650 million users. Standardizing specifications of our respective platforms, GREE and Tencent launched Tencent Wireless Open Platform for Community on August 5, 2011.

-Partnership with online payment provider PayPal
As of December 14, 2011, smartphone users in Japan can use PayPal on the GREE platform. The company also plans to introduce PayPal to GREE platform in the US and other countries. PayPal is an easy and secure payment method introduced to diversify payment options and enhance ease of use.

-Investment in Korean game developer, Mobicle
GREE has partnered with Mobicle to develop social games for smartphones, leveraging Mobicleʹs technology and expertise in real-time simultaneous connections and 3D. 
 
The company is developing its global presence and already has offices in the US, China, Korea, Singapore and England. We continue to actively pursue global growth with plans to open subsidiaries in Holland, Brazil and Germany. 
Please refer to the following URL: http:⁄⁄www.gree.co.jp⁄en⁄corporate⁄globalnetwork⁄

Service Development
The community began as a basic desktop social networking service. In 2006 a mobile version of GREE was launched together with free games and content, and in 2010 smartphone versions (iPhone and Android) followed. Today GREE is a widely recognized and used social gaming platform incorporating SNS functionality and community. The mobile version of GREE provides a large selection of free games and content, significantly contributing to the community’s ability to acquire new members. The company expects its attractive service offerings to continue boosting membership. Please visit the following webpage for an overview of company history: http:⁄⁄www.gree.co.jp⁄en⁄corporate⁄history⁄


Community Engagement
The following graphs illustrate overall usage and usage per member.

(1) Overall level of community activity
This data shows total monthly page views between Sep 2007 and Jun 2010
Users(1,824% growth)	⁄	Page views(840% growth)
Sep-07	1,960,000,000	⁄	2,450,000
Dec-07	2,800,000,000	⁄	3,280,000
Mar-08	4,470,000,000	⁄	4,290,000
Jun-08	5,840,000,000	⁄	5,540,000
Sep-08	7,630,000,000	⁄	6,700,000
Dec-08	9,160,000,000	⁄	8,020,000
Mar-09	12,180,000,000	⁄	9,860,000
Jun-09	17,420,000,000	⁄	12,600,000
Sep-09	23,680,000,000	⁄	15,120,000
Dec-09	24,970,000,000	⁄	16,730,000
Mar-10	25,950,000,000	⁄	18,430,000
Jun-10	35,760,000,000	⁄	20,590,000
Please see the diagram http:⁄⁄gmoregistry.co⁄gree⁄pv1.pdf

The rise in page views is the result of aggressive promotions that produce steady membership growth, and the introduction of new social games that boost member activity.

(2) Activity per member
This data shows the average number of page views per user
(217% growth)
Sep-07	800
Dec-07	854
Mar-08	1,042
Jun-08	1,054
Sep-08	1,139
Dec-08	1,142
Mar-09	1,235
Jun-09	1,383
Sep-09	1,566
Dec-09	1,493
Mar-10	1,408
Jun-10	1,737
Please see the diagram http:⁄⁄gmoregistry.co⁄gree⁄pv2.pdf

As is evident here, there is also an upward trend in average page views per user each month. Growth in this metric is an indication not only of increased membership but also of increased engagement on a per member basis. The above data clearly illustrates level of activity in the community overall and by individual members. 

Major Features of the Community

-Community
Members share interests and discuss topics with other members.
Any participating member can leave comments in themed community forums.
Any member can create a new thread and become administrator.
The administrator is responsible for thread management, and must promptly issue warnings or remove posts when Terms of Use violations are found. Administrators are held responsible for overlooked violations.

-Profile
Members publish profiles including photos and bios.

-Friend Links
Members search for friends and send friend requests.
“Friends” can view friend-only content including diaries and photos.

-Comment
Members can leave comments while viewing profiles.

-Diary
This feature is similar to a blog. Blog entries posted on other sites can also be published.

-Real time comment feed
Simple tool for posting opinions, ideas and feelings
Posts displayed in real time on friends’ home pages

-Photo, Video Album: Images⁄videos can be posted and viewed by other members.
Includes comment function
Images⁄videos can be password-restricted

-Mail
Allows members to communicate within GREE
Messages can be stored indefinitely within allocated storage limits.
Measures are in place to protect minors and avoid member conflict. Members under the 18 years can only exchange messages with users in a specific age bracket, and Messages containing inappropriate language or personal details cannot be sent.

-Games
PC and mobile games and apps (in-house and third-party developer games)
Many free games and some paid content
Virtual currency for in-game purchases and options

-User Q&A Forum
A member question & answer forum

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

Applicant’s relationship to the community
GREE, Inc, the applicant, is the company that established and operates the community. Planning and development, general operation (including web site development and management), provision of functionality and services, and member support operations are all carried out by the company.

Accountability mechanism’s of the applicant to the community
The company (applicant) uses the following mechanisms to ensure it remains accountable to both members and society in general.  

- Publicity aimed at General Public via Mass Media 
(1)Community Publicity
(1-1) GREE community marketing and publicity 
All GREE television commercials open and close with the same two images
opening image: http:⁄⁄gmoregistry.co⁄gree⁄cm1.png
closing image: http:⁄⁄gmoregistry.co⁄gree⁄cm2.png
This generates and reinforces recognition of the GREE community brand among the general public. 
(1-2) Television Commercials Introducing SNS Features
The company also runs commercials that aim to educate viewers on SNS functionality. These commercials contribute to general understanding of GREE, promote its existence and encourage participation not only among existing members but also to the public in general. 
(Between October 7-13, 2011 30-40 commercials a day were broadcast throughout Japan.) 


(2) User Education on Mobile Device and Internet Usage
The company has also created educational television commercials on safe and secure Internet usage aimed at minors who use the Internet or mobile devices and their guardians.  
(Between July 22 and August 31, 1-3 commercials a day were broadcast throughout Japan, and 4-10 commercials a day were broadcast in the Kanto region.) 

- Website Announcements and Notices to the Community and General Public 
The company strives to educate and inform members through its website. Help Pages provide explanation of service features and our website also features the educational page, “GREE’s 6 Promises to All”. 

- Email Communication with Members
(1) After a given period of time, new users receive information and game tutorials by email. 
(2) When a message is deleted due to a violation of Terms of Use, the sender receives a warning by email and the intended recipient is a notified that a message from the sender has been deleted. 
Through the appropriate use of email as outlined above, the company strives to educate users on service features and safe Internet usage. 

- Site Operation System
(1) 24-hour-a-day, 365-day-a-year patrol system 
GREE has established patrol centers in Tokyo, Hokkaido, and Okinawa, with a total of approximately 450 patrol staff. The patrol system was launched in November 2006. 
The patrol centers conduct surveillance using a combination of automated systems, visual checks, and user reporting. In the event that inappropriate content is discovered, action is taken including content removal, issuing a warning, and account suspension. 
(2) Age Restrictions  
- Users under 18 are excluded from the search results of users over 18,
- Users over 18 cannot message users under 18, and 
- Users who wish to send friend requests to users under 18 are limited to standard wording. 
(3) User Authentication
The company verifies the mobile devices of new users at the time of registration. This prevents users who have previously been banned from re-registering. Usage of mobile filtering services can also be detected to verify members’ ages. The company also has access to information collected by major Japanese mobile carriers KDDI Corporation and Softbank Mobile for even more reliable age verification, and will continue forging partnerships with other carriers.
(4) Security and Safety Improvement Committee lead by CEO
Under the leadership of the CEO, the Security and Safety Improvement Committee comprising the Director responsible for patrol centers, a member of the Board of Auditors, and representatives from the legal and public relations department was established to oversee the protection and education of minors on the website. 
(5)Independent Certification
Our website was the first to be certified by EMA (Content Evaluation and Monitoring Association : http:⁄⁄www.ema.or.jp⁄en⁄index.html ) in August 2008. 

- Educational Initiatives on our Website 
(1) GREE has been a member of Motto-goodnet (Better Internet Environment), an organization that promotes Internet safety, since February 2009 and provides official Motto-goodnet accounts on its website.
(2)In July 20011, GREE overhauled its educational content adding new links to educational information and modifying content to make it easier to understand. 
(3) In August 2011 we launched the educational app, “Six Promises between GREE and Everyone” and in December of the same year the service was diversified to cater to different age groups.

- Educational Initiatives beyond our Website
(1) The company is continuously promoting its patrol center and other educational initiatives to local governments and educational institutions. 
(2) The company has partnerships with organizations that promote Internet safety, non-government groups, and public agencies, and actively participates in educational events. For example, in 2011 the company presented a lecture at Tokyo Seitoku University Fukaya Senior High School (December 16), and gave a presentation at the Conference of Lifestyle Counselors in Osaka (December 18).

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

Purpose of .gree
The purpose of the .gree TLD is to create a safe and secure name space that will protect the GREE community. The company has registered many domain names under various gTLDs and ccTLDs to protect community members from harmful websites. Despite these efforts, there are still many domain name registrations and websites that attempt to impersonate the community. A single TLD is necessary to ensure users can clearly identify community websites, as well as differentiate community domain names from phishing and other fraudulent websites - we believe this is where the greatest benefit to Internet users lies. 

Further, member participation and cooperation is essential for growth and development of the community. For this reason, domain registrations will be available not only to the operational side of the community but also to the community members that play a crucial role in the development of the community.  

Intended Registrants in .gree
The following two types of domain name registration will be available.

A. GREE SNS Community Operator Registration
Domain names registered in this category must be registered solely by an entity that contributes to operation of the community. A community operator must be one of the following.
-	GREE, Inc. 
-	Companies listed in the annual securities report of GREE, Inc.
-	Contributors to the operation of GREE

* Important note: No individual-basis registrations will be allowed. In other words, the board members, employees, and contract staff of the companies listed above are not permitted to be registrants of .gree domain names.

B. GREE SNS Community Member Participant Registration
Domain names registered in this category must be registered by a community operator in conjunction with a community member. Community members who wish to register a domain name under this category will be required to undergo evaluation. 

Please refer to Question 18(b)iv for details. 

Intended End Users of .gree
End users of domain names registered in the .gree TLD are expected to be: 
- General Internet users visiting GREE websites
- GREE community members
- GREE Inc. the company and its stakeholders

Related Activities the Applicant has carried out or Intends to carry out in Service of this Purpose
Currently, the community uses TLDs including gree.co.jp and gree.jp for activities including usage of the various services previously described, and communication between users. In the future, all of these activities would be consolidated under .gree, establishing a safer and more secure community space. As outlined in Question 20b, the company already promotes community safety and security through educational campaigns and a high-security operational structure. Through a safer, more secure community platform the company aims to grow the community, bring people together, and make people happy

Explanation of how the Purpose is of a Lasting Nature
The community connects facilitates building long term relationships between users. As explained in Question 20(a) (Community Features), GREE is host to data users consider important including diaries, photos, video and messages. Maintaining this information securely over the long term is critical to GREE’s mission. Therefore in the long term, the company expects to continue operating the community safely and securely. 

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

Relationship to the Established Name of the Community
The applied for gTLD string, .gree is identical to the alphabet rendering of the community name. GREE is continuously promoting the community name through television, print, billboard, and online advertising, in FY2010 the company spent over JPY 7 billion (USD90 million) on advertising and promotion. As a result, by the end of December 2011, membership had reached 189.2 million members and the community had become widely recognized in Japan.  

Relationship to the Identification of Community Members
GREE community members have all agreed to the Terms of use in order to join, and members are always identified as GREE members. The applied for gTLD, .gree is identical to the name by which the community is identified. 

Connotations the String has beyond the Community
The applied for string, .gree is similar to the word “free” in the Welsh language, however Gree has no meaning in any of the six official languages of the United Nations. 
Also, Chinese company, Zhu Hai Gree Corporation uses the name GREE domestically in China for electronics and peripherals brand which primarily manufactures and sells air conditioners. 

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

The plans for .gree domain name registration policies are as follows.

1. Registration Eligibility
As stated in Question 20(c), registrations in the .gree TLD will be divided into two categories.

A. GREE SNS Community Operator Registration
Domain names registered in this category must be registered solely by an entity that contributes to operation of the community. A community operator must be one of the following.
-	GREE, Inc. 
-	Companies listed in the annual securities report of GREE, Inc.
-	Contributors to the operation of GREE

* Important note: No individual-basis registrations will be allowed. In other words, the board members, employees, and contract staff of the companies listed above are not permitted to be registrants of .gree domain names.

B. GREE SNS Community Member Participant Registration
Domain names registered in this category must be registered by a community operator in conjunction with a community member. Community members who wish to register a domain name under this category will be required to undergo evaluation. 

Please refer to Question 18(b)iv for details. 

2. Verification of Registration Eligibility
Registration and management of .gree domain names will be via the .gree dedicated account provided by a .gree accredited registrar. Access to .gree dedicated accounts will be limited to the registrants and their authorized administrative contacts, subject to verification of registration eligibility. The verification will be conducted by the registry, and organizations that wish to apply for a .gree dedicated account will be required to provide proof of registration eligibility to the registry via a .gree accredited registrar. All .gree domain name registration phases are subject to the verification. Proposed valid forms of documentary proof include, but are not limited to, 
* company seal (registered or unregistered)
* signature of management staff

The registry will conduct verification on a per-registrant basis only. Once verified, a registrant or its authorized administrative contact will have access to the .gree dedicated account, through which it may apply for multiple .gree domain names without further verification, under the condition that the registrant and administrative contact information of an applied-for domain name are identical to the ones the registry has verified. If there are any material changes to the verified information, the registrant or administrative contact must notify the registry of the change.

3. Restrictions on Domain Name Strings
In order to achieve the objectives described above, the company will limit registration to domain names associated with the company, its stakeholders and the community (eg. Service or event names).

4. Whois Accuracy
The registry believes that it is important to keep and publish correct Whois data; registrants will be required to provide and maintain accurate, complete and current Whois data. In addition, no Whois protection service of any kind will be allowed.

5. Content Restrictions
Website content under .gree domain names shall be exclusively related to the company, stakeholders and community. All content must uphold the trust and security of the community. 

6. 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; and
-	Posting information that is offensive to public order or morals.

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.

In addition, the registry intends to set up an abuse support window (abuse report form and abuse support window) for .gree operating 24 hours a day, 365 days a year to be able to provide prompt responses to abuse activities.

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

7. Uniform Rapid Suspension (URS) System
The Registry is committed to adopting and abiding by the URS System for trademark owners who seek a rapid system to take down domain names which infringe on their rights.  

8. Uniform Domain Name Dispute Resolution Policy (UDRP)
UDRP is applicable to all .gree domain name registrations.

Enforcement Mechanism
The .gree registration policies are designed specifically to encourage continuous compliance with the eligibility, name selection, as well as content and use policies. 

The .gree registration policies necessitate manual review and evaluation by GREE for any and all domain name registration requests that do not originate from the registry, i.e. GREE SNS Community Member Participant Registration. This stringent process ensures that all registrations are compliant with the community policies at the time the domain is registered.

After a domain name is registered, the registry plays a central role in the operation of the website, and will ensure that the site is operated in a manner that is consistent with the eligibility, name selection, and content and use policies.

The registry will also develop a Registration Policy Compliance Dispute Resolution Policy so as to allow third parties to file complaints against purported violations of the policies. Complaints may be filed on at least the following bases:
-	eligibility
-	name selection
-	content and use

Complaints may be filed to the registry directly, and will be handled by the registry or a registry-appointed company.

After receiving a complaint, the registry or the appointed company will investigate claim. If the claim is valid, and depending on the nature of the violation, the complaint will be resolved by one or more of the actions from the following non-exhaustive list.:
-		working with the registrant to remedy the situation
-		referral of the matter to the abuse point of contact
-		suspending, deleting or locking the domain name in question

The responsibility for handling complaints rests on the registry customer support representatives, who may escalate to the registry management depending on the nature of the complaint.

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

Not Available

Geographic Names


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

No

Protection of Geographic Names


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

GREE, Inc. (the registry) 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 registry may propose to ICANN to 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 registry.

The registry 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 GREE, Inc., its stakeholders, and the SNS community GREE members to register, the registry 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 to release; and
B. Purpose of registration and rules for administrating 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 registry; 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 registry.
4. If a reply is not received by the due date agreed upon by ICANN, the GAC and the registry, 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 registry may enter negotiation to attempt to reach agreement, and only upon reaching agreement shall the names be released.
6. Potential applicants of the names shall send registration requests to the registry. The request must include the following information:
A. Domain name(s) the applicant wishes to register;
B. The pledge the applicant understands the purpose and rules of the domain name registration and use included in the proposal letter described 1.A. above; and
C. The pledge the applicant abides by the purpose and rules of the domain name registration and use included in the proposal letter described 1.A. above;
7. The registry reviews the request and checks availability of the requested name. In case the registry approves the request, it issues a “code.”
Note: The availability check takes place to see whether the requested domain name has been already requested and registered by another applicant.
8. Using the “code,” the applicant requests the domain name registration through a .gree accredited registrar.

Registry Services


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

1. Overview

The registry operator plays a central role in a TLD’s ecosystem. As such, it is imperative that the registry operator provides a secure and robust set of services that serves the best interests of the community.

The following sections describe the complete set of registry services that shall be provided in the context of .gree. GMO Registry (backend registry) expects that the registry services will pose no security or stability concern.


2. Provisioning and Management of Domain Names and Associated Objects (SRS)

GMO Registry provides two interfaces to registrars for registering and managing domain names, contacts and name servers in the SRS.


2.1 EPP Service

The Extensible Provisioning Protocol (EPP) interface is the industry standard communication protocol between registrar systems and the registry SRS. It allows registrars to integrate and automate domain provisioning operations into their online store front and internal systems.

GMO Registry provides a standards-compliant EPP service. In the interests of interoperability, it reuses as much as possible existing published extensions to achieve functionalities not specified in the core EPP standards. It is fully compliant with the following RFCs:

* RFC 5730: EPP Core Framework
* RFC 5731: EPP Domain Name Mapping
* RFC 5732: EPP Host Mapping
* RFC 5733: EPP Contact Mapping
* EPP 5734: EPP Transport over TCP⁄TLS
* RFC 5910: DNSSEC Mapping for EPP
* RFC 3915: Grace Period Mapping for EPP

In addition, GMO Registry adopts a modern EPP extension developed by Cloud Registry for dealing with launch processes typically seen in modern gTLD start up. The extension, named “EPP Launch Phase Mapping”〈http:⁄⁄tools.ietf.org⁄html⁄draft-tan-epp-launchphase-00〉, was developed in accordance with RFC 3735 (Guidelines for Extending EPP) and contributed to the IETF for community discussions with a view towards publication as an RFC.


2.2 Web Management Interface

While EPP covers the use cases involving computer-to-computer interactions, it is more convenient for human operators at a registrar to use a web-based application for ad hoc support and processes.

As such, GMO Registry provides a web-based management interface for registrars. It contains a subset of functionalities offered in EPP along with convenience features that facilitate human interaction.

2.2.1 Functions

● Domain management
○ EPP commands: check, info, create, update, renew, restore, transfer, delete
○ Whois query - integrated screen for convenience
○ DNS query - integrated screen for convenience
● Contact management
○ EPP commands: check, info, create, update, transfer, delete
○ Whois query - integrated screen for convenience
● Host management
○ EPP commands: check, info, create, update, delete
○ Whois query - integrated screen for convenience
○ DNS query - integrated screen for convenience
● Registrar account self-service management
○ view and update registrar contact information
○ password change


3. Dissemination of TLD Zone Files

3.1 DNS

DNS is a primary function of the registry operator, and is a public-facing service with a high risk profile due to abusive behaviors such as DDoS attacks, yet demands a rigorous SLA. As such, GMO Registry is committed to providing a secure, efficient and highly efficient DNS service to serve the Internet community.

GMO Registry publishes updates to the master unsigned DNS zone file asynchronously using TSIG (Transaction SIGnature, as defined by RFC 2845) based dynamic update (RFC 2136). DNSSEC signing of the zone file is done using a bump-in-the-wire methodology - i.e. a decoupled DNSSEC signing subsystem is responsible for turning the unsigned zone file into a signed one, managing keys and signatures. A FIPS 140-2 Level 3 validated hardware security module (HSM) will be used for safekeeping of keys. The GMO Registry DNSSEC solution shall be operated in accordance with best practices published in draft-ietf-dnsop-rfc4641bis and elsewhere.

GMO Registry shall provide a geographically diverse network of authoritative name servers for resolution of the TLD zone contents. GMO Registry engages the Internet Systems Consortium (ISC) for the use of their proven and already-deployed [email protected] service to provide a high performance, resilient and standards compliant worldwide IPv4+IPv6-anycast DNS resolution network.

The .gree zone will contain only contents as specified in Section 2.2.3.3 of the applicant guidebook, namely:
● Apex SOA record
● Apex NS records
● In-bailiwick A and AAAA glue records for DNS servers of the TLD itself, as well as those of registered domains
● DS records for registered names
● DNSSEC-related records such as DNSKEY, RRSIG, NSEC3 and NSECPARAM

At least two of the .gree name server records registered at the root are dual-stacked, offering IPv6 anycast access globally.


4. Registration Data Publication Services

GMO Registry shall provide all registration data publication services in compliance with Specification 4 of the gTLD Agreement.

4.1 Registration Data Directory Services (Whois)

GMO Registry shall provide an RFC 3912-compliant Whois service on TCP port 43, served over IPv4 and IPv6. It supports domain, contact, host and registrar lookups.

A thin web-based front-end will also be provided over IPv4 and IPv6.

In order to curb abuse, both the port 43 and web-based channels will be rate-limited by IP address. In addition, the web-based channels will also require the use of visual and audio captcha.

A white-list of clients is maintained by the registry to provide a mean for bypassing the above protection mechanisms. Entities with legitimate reasons to access the Whois service in an unrestricted manner may request for inclusion in the white-list. In general, law enforcement agencies, security researchers and internal registry staff or systems are the categories of entities that are eligible to be white-listed.

4.2 Zone File Access

GMO Registry will provide access to zone files adhering to the format specified in Section 2.1.4, Specification 4 of the gTLD Agreement. Provisioning of account credentials used for accessing the zone files will be done in cooperation with the Centralized Zone Data Access Provider (“CDZA Provider”). Bulk access to the zone files will also be provided to ICANN and its designee including emergency operators designated by ICANN, on a continuous basis.

The Zone File Access service will be provided through a secure HTTPS (HTTP over SSL⁄TLS) interface. Access control is enforced by the use of IP-based access control list and HTTP Basic Authentication (RFC 2617). All access attempts are logged along the client source IP address and requested resources. All failure attempts are alerted. Failure attempts that correspond to an existing account will be recorded, and will result in an automatic account lock-out if the number of failure attempts exceed a configurable threshold. Locked accounts must be manually reset by registry staff upon verified out-of-band request by the account holder.

4.3 Bulk Registration Data Access by ICANN

GMO Registry will provide ICANN periodic access to thin registration data, and exceptional access to thick registration data, as specified in Section 3, Specification 4 of the gTLD Agreement. The registration data files are available for download by ICANN using the SFTP protocol using public key authentication, or any other protocols as required by ICANN. The service will be firewalled to only allow ICANN-nominated IP addresses.


5. Registry Data Escrow

Whilst not a service offered to the general public, GMO Registry recognizes that registry data escrow is a mandatory registry data publication function that must be implemented by all gTLD registries. GMO Registry shall comply with all requirements set forth in Specification 2 of the gTLD Agreement. Details on GMO Registry’s implementation of data escrow are supplied in the answers to Question 38.


6. DNSSEC
The .gree zone will be signed and fully validatable and operational at the time of launch. In particular, GMO Registry will arrange to have the DS records corresponding to the zone KSK published at the root beforehand, and all procedures in place for the ongoing operations of the signed zone thereafter.

DNSSEC will be fully supported in the provisioning interfaces (EPP and Web Management Interface) allowing registrars to manage DS records. Provisioning of DNSSEC-related data over EPP is fully compliant with RFC 5910.


7. Internationalized Domain Name (IDN)

GMO Registry plans to offer registration of second level IDN labels at launch, making the following language(s) available:

- Japanese (tag: ja)

The GMO Registry IDN implementation is fully compliant with the IDNA 2008 suite of standards (RFC 5890, 5891, 5892 and 5893) as well as the ICANN Guidelines for the Implementation of IDN Version 3.0 〈http:⁄⁄www.icann.org⁄en⁄resources⁄idn⁄implementation-guidelines〉. To ensure stability and security, GMO Registry has adopted a conservative approach in its IDN registration policies as well as technical implementation.

All IDN registrations must be requested using the A-label form, and accompanied by an RFC 5646 language tag identifying the corresponding language table published by the registry. The candidate A-label is processed according to the registration protocol as specified in Section 4 of RFC 5891, with full U-label validation. Specifically, the “Registry Restrictions” steps specified in Section 4.3 of RFC 5891 are implemented by validating the U-label against the identified language table to ensure that the set of characters in the U-label is a proper subset of the character repertoire listed in the language table.


8. Policies

8.1 Grace periods

GMO Registry implements the following customary grace periods and associated policies commonly provided in gTLDs:

● Add Grace Period (AGP)
● Renew⁄Extend Grace Period (REGP)
● Auto-Renew Grace Period (ARGP)
● Transfer Grace Period (TGP)
● Redemption Grace Period (RGP)

Details are described in Question 27 “Registration Lifecycle”.

8.2 Consensus Policies
GMO Registry recognizes that an ICANN accredited registry operator must comply with all of the consensus policies listed at 〈http:⁄⁄www.icann.org⁄en⁄general⁄consensus-policies.htm〉 and any temporary policies that may be ratified by the community from time to time.

GMO Registry will fully support the following consensus policies that relate to ongoing registry operations:
● Inter Registrar Transfer Policy
● AGP Limits
● Registry Services Evaluation Policy

GMO Registry supports the name registration policies that are principal responsibilities of ICANN accredited registrars. These include:
● Uniform Domain Name Dispute Resolution Policy
● Whois Marketing Restriction Policy
● Restored Names Accuracy Policy
● Expired Domain Deletion Policy
● Whois Data Reminder Policy


9. Rights Protection Services

GMO Registry will support all mandatory rights protection mechanisms required by Article 2, Section 2.8 of the ICANN New gTLD Agreement and implement policies and process for initial and ongoing protection of the legal rights of third parties. The registry will employ the services of the ICANN-appointed Trademark Clearinghouse to support its rights protection mechanisms (RPMs). The registry will offer a sunrise service during pre-launch, as well as Trademark Claims service in conjunction with the general availability phase. In addition, the registry will fully support the Uniform Suspension System (URS), including the implementation of determinations issued by URS examiners.

Demonstration of Technical & Operational Capability


24. Shared Registration System (SRS) Performance

1. Overview
The Shared Registration System (SRS) is a critical function of a TLD that enables multiple registrars to provision and manage registry objects such as domains, name servers and contacts. The availability and performance of the SRS has an acute impact on registrar business operations, registrants and Internet users, and therefore has a direct effect on the security and stability of the Internet as well as consumer confidence in the DNS. In recognition of that, GMO Registry has deployed a secure, robust and scalable SRS infrastructure to meet the anticipated demands of the .gree gTLD, with ample head room to account for surges and the capability to scale up easily.


2. Architecture

GMO Registry uses the Cloud Registry Management Platform (CRMP) for its SRS implementation. CRMP is a modern implementation of SRS and supporting services for TLD registries. At a high level, the CRMP SRS consists of the following components, which together make up a system that is fully compliant with the gTLD Agreement requirements. Specifically, it conforms to, and is fully interoperable with, the standards in Specification 6. Additionally, the platform is designed to be efficient and horizontally scalable, and when appropriately resourced and operated (see infrastructure and resources) fully capable of exceeding the Service Level Requirement (SLR) stipulated in Specification 10.



![attached: SRS Software Compnent Architecture - 24_1.png](⁄24_1.png)


2.1. Provisioning interfaces

2.1.1. EPP Interface

The EPP implementation conforms to clause 1.2 in Specification 6 of the gTLD Agreement. In particular, it is fully compliant with RFCs 5730, 5731, 5732, 5733, 5910, and 3915. The EPP service is offered as a TCP server protected by TLS (RFC 5734). In addition, all supported extensions comply with RFC 3735 (guidelines for extending EPP.)

The EPP server understands the EPP protocol, and maintains the authenticated EPP session for the lifetime of the connection. It acts as an intermediary, forwarding requests from registrars to the Application Server and relaying the responses back to the registrars. The EPP server uses standard EPP protocol communication with the registrars and an efficient remote procedure call mechanism with the Application Server.

The EPP server only accepts connections from authorized IP addresses advised by registrars.

2.1.2. Web Management Interface

The web based management interface contains a subset of functionalities offered in EPP, along with convenient features such as viewing reports and billing information. It is offered over a secure HTTP interface protected by SSL⁄TLS. It uses the same remote procedure call mechanism as the EPP interface for relaying user requests to the Application Server.

2.2. Internal components

2.2.1. Application Server

The application server implements core SRS business rules which manage the full lifecycle of various registry objects, enforces policies and mediates access to the core SRS database. As part of a fault tolerant, distributed system, it uses the Distributed Coordination Service (DCS) to synchronise access to resources. In order to enhance resiliency as well as to maintain service levels, it also uses the message queue for asynchronous processing of non-timing sensitive or potentially high latency operations.


2.2.2. SRS Database

The SRS database is a logical collection of registry objects and associated data, presented as an interface that allows clients to perform read and write operations to the collection. In concrete terms, it is a cluster of database processes that together provides a scalable, highly available, and fault-tolerant service at the core of the registry.


2.3. Interfaces to other registry systems

2.3.1 DNS Publication Subsystem

The DNS Publication Subsystem is responsible for publishing updates to the SRS database that has material effects on the DNS. These include domain name registration, deletion, updates that causes the set of delegated name servers to be changed, as well as glue record creation, update and deletion.

DNSSEC processing is also handled within the DNS Publication Subsystem, including functions such as key management and zone signing.

Changes effected in this subsystem are replicated to the public authoritative name servers using standard zone transfer mechanisms.

2.3.2. Whois Publication Subsystem

The Whois Publication Subsystem processes data destined for inclusion into the public Registration Data Directory Service, storing it in a highly optimized database for query-only workload consistent with the nature of the Whois service. The database is replicated into public Whois server points of presence over secure VPN tunnels.

2.3.3. Billing & Reporting Subsystem

The Billing and Reporting Subsystem handles transactions within the SRS and any other registry services that are deemed billable. It is responsible for billing functions including financial reconciliation, interfaces to accounting systems, invoicing and business report generation.

2.3.4. Data Export Subsystem

The Data Export Subsystem is a collection of processes that satisfy the following ICANN gTLD contractual requirements: Registry Data Escrow, Zone File Access, and Bulk Registration Data Access. It involves a set of escrow data and zone data generation processes as well as supporting services.

It also includes the ICANN Reports Generation Batch Process – a monthly batch job that collects and aggregates data, transaction logs, and metrics from various registry components and produces a set of reports according to Specification 3 of the gTLD Agreement. Generated reports are sent to ICANN via prescribed communication channel.


3. Infrastructure

3.1. Sites

In order to maintain high service levels in the face of catastrophic disasters or outages caused by equipment failure, upstream connectivity or power failure, SRS functions are delivered utilizing fault tolerant mechanisms.

SRS functions during normal operations are delivered from the primary site. In the event of an outage affecting the primary site, all services can be delivered from a geographically diverse, hot standby site.

All systems on the primary and standby backup site are deployed in a fully redundant N+1 setup and transparently withstand catastrophic failure of any single component utilizing load balancers with active health check mechanisms, clustered fault tolerant application servers and transit capacity from multiple independent upstream providers.

Both the primary and standby sites are hosted in telco-grade data centres. More details about the datacentres are specified in Question 32 “Architecture”.

All critical registry data is continuously replicated to the backup site via securely encrypted transmission channels providing a near real-time restore point objective.

![attached: 24_2.png](⁄24_2.png)


3.1.1 SRS Primary Site

More details on the infrastructure hardware are specified in the answers to Question 32 “Architecture”.

Location: Tokyo
Equipment manifest:

• 2 x Firewalls
• 2 x Switches
• 1 x Console Server
• 9 x Intel Quad Xeon-based Servers
• 3 x Intel Quad Xeon-based Database Servers
• 2 x VM Host Servers
• 1 x HSM
• 1 x Backup Server


3.1.2. SRS Hot Standby Site

Location: Sydney
Equipment manifest:

• 2 x Firewalls
• 2 x Switches
• 1 x Console Server
• 3 x Intel Xeon-based Database Servers
• 6 x VM Host Servers
• 1 x HSM
• 1 x Backup Server

3.2. Synchronisation Scheme

The primary and standby sites are connected via a secure VPN tunnel over redundant links. All synchronisation traffic is securely transmitted over the VPN tunnel. Connectivity between sites, as well as synchronisation status of various sub-system components are actively monitored.

3.2.1. SRS Database

The SRS database is held in a master database cluster in the primary site, with a slave cluster mirrored in the standby site. The clusters operate in an active-standby mode, with all data natively replicated from the master to the standby cluster in an asynchronous fashion.

3.2.2. Whois Database

The Whois master database contains a subset of data stored in the SRS database, and if required, can be readily regenerated from the SRS database. There are two instances of the Whois master database - one in the primary site (primary Whois master) and another on the standby site (standby Whois master).

Sychronisation between the primary Whois master database and the standby Whois master as well as public Whois nodes is achieved using master-slave asynchronous replication.

3.2.3. Zone Data

TLD zone data (for both clear and signed copies) is synchronised with the help of standard DNS master slave replication between the BIND instances on the primary site and mirror instances on the standby site.

3.2.4 Applications and Configurations

Software deployments and configuration changes are kept in sync on both sites at the time of deployment or change implementation. This is enforced through strict operational procedures, with monitoring in place to detect and alert any inconsistencies.

3.3 Network

Within each site, the SRS network architecture is depicted as follows:



![attached: SRS Conceptual Architecture - Provisioning - 24_3.png](⁄24_3.png)



![attached: SRS Conceptual Architecture - Publication - 24_4.png](⁄24_4.png)


4. SRS Performance

GMO Registry will comply with all SRS performance specifications set forth in Specification 10 of the gTLD Agreement.

In order to meet the availability and response time service levels defined in Specification 10, it is necessary to take into account the various components that constitute the SRS as a whole.

4.1. Availability

The necessary preconditions for maintaining availability of the SRS are as follows:
a. the EPP interface and all of the supporting components must be end-to-end operational; and
b. the round trip time of any given EPP command must not be more than 5 times higher than the corresponding SLR defined in Specification 10. While the actual requirement for EPP service availability in Specification 10 is more lenient than what is stated here, response times that exceed normal levels are almost certainly an indication of a fault or capacity issue in some underlying components that has the potential of compounding to a loss of availability. As such, instances of EPP commands that exhibit such behaviours are investigated and dealt with urgently.
In general, the following strategies are employed to safeguard the availability of the SRS:
• internal redundancy - to ensure that any single component failure in any layer of the architecture will not result in an outage
• network redundancy - multiple upstream transit providers mitigates the risk of connectivity issues
• site redundancy - with geographically distinct hot standby site helps mitigate prolonged outage of the SRS in case of catastrophic failure involving an entire data centre or geographic region
• software architecture - with clear separation of concern between decoupled components each with different load characteristics facilitates horizontal scaling to upgrade capacity of the affected components
• hardware scalability - computing resources are virtualised with headroom in the host system to allow operational flexibility to add capacity as needed
• monitoring - collects performance and system metrics and alerts abnormal resource usage levels helps to proactively detect and identify issues so that prompt corrective actions can be taken, as well as to facilitate capacity planning
• capacity planning - well-defined plan to periodically review system performance and plan upgrades well before performance is affected.

4.2. EPP Command Response Times

In general, EPP command response time is the sum of the processing times required by each component responsible for processing the request, as well as the internal network round trip time required. The following tabulates the components and their respective overhead in our SRS implementation:

• EPP Servers Processing overhead: decoding of SSL frames, session management, EPP message processing
• Application Servers Processing overhead: command processing logic including validation and business rules.
• Database Servers Processing overhead: performing read and write transactions involving disk I⁄O, intra-cluster communication for managing consistency

GMO Registry optimizes EPP command response times by employing the following strategies:
• defer operations that can be performed in the background, removing them from the critical command processing path. Examples of such operations are: billing, DNS updates, Whois update
• employ efficient coding techniques such as safe caching of static data, parallelizing operations where possible, lightweight compression to minimize expensive network round trip (relative to CPU time required for compression⁄decompression)
• careful tuning of components to cater to the load characteristics

4.2.1. Service Level Parameters

The following service level parameters are defined in Specification 10. GMO Registry is aware that for the purposes of determining service levels, the following round-trip time (RTT) measurements are timed from the perspective of the testing probes, and includes the network latency of the link between the probes and the SRS infrastructure. While this effectively increases the rigor of the requirements, GMO Registry is committed to exceeding the SLRs, and uses significantly more stringent thresholds for monitoring and internal targets.

4.2.1.1. EPP Query Command RTT

Specification 10 defines this to be the “RTT of the sequence of packets that includes the sending of a query command plus the reception of the EPP response for only one EPP query command.” The Service Level Requirement for this parameter is “≤ 2000 ms, for at least 90% of the commands”, as seen from the testing probes.

GMO Registry’s SRS implementation is highly optimized for performance. Query command processing is efficient and requires minimal resources. In addition, it is able to linearly scale query commands to increase concurrency by adding capacity.

Production and load tests log analysis confirms that GMO Registry’s SRS infrastructure has the capability to handle query commands well within 100ms at 160 transactions per second.

4.2.1.2. EPP Session Command RTT

Specification 10 defines this to be the “RTT of the sequence of packets that includes the sending of a session command plus the reception of the EPP response for only one EPP session command. For the login command it will include packets needed for starting the TCP session. For the logout command it will include packets needed for closing the TCP session.” The Service Level Requirement for this parameter is “≤ 4000 ms, for at least 90% of the commands”, as seen from the testing probes.

From a processing perspective, session commands have a similar load profile to that of EPP Query Commands, with the overhead of TCP and SSL establishment and teardown. The former involves handshake packets, which may amplify any latency issue between the testing probes and the SRS infrastructure.

The SRS has the capability to handle session commands well within 100ms at 210 transactions per second.

4.2.1.3. EPP Transform Command RTT

Specification 10 defines this to be the “RTT of the sequence of packets that includes the sending of a transform command plus the reception of the EPP response for only one EPP transform command.” The Service Level Requirement for this parameter is “≤ 4000 ms, for at least 90% of the commands”, as seen from the testing probes.

GMO Registry’s SRS implementation is highly optimized for performance. Transform commands are by nature more complex than queries, and involve database write operations with transaction management within the database cluster. For performance and fault tolerance, GMO Registry utilizes workers to perform operations in the background. This removes potentially expensive operations from the processing pipeline, improving performance and reliability.

In addition, the GMO Registry database seamlessly scales write operations linearly with cluster size, so that capacity can be added on demand. Please refer to the answers to Question 33 “Database” for more information.

The SRS has the capability to handle transform commands well within 500ms at 150 transactions per second.


4.3. Capacity

GMO Registry anticipates that .gree will utilize less than 35% of the infrastructure capacity reserved for .gree during the first 3 years of operation. Individual systems are upgraded when utilization reaches 60%.

GMO Registry conducts frequent utilization assessments to determine the need for infrastructure upgrades.

Please refer to the “Scale, Projection and Costs” section of the answers to Question 31 “Registry Overview” for more details.


5. Resourcing Plans

The implementation and operation of this aspect of registry operations fall under the areas of responsibility of the following roles:
• Technical Manager
• Network Engineer
• Applications Engineer
• Database Administrator
• System Architect
• System Administrator
• Technical Support
• Security Officer
• QA and Process Manager

The attached table, “resource_fte.png”, outlines the overall FTE equivalent resources available to GMO Registry for the initial implementation and ongoing operations of the registry, of which SRS Performance is a subset.

5.1. Initial Implementation

Initial implementation of SRS Performance refers to:
• implementation and deployment of the infrastructure and systems outlined in this document, a significant portion of which already exists in the current GMO Registry production infrastructure;
• implementation of performance and availability monitoring in support of the goals outlined in this document, that are not already in the current production monitoring setup.

During this phase, all roles listed above are involved in the planning and implementation of their respective systems in support of this component.

5.2. Ongoing Maintenance

The ongoing maintenance of SRS Performance involves:
• monitoring of performance and availability objectives
• analyzing systems behavior and optimizing application, configuration and architecture to yield improved performance
• conducting proactive maintenance according to the standard operational procedures

All roles listed above are involved in this phase of the operations.

25. Extensible Provisioning Protocol (EPP)

1. Overview

Extensible Provisioning Protocol (EPP) is the industry standard interface for managing registrations between a registry and its registrars in a Shared Registration System (SRS). It is specified in a series of IETF RFCs.

EPP, in summary, consists of a generic XML-based protocol framework (RFC 5730) that specifies the high level commands that are generally useful in the provisioning of registry objects, as well as an extension mechanism for managing various classes of registry objects. Extensions that prescribe the use of certain object classes are commonly referred to as “mappings”. Of particular interests to gTLD registries and registrars are: domain name mapping (RFC 5731), host mapping (RFC 5732), contact mapping (RFC 5733), grace periods mapping (RFC 3915), and DNSSEC mapping (RFC 5910.)

The framework was designed to decouple content from the underlying network transport, so that the same XML serialization format and protocol flow may be carried by different underlying transports such as TCP, SMTP, HTTP. By far, the most commonly used transport is Transport Layer Security (TLS) over TCP as specified in RFC 5734.

GMO Registry (backend registry)’s implementation of EPP is fully compliant with RFCs 5730, 5731, 5732, 5733, 5734, 3915 and 5910. In addition, custom extensions are compliant with RFC 3735.


2. Architecture

CRMP employs a multi-tiered EPP service architecture to achieve fault tolerance, availability, scalability and security. The EPP service is logically separated into Front End Servers and Back End Application Servers. This architecture provides several benefits:
● better resource utilization - each component can be scaled independently according to its respective load profile
● risk isolation - decoupled components communicating via well-defined interfaces minimizes the exposure in cases such as fault or compromise of one component
● fault tolerance - redundant load-balanced instances presents no single point of failure
● high availability - back end application servers can be restarted or taken out of rotation without affecting registrar connections

The following diagram depicts the stated architecture of the EPP service comprising Front End EPP Servers and Back End Application Servers.

EPP and Application Servers Architecture


![attached: 25_1.png](⁄25_1.png)

2.1. Front End Servers

Externally, it offers a standards-compliant EPP service protected by TLS over TCP port 700. This is handled by a cluster of high-performance, lightweight front end servers whose primary functions are to encode and decode EPP frames, authenticate clients and maintain the persistent connections (authenticated sessions.)

The cluster is protected behind redundant firewalls, and is load balanced so it scales linearly with the number of servers. Each server has a capacity of 10,000 concurrent connections.

The front end servers also features additional safeguards against abuse. A maximum concurrent connections limit per registrar may be set, and also rate limits for read and write EPP transactions may be enforced.

2.2. Back End Application Servers

All commands from clients are received by the front end EPP servers and forwarded to an internal cluster of application servers using an efficient and reliable remote procedure call mechanism. The application server is armed with SRS application logic, business rules and TLD policies. Each incoming EPP command is processed and returned to the front end EPP server.

The attached diagram depicts the interaction between the EPP Server and Application Server in a typical session.

EPP and Application Servers Interaction

![attached: 25_2.png](⁄25_2.png)

The application server implements a set of fully standards-compliant EPP mappings for domains, hosts, contacts objects, as well as DNSSEC and grace period data. It implements the “hostObj” style for specifying name servers in the domain mapping (RFC 5731), which is more widely implemented in gTLD registries than the “hostAttr” alternative.


3. Interface Specification

3.1. Transport

GMO Registry will offer EPP over the most commonly used transport -- Transport Layer Security (TLS) over TCP as specified in RFC 5734.

The EPP server requires clients to present a client certificate during the TLS⁄SSL handshake phase. GMO Registry supports a list of trusted commercial certification authorities (CAs) that issue client certificates, and will make the list available to registrars.

The client certificate SHA1 fingerprint must be pre-provisioned out of band and linked to the registrar’s EPP account in the SRS database. It will be used as an additional authentication factor which, together with the client ID and password, will be validated at the time of EPP session establishment (login).

3.2. Base EPP Standards

GMO Registry fully supports the core EPP specification (RFC 5730), as well as the Domain Name Mapping (RFC 5731), Host Mapping (RFC 5732), and Contact Mapping (RFC 5733).

3.3. Extensions

In addition to the core EPP specification and the basic object mappings, GMO Registry also supports the mappings specified in the following IETF standards track RFCs.

3.3.1. RFC 3915 - Grace Period Mapping

In order to encourage interoperability and ease registrar integration to the GMO Registry SRS, the grace period mapping is fully adopted to support the domain name lifecycle. Please refer to the answers to Question 27 “Registration Lifecycle”.

3.3.2. RFC 5910 - DNSSEC Mapping

GMO Registry accepts Delegation Signer (DS) records from child zones (registered domains) over EPP using the DS Data Interface specified in RFC 5910.

3.3.3. Launch Phase Mapping

GMO Registry will adopt any formally ICANN-approved EPP extension to manage its sunrise process. Absent such an extension, GMO Registry will adopt the launch phase mapping designed by Cloud Registry to manage applications for domain names, typically during the initial phases of a gTLD launch, such as Sunrise or land rush.

It does not impact the registration lifecycle of domains as application objects are managed separately from domain objects. The relationship between application objects and domain objects are outlined below:

● Name uniqueness - there may be multiple application objects for a given domain name, whereas there can only be a single domain object for a given domain name at any time.
● Registration blocking - once a domain name is applied for, an application is created and at the same time the corresponding domain name is blocked from registration.
● Allocation - depending on registry policies, during and at the end of a launch phase, applications will be processed and eventually allocated or cancelled. If allocated, a domain is created with information from the application. Once created, the domain has no further relationship with the application from which it was created.
● Trademark validation - certain launch phases with rights protection mechanisms in place may require rights to be validated by a third party such as the Trademark Clearinghouse. In those instances, trademark related data is attached to application objects and special business rules are in place to validate them against the third party validation service.

Cloud Registry contributed the initial IETF draft to the wider ICANN community and brought the discussions to the IETF Provreg mailing list for community consensus building, with a view to take it to IETF Standards Track RFC.

This draft document is attached as ![EPP Launch Phase Mapping Internet Draft](⁄q25_draft-tan-epp-launchphase-01.pdf). Latest version of the specification will be published at http:⁄⁄tools.ietf.org⁄html⁄draft-tan-epp-launchphase or the collaborative online repository: https:⁄⁄github.com⁄cloudregistry⁄EPP-Launch-Phase-Extension-Specification


3.3.4. IDN Extension

In order to support IDN registrations carrying a language tag attribute, GMO Registry supports the EPP Extension specified in the IDN Mapping Extension for EPP, currently in draft form with the latest version available at 〈http:⁄⁄tools.ietf.org⁄html⁄draft-obispo-epp-idn〉. A copy is also attached as ![EPP IDN Mapping Internet Draft](⁄q25_draft-obispo-epp-idn-00.pdf).


4. Operations

As part of the SRS operations, the EPP service is proactively monitored to facilitate detection and reaction to fault and abuse. This also includes metrics collection that aids in capacity and load planning to ensure that ample headroom is provided in anticipation of load spikes. For more details, please consult the response to Question 42: Monitoring and Fault Escalation.


5. Resourcing Plans

The implementation and operation of the EPP service involve the following roles:
● Technical Manager
● Network Engineer
● Applications Engineer
● Database Administrator
● System Architect
● System Administration
● Technical Support
● Security Officer
● Registry Administrator
● Trademark Protection
● QA and Process Manager

The attached table, “resource_fte.png”, outlines the overall FTE equivalent resources available to GMO Registry for the initial implementation and ongoing operations of the registry, of which the EPP service is a subset.

5.1. Current Capabilities
The registry platform is already deployed and proven in production supporting two ccTLDs. With the exception of additional policies that are specific to each ccTLD, these implementations are consistent with the specifications detailed in this document.

5.2. Initial Implementation
Initial implementation of this aspect of registry operations refers to:
● allocation of network resources such as dedicated front end and backend virtual IP addresses
● implementation of monitoring configurations outlined in this document that are additional to the current production monitoring setup
● implement the EPP extensions outlined, of which a majority are already supported in production.

During this phase, all roles listed above are involved in the planning and implementation of their respective systems in support of this component.

5.3. Ongoing Maintenance
The ongoing maintenance of the EPP service involves:
● monitoring the EPP infrastructure and service ensuring the SLA obligations of Specification 10 are met
● providing technical support to registrars regarding connection or SSL handshake issues
● provisioning of firewall rules according to IP subnets given by registrars
● capacity planning

The follow roles are involved in this phase of the operations:
● Technical Manager
● Applications Engineer
● System Administration
● Technical Support
● Security Officer
● Registry Administrator
● QA and Process Manager

26. Whois

1. Overview

The Whois service is a concrete implementation of the Registration Data Directory Services, and is one of the five critical registry functions.

Whois provides “telephone directory” like information services to the public at large. In a domain name registry context, the contents published by Whois typically include public information about registered domain names, contacts, nameservers, as well as registrars.


2. Compliance

GMO Registry (backend registry) implements a Whois service that is based on industry best practice and complies with the following:
● RFC 3912 - Whois Protocol Specification
● Output format as prescribed in Specification 4 of the ICANN gTLD Agreement
● As required in Section 1.5, Specification 1 of the ICANN gTLD Agreement, GMO Registry shall offer IPv6 access to the Whois protocol service as well as the web-based Whois query interface.

GMO Registry has plans to offer a RESTful Whois service over HTTP and HTTPS as an enhanced alternative to the port 43 service. GMO Registry supports the WHOIS-based Extensible Internet Registration Data Service (WEIRDS) Internet Draft authored by ICANN staffs and other community members “A RESTful Service for Domain Name Registration Data” 〈http:⁄⁄tools.ietf.org⁄html⁄draft-sheng-weirds-icann-rws-dnrd-00〉. When consensus and ⁄ or standards emerge in the IETF, GMO Registry will strongly consider implementing it.


3. Whois System Description

![attached: 26_1.png](⁄26_1.png)



The GMO Registry Whois service is a logically distinct subsystem that is connected to the SRS via a well-defined interface. The Whois service acts as a passive subscriber to the SRS, from which it obtains updates to data. There are two components which facilitate its functionalities.

3.1. Whois Publication Subsystem

The WHOIS publication subsystem is the Whois processing pipeline that resides logically within the SRS. It main tasks are as follows:
● subscribes to changes (objects created, updated, deleted) made to the SRS
● performs filtering
● data transformation
● indexing of the data making it suitable for efficient Whois querying
● writes the data to the Whois Master Database.

3.2. Whois Service Network

The WHOIS service network is the public Whois service offered via two interfaces - Whois protocol (RFC3912) and a web-based Whois query interface. The Whois service, including both interface types, is made available via a dedicated Whois instance infrastructure deployment and is accessible over an anycast IPv4 and anycast IPv6 network.

3.2.1. Whois Instances

A Whois Instance is a collection of components residing on a server, or group of servers, that work together to deliver the required Whois interfaces. The Whois Service Network consists of redundant Whois instances in multiple geographically diverse sites.

Each Whois Instance contains the following components:
● Two, or more, Whois daemons on independent, load-balanced, hardware answering TCP port 43 queries
● Two, or more, Whois Slave Databases that replicate data from the Whois Master Database in near real-time
● Two, or more, web servers on independent, load-balanced hardware, offering web-based Whois query capabilities
● Site-wide cache for access control and rate limiting.

The Whois daemon is a custom application designed to be performant, fault-tolerant and efficient on resource usage.

3.3. Interconnectivity with Other Registry Systems

The Whois service is logically decoupled from other registry components. The processing of updates to the Whois database resides in the Whois Publication Subsystem of the SRS and is triggered by actions against the SRS database.

The SRS application server, upon executing write transactions originating from registrars or initiated by the server, persists the changes to the SRS database. The following types of transactions may trigger an update to the Whois service:
● Create Domain
● Update Domain
● Renew Domain (including autorenews)
● Transfer Domain (including intermediate state changes)
○ child hosts that are automatically transferred when the parent domain’s transfer operation is effected will also be reflected in Whois
● Delete Domain
● Restore Domain
● Create Contact
● Update Contact
● Transfer Contact (including intermediate state changes)
● Delete Contact
● Create Host
● Update Host
● Delete Host
● Create Registrar
● Update Registrar
● Delete Registrar


3.3.1. Update Frequency

The Whois Publishing Worker batches together updates within a 5-minute window and updates the Master Whois Database.

The chain of databases, originating from the Whois Master Database to the various Whois Slave Databases are synchronized using real-time streaming replication. Typically, the replication delay between master and slave is on the order of seconds.

Replication delay is affected by network latency between data centers as well as load on the responsible systems. We mitigate load issues by over-provisioning, monitoring, and careful benchmarking and tuning. While connectivity issues are generally in upstream provider infrastructure, the Anycast rollout offers a readily available alternative access point for any whois query. We actively monitor links and replication delay on each slave node. Should connectivity issues persist for extended periods, we will manually take the relevant node out of service to maintain the integrity of the presented data without affecting availability.

This update frequency of the Whois Publishing Worker, together with the Whois DB master-slave synchronization ensures the RDDS update time falls well within the SLA outlined in Specification 10 of the gTLD Agreement. Additionally, active monitoring of metrics and faults allows us to detect and respond to issues quickly to ensure that SLA can be met.


3.4. Abuse Prevention

In order to mitigate the potential for abuse or malicious attacks to the Whois service, leading industry practices are followed.

On the Whois protocol service, clients are rate-limited to a configurable number of queries per minute. The rate limits can be applied to single IP addresses as well as subnets. The initial rate limit is configured to be 60 queries per minute per IP address. GMO Registry will review the rate limits periodically based on collected statistics.

On the web-based query interface, users are required to correctly fill out a captcha in order to obtain service.

Unauthorized clients whose IP addresses and subnets consistently exceed the rate limits will be blacklisted for exponentially growing lengths of time.


3.5. Bulk Access
Bulk access to Whois data is available to parties with legitimate needs. Examples include security researchers and law enforcement agencies. Bulk access arrangement should be made directly to GMO Registry. Bulk access may be provided in one or both of the following forms:
● removal of rate limits or captcha restrictions for a small source IP address or subnet.
● access to download bulk Whois data in a similar arrangement to the Bulk Registration Data Access requirements outlined in Specification 4 of the gTLD Agreement. Specifically:
○ Content: public thick Whois content
○ Format: escrow deposit format as specified in Specification 2
○ Protocol: SFTP or HTTPS, restricted to pre-provisioned client IP or subnet


4. Whois Infrastructure
The publicly visible Whois service will live on whois.gree, under which one A and one AAAA record will be published. These addresses are advertised via two independent network providers and between 4 geographically dispersed Whois nodes to provide closest point of access and redundancy. All nodes are deployed on dedicated Whois infrastructure equipment and transit links. They do not share any of the SRS infrastructure and are physically separated from the SRS infrastructure. One of the advantages of using Anycast is that it is always possible to strategically and transparently add nodes in case there is a hotspot. By placing a local Anycast node near the geographical hotspot, traffic can be drawn away from the global Anycast nodes.

The IPv4 address will be souced and advertised as part of the 103.5.94.0⁄24 address block. The IPv6 address will be sourced and advertised as part of the 2402:8700:94::⁄48 address block.


RDDS Anycast Network

![attached: 26_2.png](⁄26_2.png)

Each whois node is equipped with two firewalls in a clustered configuration and two load balancers in a clustered configuration. The active firewall in the cluster will advertise the Anycast ranges via BGP to the upstream providers and forward the traffic using Network Address Translation (NAT) internally to the load balancer cluster. Additionally each firewall is equipped with a dedicated link and ip addresses to facilitate management access and IPSec VPN tunnels for the data replication from the Whois Distribution Master in the SRS.

Each Whois node will initially consist of two (2) servers providing the RDDS function. Each of these servers contains the full suite of software and data required to service both of the Whois interfaces. Both servers are actively used as incoming queries are distributed via the onsite load balancer. Additional capacity can be added transparently and quickly by adding additional servers with the full whois stack.

The Whois instance infrastructure is depicted below.




RDDS Node Infrastructure

![attached: 26_3.png](⁄26_3.png)


5. Resourcing Plans

The implementation and operation of this aspect of registry operations involve the following roles:
● Technical Manager
● Network Engineer
● Applications Engineer
● Database Administrator
● System Architect
● System Administration
● Security Officer
● Technical Support
● Registry Administrators
● Trademark Protection Officer
● QA and Process Manager

The attached table, “resource_fte.png”, outlines the overall FTE equivalent resources available to GMO Registry for the initial implementation and ongoing operations of the registry, of which the provision of Whois is a subset.

5.1. Initial Implementation

Initial implementation of this aspect of registry operations refers to:
● implementation and deployment of the Whois hardware and systems outlined in this document, a significant portion of which already exists in the current production deployment
● allocation of network resources such as dedicated IPv4 and IPv6 addresses
● customization of the headers, footers, legal text, web-based Whois templates
● implementation of monitoring configurations outlined in this document that are additional to the current production monitoring setup.

During this phase, all roles listed above are involved in the planning and implementation of their respective systems in support of this component.

5.2. Ongoing Maintenance

The ongoing maintenance of the Whois service involves:
● monitoring the RDDS infrastructure and service ensuring the SLA obligations of Specification 10 are met
● conducting proactive maintenance according to the standard operational procedures
● provisioning of bulk whois data access
● reviewing rate limits and implementing changes as may be required to curb abuse

All roles listed above are involved in this phase of the operations.

27. Registration Life Cycle

Overview

Registration Lifecycle refers to the various stages that a domain object in the SRS go through, as well as all possible states (and combinations thereof) in which it may exist, along with events that trigger each state change.

It is commonly understood that domains are registered for a fixed period of time, after which it expires. However, it is not well known outside the ICANN community that, for a variety of business, policy, security reasons, there exist many policies that warrant a complex lifecycle that commences the moment a domain is registered.

The registration lifecycle in the SRS is modeled after ICANN consensus policies and current best practices in gTLD registries, and is fully compliant with the standards track EPP RFCs, specifically RFC 5731 (EPP domain name mapping) and RFC 3915 (EPP domain registry grace period mapping).

The following diagram illustrates an overview of the domain registration lifecycle.

![attached: 27_1.png](⁄27_1.png)



EPP Statuses

The EPP Domain Name Mapping specifies a set of statuses that may be associated with a domain name, along with their semantics and constraints on how they can be combined.

The following status values are supported by the .gree registry. Status values that are prefixed with “client” can be managed by the sponsoring registrar. Status values that are prefixed with “server” is managed by the registry, either through automated processes in the SRS or manually updated by the registry operator.

clientDeleteProhibited, serverDeleteProhibited:
Requests to delete the domain will be rejected by the SRS.

clientHold, serverHold:
The domain will not be included in the zone file.

clientRenewProhibited, serverRenewProhibited:
Requests to renew the domain will be rejected by the SRS.

clientTransferProhibited, serverTransferProhibited:
Requests to transfer the domain will be rejected by the SRS.

clientUpdateProhibited, serverUpdateProhibited:
Requests to update the domain (other than to remove this status) will be rejected by the SRS.

Inactive:
This is the default status when a domain is first created and there are no associated host objects for the DNS delegation. This status is also be set by the server when all host-object associations are removed.

Ok:
This is the normal status value for a domain that has no pending operations or prohibitions. This value is set and removed by the server as other status values are added or removed.


Grace Periods

In addition to standard EPP statuses, the registry also implements operational grace periods commonly offered in other gTLD registries. The following grace periods and their associated rules apply:

Add Grace Period (AGP): This grace period is provided after the initial registration of a domain name. The registration fee will be charged to the registrar of the domain name at the time of the initial registration of the domain name. The value of the Add Grace Period is 5 calendar days.

- If the domain name is deleted by the registrar during this period, the domain name will be deleted immediately and become available for registration. The registry provides a credit to the registrar for the cost of the registration except when it exceeds the excess deletion limit according to the Add Grace Period Limits consensus policy.

- If the domain name is extended during this period, no credit for the extension will be provided to the registrar of the domain name. The fee for the number of the extended years will be charged to the registrar of the domain name when the domain name is extended.

- The ICANN consensus policy on Inter-Registrar Transfer does not allow transfers within the first 60 days after the initial registration. It is the registrars’ responsibility to enforce this restriction, and the SRS also enforces it.

- Bulk transfers with ICANN approval may be made during this period according to the procedures in Part B of the ICANN Policy on Transfer of Registrations between Registrars. The expiration dates of transferred registrations are not affected. The fee for the initial add will be charged to the losing registrar when the domain name is registered.

(Please see [Overlapping Grace Period] for a description when an operation falls into more than one grace period.)

Auto-Renew Grace Period (ARGP): This grace period is provided after a domain name registration period expires and is extended (renewed) by one year automatically by the registry. The Auto-Renew fee will be charged at the time of the Auto-Renew. The value of the Auto-Renew Grace Period is 45 calendar days.

- If the domain name is deleted by the registrar during this period, the Auto-Renew fee will be credited to the registrar. The domain name will go into Redemption Grace Period. The status becomes Pending Delete – Restorable.

- If the domain name is explicitly extended during this period, the fee for the number of the extended years will be charged to the registrar of the domain name at the time of the extension.

- If the domain name is transferred other than ICANN-approved bulk transfer, the Auto-Renew fee will be credited to the losing registrar. The one year added by the Auto-Renew operation is cancelled. The expiration date of the domain name is extended by one year up to a total maximum of ten and the gaining registrar is charged for that additional year, even in cases where a full year is not added because of the 10-year registration term maximum.

- Bulk transfers with ICANN approval may be made during this period according to the procedures in Part B of the ICANN Policy on Transfer of Registrations between Registrars. The expiration dates of transferred registrations are not affected. The fee for the Auto-Renew will be charged to the losing registrar when the domain name is transferred.

(Please see [Overlapping Grace Period] for a description when an operation falls into more than one grace period.)

Renew Grace Period (REGP): This grace period is provided after a domain name registration period is explicitly extended (renewed) by the registrar. The renewal fee will be charged to the registrar of the domain name at the time the domain name is extended. The value of the Renew Grace Period is 5 calendar days.

- If the domain name is deleted by the registrar during this period, the registry provides a credit to the registrar for the cost of the renewal. The domain name will go into Redemption Grace Period. The status becomes Pending Delete – Restorable.

- If the domain name is extended during this period, the fee for the number of the extended years will be charged to the registrar of the domain name at the time of the extension.

- If the domain name is transferred other than ICANN-approved bulk transfer, there is no credit to the losing registrar. The expiration date of the domain registration is extended by one year and the years added as a result of the Renew remain on the domain name up to a total of 10 years. The gaining registrar will be charged for that additional year, even in cases where a full year is not added because of the 10-year registration term maximum.

- Bulk transfers with ICANN approval may be made during this period according to the procedures in Part B of the ICANN Policy on Transfer of Registrations between Registrars. The expiration dates of transferred registrations are not affected. The fee for the number of the extended years will be charged to the losing registrar when the domain name is extended.

(Please see [Overlapping Grace Period] for a description when an operation falls into more than one grace period.)

Transfer Grace Period (TGP): This grace period is provided after the successful transfer of domain name registration sponsorship from one registrar to another registrar. The transfer fee will be charged to the gaining registrar at the time the domain name is transferred. The value of the Transfer Grace Period is 5 calendar days.

- If the domain name is deleted by the gaining registrar during this period, the registry provides a credit to the gaining registrar for the cost of the transfer. The domain name will go into Redemption Grace Period. The status becomes Pending Delete – Restorable.

- If the domain name is extended during this period, there is no credit for the transfer. The fee for the number of the extended years will be charged to the registrar of the domain name at the time of the extension.

- The ICANN consensus policy on Inter-Registrar Transfer does not allow transfers within the first 60 days after another transfer has occurred. It is the registrars’ responsibility to enforce this restriction, and the SRS also enforces it.

- Bulk transfers with ICANN approval may be made during this period according to the procedures in Part B of the ICANN Policy on Transfer of Registrations between Registrars. The expiration dates of transferred registrations are not affected. The fee for the transfer that occurred prior to the Bulk Transfer will be charged to the losing registrar when the domain name is transferred.

(Please see [Overlapping Grace Period] for a description when an operation falls into more than one grace period.)

Redemption Grace Period (RGP): A domain name is placed in Redemption Grace Period status when a registrar requests the deletion of a domain that is not within the Add Grace Period. A name that is in Redemption Grace Period status will not be included in the zone file. A registrar can not modify or purge a domain in Redemption Grace Period status. The only action a registrar can take on a domain in Redemption Grace Period is to request that it be restored. Any other registrar requests to modify or otherwise update the domain will be rejected. Unless restored, the domain will be held in Redemption Grace Period for 30 calendar days.


Overlapping Grace Period

If an operation is performed that falls into more than one grace period, the following rules apply:

- If a domain name is deleted within the Add Grace Period and the Renew Grace Period, the registry provides a credit to the registrar for the cost of the registration and renewal. The domain name will be deleted immediately and become available for registration.

- If a domain name is auto-renewed, then extended within the Auto Renew Grace Period, and then deleted within the Renew Grace Period, the registry provides a credit to the registrar for the cost of the auto-renew and renewal. The domain name will go into Redemption Grace Period. The status becomes Pending Delete – Restorable.

- If a domain name is transferred, then extended within the Transfer Grace Period, and then deleted within the Renew Grace Period, there is no credit to the current (gaining) registrar for the transfer. The registry provides a credit to the current registrar for the cost of the renewal. The domain name will go into Redemption Grace Period. The status becomes Pending Delete – Restorable.

Note: If several billable operations, including a transfer, are performed on a domain name and the domain name is deleted within the grace periods of each of those operations, only those operations that were performed after the latest transfer, including the latest transfer, are credited to the current registrar.


Pending Periods

Pending Transfer: A specified number of calendar days following a request from a registrar (registrar A) to transfer a domain in which the current registrar of the domain (registrar B) may explicitly approve or reject the transfer request. The value of the Pending Transfer period is five calendar days for all registrars. The transfer will be finalized upon receipt of explicit approval or rejection from the current registrar (registrar B). If the current registrar (registrar B) does not explicitly approve or reject the request initiated by registrar A, the registry will approve the request automatically after the end of the Pending Transfer period. During the Pending Transfer period:
• EPP TRANSFER request is denied
• EPP RENEW request is denied.
• EPP DELETE request is denied.
• EPP UPDATE request is denied.
• AUTO-RENEW is allowed.
• Bulk Transfer operations are allowed.
After a transfer of a domain, the EPP TRANSFER request may be denied for 60 days.

Pending Restore (optional): This status value is used to describe a domain that is in the process of being restored during the Redemption Grace Period.

Pending Delete: A domain name is placed in Pending Delete status if it has not been restored during the Redemption Grace Period. A name that is in Pending Delete status will not be included in the zone file. All registrar requests to modify or otherwise update a domain in Pending Delete status will be rejected. A domain name is purged from the registry database a specified number of calendar days after it is placed in Pending Delete status. The length of this Pending Delete Period is five calendar days.


Resourcing Plan

Domain lifecycle management is a core function of the SRS. As such, the responsibilities of maintaining and operating this aspect of registry operations involve the following roles:
● Technical Manager
● Applications Engineer
● System Architect
● Security Officer
● Technical Support
● Registry Administrators
● Trademark Protection Officer
● QA and Process Manager

The attached table, “resource_fte.png”, outlines the overall FTE equivalent resources available to GMO Registry for the initial implementation and ongoing operations of the registry, of which the management of domain lifecycle is a subset.

Initial Implementation

Initial implementation of this aspect of registry operations refers to:
● implementation of the domain lifecycle and grace period policies outlined above in all related registry components including billing, majority of which already exists in the current production SRS
● conducting training for customer support personnel
● creation of registrar documentation relating to the grace period policies

During this phase, all roles listed above are involved in the planning and implementation of their respective systems and processes in support of this component.

Ongoing Maintenance

The ongoing maintenance of the domain lifecycle is a constituent of the SRS operations, which involves:
 Monitoring the lifecycle processes to ensure accurate and timely operation
 Providing customer support to registrars in regards to policies, grace periods and billing
 Engaging in knowledge sharing within the ICANN community to contribute to, and adopt best practices and⁄or consensus policies that may emerge from time to time

All roles listed above are involved in this phase of the operations.

28. Abuse Prevention and Mitigation

In order to safeguard the security and stability of .gree, as well as the Internet at large, Gree, 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:

- conducting pre-verification of registration eligibility
- 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; and
- developing procedures for handling complaints, including takedown requests, in a timely manner.

.gree is a domain for Gree, Inc. its stakeholders, and the GREE SNS community and domain name registration of the TLD will be available to the members of the GREE SNS community. However, as stated in Question 18, the registry believes that allowing registrations on the basis of membership in the community alone would open the TLD to increased risk of abuse. As a consequence, the registry will adopt the following registration policy to restrict the eligibility, name selection and usage of domains.

Domain Name Registration Categories
Domain name registration may qualify in one of the following two categories.
A. GREE SNS community operator registration
B. GREE SNS community member participant registration

A. GREE SNS Community Operator Registration
Domain names registered in this category must be registered solely by an entity that contributes to operation of the community, upon successful verification. Verification will be conducted by the registry, and organizations that wish to apply for a .gree dedicated account will be required to provide proof of registration eligibility to the registry via a .gree accredited registrar. Proposed valid forms of documentary proof include, but are not limited to,
- company seal (registered or unregistered)
- signature of management staff

A community operator must be one of the following.
- GREE, Inc.
- Companies listed in the annual securities report of GREE, Inc.
- Contributors to the operation of GREE


B. GREE SNS Community Member Participant Registration
Domain names registered in this category must be registered by a community operator in conjunction with a community member. Community members who wish to register a domain name under this category will be required to undergo evaluation. The evaluation will seek to determine whether the applied for domain name would benefit the community. For evaluation purposes, applicants must submit a proposal to GREE, Inc. addressing at minimum the following four points.

- The domain name being applied for
- Purpose of applied for domain name registration
- Specific intended content restriction and use of the applied for domain name
- Reason the applied for domain name registration would benefit the community

Community members whose evaluations are successful will operate the applied for domain in partnership with a GREE SNS community operator and in accordance with the submitted proposal.


Regardless of the registration category, all domain names and associated contact details are verified at registration time. Should there be any material changes to the verified information at any time, the registrant or administrative contact must notify the registry of the change. Failure to comply with the policies may result in the suspension, cancellation or transfer of any registration or transaction, as well as the placement of lock, hold or similar statuses on existing domain names.

The registry believes that the verification step will help mitigate abusive activities including abusive registrations as well as promote Whois accuracy.

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; and
- Posting information that is offensive to public order or morals.

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.

Abuse Public Contact Information
In order to comply with Specification 6.4.1 of New gTLD Agreement, the registry will provide to ICANN its Abuse contact details. The information will include a valid e-mail and mailing address and a primary contact, and the registry will promptly provide to ICANN a notice of any changes to the contact.

Also, the registry will also publish its abuse public contact information on its web site when it publicly releases the .gree domain name registration policies. The abuse public contact will be responsible for handling complaints concerning abusive activities relating to domains registered under the .gree 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.

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.

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.
- Nomal: 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. The registry 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.


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.


Resourcing Plans
The implementation and operation of this aspect of registry operations involve the following roles:
● Technical Manager
● Network Engineer
● Applications Engineer
● Database Administrator
● System Architect
● Security Officer
● Technical Support
● Registry Administrators
● Trademark Protection Officer
● QA and Process Manager

The attached table, “resource_fte.png”, outlines the overall FTE equivalent resources available to GMO Registry for the initial implementation and ongoing operations of the registry, of which abuse handlings a subset.

Initial Implementation
Initial implementation of this aspect of registry operations refers to:
● development of detailed procedures on the policies and procedures set forth above
● configuration of the customer support ticketing system for efficient handling of abuse complaints
● training of the operational staff

During this phase, all roles listed above are involved in the planning and implementation of their respective systems in support of this component.

Ongoing Maintenance
The ongoing maintenance of abuse mitigation involves:
● proactive monitoring of the SRS, Whois and DNS services to detect and curb abuse
● acting as the primary abuse point of contact to coordinate the handling of complaints received and escalating to relevant vendors as necessary
● monitoring of security mailing lists for takedown requests arising from security researchers and emergency response teams
● participating in relevant ICANN communities to engage in knowledge sharing, implementing best practices that may emerge


The follow roles are involved in this phase of the operations:
● Technical Manager
● Technical Support
● Security Officer
● Registry Administrator
● Trademark Protection Officer
● QA and Process Manager

29. Rights Protection Mechanisms

Gree, Inc. is committed to implementing and adhering to any rights protection mechanisms that may be mandated from time to time by ICANN, as required by Specification 7 of the New gTLD Agreement.

In order to minimize abusive activities and protect the legal rights of others, the registry will adopt the following policies and practices:

- Pre-Verification of Registration Eligibility
- Sunrise Registration Process
- Trademark Claims Service
- Uniform Rapid Suspension (URS) System
- Uniform Domain Name Dispute Resolution Policy (UDRP)
- Abusive Use Policy

Pre-Verification of Registration Eligibility
All domain names and associated contact details are verified at registration time. Should there be any material changes to the verified information at any time, the registrant or administrative contact must notify the registry of the change. Failure to comply with the policies may result in the suspension, cancellation or transfer of any registration or transaction, as well as the placement of lock, hold or similar statuses on existing domain names. For details on the pre-verification of registration eligibility, please refer to Question 18.


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

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

Sunrise Eligibility Requirements
In accordance with the section entitled “Trademark Clearinghouse” of the Application Guidebook (January 11, 2012 version), .gree SER will at least include
- Acceptable marks:
 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;
 that have been court-validated; or
 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.

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

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 at its own discretion.
- 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 on a first-come-first-served basis.
- Deletion, renewal, and transfer of a Sunrise domain name will be prohibited for 60 calendar days after the domain name is successfully registered.

Sunrise Dispute Resolution Policy
As required by ICANN, proposed .gree 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.


Trademark Claims Service
As is required by ICANN, the registry is committed to implementing the Trademark Claims Service for marks in the Trademark Clearinghouse.

Please Note: Rules and procedures will be determined as soon as the Trademark Claims Service is finalized by ICANN.

The registry will run the process for at least 60 days after the general registration opens. However, the registry may revise the length of this period if ICANNN requirements are amended.

URS System
The registry is committed to adopting and abiding by the URS System for trademark owners who seek a rapid system to take down domain names which infringe on their rights. All .gree TLD registrars and registrants must agree to abide by the URS System.

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

Abusive Use Policy
In addition to the policies and practices described in this section, the registry sets forth the Abusive Use Policy to minimize abusive activities. Not all abusive activities necessarily affect rights but some abusive activities do affect the rights when the activities are in conjunction with abusive registrations. A description of the policy and takedown procedures is provided in Question 28.


Resourcing Plans
The implementation and operation of this aspect of registry operations involve the following roles:
● Technical Manager
● Network Engineer
● Applications Engineer
● System Architect
● System Administration
● Security Officer
● Technical Support
● Registry Administrators
● Trademark Protection Officer
● QA and Process Manager

The attached table, “resource_fte.png”, outlines the overall FTE equivalent resources available to GMO Registry for the initial implementation and ongoing operations of the registry, of which the implementation and maintenance of rights protection measures is a subset.

Initial Implementation
Initial implementation of this aspect of registry operations refers to:
 Implementation of SRS rules relating to the rights protection mechanisms
 planning and coordination of the launch activities to ensure proper rights protection
 coordinating with the trademark clearinghouse and dispute providers to support the rights protection mechanisms described above

During this phase, all roles listed above are involved in the planning and implementation of their respective systems in support of this component.

Ongoing Maintenance
The ongoing maintenance of rights protection measures involves:
● handling registrar enquiries about rights protection policies
● implementing URS notices and decisions
● operating rights protection services outlined above, including sunrise and trademark claims services

The follow roles are actively involved in this phase of the operations:
● Technical Manager
● Technical Support
● Registry Administrator
● Trademark Protection Officer
● QA and Process Manager

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

1. Overview

Applicant outsources its registry systems and operations to GMO Registry. The security policies, procedures and systems described in Question 30(a) and 30(b) are provided by GMO Registry.

GMO Registry understands that gTLDs are part of the Internetʹs critical infrastructure, with people, systems, organizations, governments, and businesses relying on its responsiveness, integrity, safety and continuous operation.

Recognizing that security is not just a technical solution but a framework and practice needs to be adopted in all aspects of an organization, GMO Registry adopts a holistic, multi-pronged approach to security. GMO Registry’s well-developed and comprehensive security controls and policies ensure the confidentiality, integrity, privacy and availability of registry data and systems.

As avid security practitioners and evangelists, the GMO Registry team has invested heavily in an extensive and robust security framework to operate the registry at a level of security that far exceeds the level of trust associated with .gree.

GMO Registry 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. Whilst not intending to be certified, GMO Registry implements many of the ISO⁄IEC 27001 and ISO⁄IEC 27002 security controls.


Security Levels and Commitments

GMO Registry Recognizes that security is an extremely important aspect for every TLD. The five critical registry functions service a public resource and well-defined policies and procedures are required to ensure security and stability of the Internet at large.

Implementing security effectively requires a fine balance between security and convenience. GMO Registry understands that simply applying a lock down policy works adversely towards the actual security achieved, affects productivity and hampers business processes. Applying the appropriate security measures for the given system or data, in combination with ongoing security awareness training, are the key elements to effective security.

.gree does not require heightened security levels. As such, GMO Registry makes no specific commitments other than to meet or exceed industry standard practices adopted by other gTLD registries. Nevertheless, GMO Registry is committed to operating a secure TLD by providing industry-leading security policies, procedures, systems as a baseline, which are continuously refined in order to stay abreast of the security landscape.


3. Summary of Security Policies

To be effective, security must be a team effort involving the participation and support of every GMO Registry staff who deals with information, information systems or registry functions or services. In recognition of the need for teamwork, GMO Registry security policies clarify the responsibilities of users as well as the steps they must take to help protect GMO Registry information and information systems.

Effective security will be found by ensuring that the following criteria are met for all critical registry functions:

- Availability
- Integrity
- Confidentiality
- Accountability

The GMO Registry security policies and associated procedures and systems have been developed to provide a framework along with concrete measures to support these objectives.


SCOPE

The policy statement applies to all employees, contractors, consultants, temporaries, and other workers at GMO Registry, including those workers affiliated with third parties who access GMO Registry computer networks, provide services on behalf of GMO Registry or sell using GMO Registry services e.g. registrars.

The policies apply to all computer and data communication systems, servers, applications and registry functions or services owned by and⁄or provided by GMO Registry.


RESPONSIBILITIES OF OWNERS, CUSTODIANS, AND USERS

To facilitate accountability for information assets and critical registry functions, ownership will be assigned according to the following guidelines.

Owners: Owners are the managers or their delegates within GMO Registry who bear responsibility for the five critical registry functions and related information assets. All production application systems or information related to these functions must have a designated Owner. Owners define the authorized uses of information, systems and services and define the permitted access to them.

Custodians: Custodians are in physical or logical control of GMO Registry information, systems or services. Each type of production system or service must have one or more designated Custodians. Custodians are responsible for safeguarding the information, services and functions, including implementing access control systems to prevent inappropriate access or modification of registry data and making back-ups so that critical information and functions will not be lost or unavailable. Custodians are also required to implement, operate, and maintain the security measures defined by information Owners.

Users: Users are responsible for familiarizing themselves with and complying with all GMO Registry policies, procedures, and standards dealing with security. Questions about the appropriate handling of a specific type of request or event should be directed to either the Custodian or the Owner of the involved information.


SYSTEM AND NETWORK ACCESS CONTROLS

All requests for access to GMO Registry information assets or services are requested and carried out only according to the ITIL based Change Management procedures. These procedures ensure the authenticity of the request for use.

Anonymous logons to any of GMO Registry servers or services are not permitted, with the exception of machines that are expressly for public access, such as public web, DNS or Whois servers.

All successful and failed non-anonymous accesses are logged with username, access time, type of access and source of access to a central and secure logging server. These audit trails are backed up daily to a remote and secure backup facility and retained for a period of five years.

All failed non-anonymous access are reported near real-time to the NOC via the central monitoring server and further analyzed to determine accidental or malicious attempts.

All anonymous accesses are logged with access time, type of access and source of access to the local server. These audit trails are backed up daily to a remote and secure backup facility and retained for a period of six months.


SYSTEM AND NETWORK CHANGES

Any changes to GMO Registry networks or service configurations, such as routers, firewalls, SRS, DNS, RDDS and other registry functions should be supported by approval from the Owner. Changes are requested and carried out only according the ITIL based Change Management procedures.

Emergency changes are handled by the Incident Response Team and managed via the well-defined ITIL based Incident Management procedures.


AVAILABILITY

All critical registry services are delivered utilizing fault tolerant mechanisms.

SRS functions are delivered from a primary site. All systems are deployed in a fully redundant N+1 setup and transparently withstand catastrophic failure of any single component utilizing load balancers with active health check mechanisms and clustered fault tolerant application servers. In case of a catastrophic disaster affecting the primary site, services can be delivered from a hot standby site.

Both the Primary and Hot Standby SRS sites are hosted in carrier-grade data centres and provisioned via multiple independent transit providers to mitigate technical issues with any one of the upstream carriers or DDoS events.

DNS functions are delivered utilizing an Anycast network topology ensuring availability even during catastrophic events and provide DDoS attack resilience.

RDDS functions are delivered via multiple, geographically diverse points of presence via independent transit links.


BACKUPS

All critical registry data is continuously replicated to the backup site via securely encrypted transmission channels aiming a near real-time backup. Further to that all critical registry data is backed up from the original source to a secure remote backup facility on a daily basis. This dual approach facilitates both a quick recovery in case of catastrophic disasters as well as point in time recovery or verification abilities.


INCIDENT DETECTION AND RESPONSE

A central Intrusion Detection System and a central Monitoring System are deployed to detect and report abnormalities. Mechanisms like signature based attack detection and network or service usage fluctuations are used to report possible incidents to the NOC.

All incidents are handled by the Incident Response Team and managed via the well-defined ITIL based Incident Management procedures.


INTERNAL SYSTEMS COMMUNICATIONS AND DATA EXCHANGE

All communications between systems in geographical diverse locations will take place via at least double encryption, utilizing independent encryption keys.

In the case of DNSSEC signing operations communications will take place via encrypted channels, even for systems within the same location.

DNS zone data as well as associated DNSSEC signatures are verified for validity using a “bump in the wire” methodology before updating the distribution masters ensuring a consistent public data set at all times.


PASSWORDS AND SECRETS
GMO Registry requires strong passwords to be used across the board in all systems. Regular passwords and credentials refresh for all internal as well as external systems is mandated.


4. Summary of Security Procedures

INDUCTION AND TRAINING

To be effective, security must be a team effort involving the participation and support of every GMO Registry worker who deals with information, information systems or registry functions or services. In recognition of the need for teamwork security awareness is an integral part of the GMO Registry induction and ongoing training and awareness programs.

SYSTEM AND NETWORK ACCESS CONTROLS

All requests for access to GMO Registry information assets or services are supported by approval from the appropriate system Owner and carried out only according the ITIL based Change Management procedures. These procedures were put in place to prevent unauthorized access and ensure a detailed audit trail of all access requests and access changes.

Emergency changes are handled by the Incident Response Team and managed via the well-defined ITIL based Incident Management procedures.

SYSTEM AND NETWORK CHANGES

Any changes to GMO Registry networks or service configurations, such as routers, firewalls, SRS, DNS, RDDS and other registry functions are supported by approval from the Owner. Changes are requested and carried out only according the ITIL based Change Management procedures. These procedures were put in place to assure continuity of the five critical registry functions and ensure a detailed audit trail of all system and network changes.

Changes to production systems are announced in advance to all relevant stakeholders. The announcement includes details and purpose of the scheduled change, time and date the change will take place, expected system or service impact and risk profile.

CONTINUITY AND FAILOVER TESTING

GMO Registry has established operational procedures in order to ensure disaster-preparedness and maximize availability in the event of disaster.

All chosen datacenters procedurally test the failover functionality of UPS and HVAC systems on a regular basis.

MONITORING

All systems operated by GMO Registry are actively monitored. All industry standard system metrics are monitored and data is stored for trend analysis. Alerts are placed both on real-time threshold based events as well as trend based anomalies. This dual layer approach surpasses the capabilities of traditional monitoring systems which only alert based on threshold-based events.

All systems operated by GMO Registry log system and access information to a centrally based hosts. The loghost runs dedicated processes to monitor and report suspicious successful and unsuccessful non-anonymous accesses. Access reports are generated on a daily basis for operational review and management reporting. These reports are structured per organization and per account and include number of accesses, type of access, source and activity.


Publicly accessible services are monitored both for availability and data integrity from an external viewpoint.

Remote probes have been implemented with the purpose of executing service health checks, connecting back into both Primary and Secondary monitoring servers.

All monitoring and alerting capabilities are tested on a regular basis by purposely introducing network traffic, user behavior or test data which should trigger an alert.



© 2012 Internet Corporation For Assigned Names and Numbers.