Application number: 1-890-52063 for GMO Registry, Inc.

GMO Registry, Inc.

+81 3 456 1601

+81 3 3780 5239

http:⁄⁄www.gmoregistry.com

Mr. Hirokatsu Ohigashi

Executive Director

+81 3 5456 1601

+81 3 3780 5239

newgtld@gmoregistry.com

Mr. Hiroya Tsukahara

Director

+81 3 5456 1601

+81 3 3780 5239

info@gmoregistry.com

Corporation

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)

Not Available

GMO Internet, Inc.

Hirokatsu Ohigashi
Executive Director
Hiroya Tsukahara
Director
Hiroyuki Nishiyama
Director
Masashi Yasuda
Auditor
Masatoshi Kumagai
CEO
Tadashi Ito
Director
Yoshitake Tamura
Director
Yusuke Adachi
Director

Hirokatsu Ohigashi
Executive Director
Hiroya Tsukahara
Director
Hiroyuki Nishiyama
Director
Masashi Yasuda
Auditor
Masatoshi Kumagai
CEO
Tadashi Ito
Director
Yoshitake Tamura
Director
Yusuke Adachi
Director

GMO Internet, Inc.
Not Applicable

SHOP

Not Available

GMO Registry, Inc. (the applicant) has conducted technical analysis on the applied-for string, and concluded that there are no known potential operational or rendering issues associated with the string.
The following sections discuss the potential operational or rendering problems that can arise, and how GMO Registry mitigates them.
1. Compliance and Interoperability
The applied-for string conforms to all relevant RFCs, as well as the string requirements set forth in Section 2.2.1.3.2 of the Applicant Guidebook.
2. Mixing Scripts
If a domain name label contains characters from different scripts, it has a higher likelihood of encountering rendering issues. If the mixing of scripts occurs within the top-level label, any rendering issue would affect all domain names registered under it. If occurring within second level labels, its ill-effects are confined to the domain names with such labels.
All characters in the applied-for gTLD string are taken from a single script. In addition, GMO Registryʹs IDN policies are deliberately conservative and compliant with the ICANN Guidelines for the Implementation of IDN Version 3.0. Specifically, GMO Registry does not allow mixed-script labels to be registered at the second level, except for languages with established orthographies and conventions that require the commingled use of multiple scripts, e.g. Japanese.
3. Interaction Between Labels
Even with the above issue appropriately restricted, it is possible that a domain name composed of labels with different properties such as script and directionality may introduce unintended rendering behavior.
GMO Registry adopts a conservative strategy when offering IDN registrations. In particular, it ensures that any IDN language tables used for offering IDN second level registrations involve only scripts and characters that would not pose a risk when combined with the top level label.
4. Immature Scripts
Scripts or characters added in Unicode versions newer than 3.2 (on which IDNA2003 was based) may encounter interoperability issues due to the lack of software support.
GMO Registry does not currently plan to offer registration of labels containing such scripts or characters.
5. Other Issues
To further contain the risks of operation or rendering problems, GMO Registry currently does not offer registration of labels containing combining characters or characters that require IDNA contextual rules handling. It may reconsider this decision in cases where a language has a clear need for such characters.
GMO Registry understands that the following may be construed as operational or rendering issues, but considers them out of the scope of this question. Nevertheless, it will take reasonable steps to protect registrants and Internet users by working with vendors and relevant language communities to mitigate such issues.
- missing fonts causing string to fail to render correctly; and
- universal acceptance of the TLD;

The main purpose of applying for the TLD is to establish a clear, unambiguous and easy to remember online identity for the community who are business entities or organizations that deploy commercial activities in an online or offline environment, or provide information in relation thereto over the internet and to promote a defined, meaningful, and secure name space in order to contribute to the further development of the community and the (commercial) activities of its members.

JP Morgan predicts that, by 2013 annual global ecommerce sales will be worth USD963 billion. (Nothing but Net: 2011 Internet Investment Guide on Digital Commerce, JP Morgan, 2011)

Further, the report states that “Even after several years of very robust growth in eCommerce, the sector represents less than 5% of all retail sales in the US and is even less developed in many other countries.”

The Applicant believes given burgeoning growth in the ecommerce market, and equally strong growth potential, that both the defined community and Internet users would benefit from the introduction of a dedicated commerce namespace.

Of course, .SHOP would not be restricted only to online commerce. Retailers and traders who primarily conduct transactions offline would also benefit from a web presence with a .SHOP identity especially as they face increasing competition from their online counterparts. 

The .COM generic top-level domain has provided a specific online identity for commerce since the beginning of the Domain Name System. Its powerful brand and sustained growth has been unparalleled and today about 1 in 2 domain names registered is a .COM.
 
However, .COM can no longer claim to be the exclusive online location for commerce. As a result of the unrestricted nature of the TLD, anyone who can pay the domain name registration fee can access the world’s biggest Internet extension.
 
Therefore, currently there is no domain specifically targeting business entities or organizations that deploy commercial activities. As a result, these activities are operated under various gTLDs and ccTLDs that may not be particularly relevant.
 
.SHOP makes it possible for these businesses to operate under a relevant TLD space with a clear, unambiguous and memorable online identity that is recognized by Internet users as meaningful and secure. Having a strong online identity is a key asset for businesses, and translates to a better user experience when dealing with these businesses.

Advantages for Businesses
In addition to providing more TLD options .SHOP also provides an opportunity for business entities or organizations to register a direct, simple, and intuitive domain that corresponds to their businesses. Furthermore, this TLD will offer an additional suite of tools and services that are focused on providing .SHOP users with a safe, secure and reliable experience.
 
Since .SHOP is clear and easy to associate with commercial activities and the word “SHOP” is recognized worldwide, it allows a business to easily reach out to its target audience and market its products and services in an effective and efficient manner, thus promoting business growth.
 
Today, having an online presence is considered to be a necessity for any business. One of the crucial first steps in establishing an online presence is the selection of a TLD and domain name. In current TLDs, especially .COM, which has the most registrations and is intended for all purposes, there is a high possibility that businesses will not find the desired domain names, and be forced to find an alternative. In this case, the business has no choice but to spend more time looking for what is available and deciding which ones to register. The end result may be that the registered domain names are far from direct, simple, easy to understand, and intuitive, all of which are important qualities from a marketing perspective. The Applicant hopes that .SHOP will help reduce difficulties in securing a relevant online identity and facilitate a smooth business launch. In addition, if there is demand from registrants or registrars, the Applicant intends to provide optional supporting products (i.e. shopping cart) for new businesses and others.

Benefits for Internet Users
As stated in the previous paragraph, business entities or organizations are often obliged to use non-relevant gTLDs and ccTLDs since there is no domain that specifically identifies this community at this point. As a consequence, Internet users often have difficulty reaching the websites, information, and services they seek. The Applicant believes that .SHOP will help reduce user confusion and improve convenience for online shoppers and other Internet users since it is intuitive and self-explanatory.

Just as proliferation of smartphones and tablet-type devices contributed to what is now a ubiquitous network society, expansion of .SHOP could enhance user experience in online commerce for both the community and Internet users.

i. What is the goal of your proposed gTLD in terms of areas of specialty, service levels, or reputation?
 
Specialty
.SHOP is a domain for business entities or organizations that deploy commercial activities in an online or offline environment. The goal of .SHOP in this respect is to build a quality, meaningful, safe and secure domain name space that can be trusted to complement the inherent advantages of .SHOP: that it is direct, simple, and intuitive. The Applicant strives to achieve the following characterizations by each of the following groups of .SHOP stakeholders:

SHOP registrants: a namespace where registrants can effectively and efficiently provide information on goods and services offered.
 
Internet users: a name space where Internet users can access and interact with their target business entities or organizations in a safe and productive way, obtaining access to genuine content, products and services. The .SHOP TLD is able to contribute to reducing the sale of counterfeit and pirated goods, as registrants will be identified and remain identifiable throughout the term during which the domain name is registered in the .SHOP TLD;

For others: a TLD that contributes to growth in the industry, and hence the economy.
 
Service Levels
Aims for the service levels of .SHOP are:
 
1. Registry Operation
The Applicant aims to operate the TLD in a secure and stable manner, adopting industry best practices where applicable. The Applicant’s operational goals are to have DNS load dispersion that is resistant to DDoS attacks, industry-leading level of Whois information change and DNS record change reflection time, substantial registrar support, and abuse window operation 24 hours a day, 365 days a year. The Applicant will also implement proven security measures at every level of the registry business and technical operation to provide maximum protection for its stakeholders. This includes stringent security policies and procedures, as well as comprehensive abuse handling mechanisms to mitigate security threats to the TLD. In addition, the Applicant will strive to provide an outstanding level of technical and operational support to the registrars.
 
2. High Quality Content
In order to maintain high quality content and provide a safe .SHOP namespace for Internet users, the Applicant will develop a set of abusive use policies and takedown processes to prevent and respond to abuse in an efficient manner. In addition, the Applicant will publish an information page on its website describing recommended ways to use the TLD. The information page will include best practices for web contents and a list of prohibited activities under the TLD. The Applicant believes that the information page will help registrants understand the purpose of the TLD, preserve the characteristics of the TLD and help mitigate abusive activities.
 
Reputation
The aims for the reputations of .SHOP are:
1. to become well recognized as a TLD for commercial activities;
2. to become a namespace that Internet users appreciate for its quality, meaningfulness, pleasure, safety, stability, and truthfulness; and
3. to provide various benefits to the target community and become regarded as a contributing factor to the expansion thereof..
 

ii. What do you anticipate your proposed gTLD will add to the current space, in terms of competition, differentiation, or innovation?
 
The Applicant believes that .SHOP will promote competition, differentiation, and innovation for domain name registrants, Internet users, and business, considering that the .SHOP TLD is an Internet extension exclusively reserved for business entities or organizations that deploy commercial activities or provide information in relation thereto over the Internet.
 
However there is no TLD that is exclusively for them among the 22 gTLDs and sTLDs available for public registration. As a result, owners of related businesses are required to select domain names from the currently-available TLDs that are not necessary related to their business.
 
Unlike currently existing or new TLDs with broad interpretations, the Applicant believes that the specificity of .SHOP will be welcomed by business entities or organizations. Since .SHOP also provides compelling marketing and branding value, the Applicant anticipates that a significant number of business entities or organizations who are currently operating under domain names registered in existing TLDs will switch to using a .SHOP domain name as their primary online identity. The Applicant also anticipates new businesses will select .SHOP, given that it is the only TLD that exactly represents the nature and identity of their businesses. New businesses will also be attracted by the advantages that .SHOP offers them as stated in part (a) of this question. The Applicant expects to infuse positive competition and differentiation in the current space.
 
Furthermore, .SHOP will be an additional choice for registrars to provide to customers. However, registrars will not select TLDs that do not bring benefits in various ways to both Internet users and their businesses. In order to meet these demands, registries need to make an effort to provide quality services, business operations, system operations, pricing, customer support, and so on. It is expected that this will also promote competition and differentiation in the current space.
 
Competition and differentiation in turn will spur innovation. In the case of .SHOP, the Applicant intends to discuss ideas with registrars and introduce tools, products, and services that are effective or necessary in achieving goals and roles set forth for .SHOP. The Applicant believes that these efforts will promote innovation and lead to a better name space.
 
iii. What goals does your proposed gTLD have in terms of user experience?
 
The Applicant will endeavor to achieve the goals listed in (b).i. in this section as well as to build a namespace that Internet users are satisfied with for its meaningfulness, safety and effectiveness.
 
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 .SHOP domain name registration policies are as follows. All .SHOP TLD registrars are required to include policies and restrictions including but not limited to the following in their registration agreement with their customers to which registrants must agree and comply.
 
1. Registrant Eligibility Requirements
The Applicant intends to put in place the following eligibility requirements for registrants in .SHOP: 
In order to qualify for registering a domain name in the .SHOP TLD, the registrant must be a business entity or organization that deploys commercial activities in an online or offline environment, i.e. offering for sale and selling products or services on a more than occasional basis, or provide information in relation thereto over the Internet.
.SHOP domain name registrations will also be made available to business entities or organizations that currently do not deploy commercial activities, but that have expressed intention to engage in the activities within one year following the registration of a .SHOP domain name.

Proof of Corporation⁄Company Establishment
All .SHOP domain name registrants will be required to prove that the business entities or organizations are legally established by providing the following information at the time of domain name registration:
- Country name where the business entity or organization is established
- Business entity or organization identification number type (Business ID, Tax ID, VAT, etc.)
- Business entity or organization identification number
Furthermore, registrants that are not currently engaged but have expressed intention to deploy commercial activities in an online environment may be required to submit additional information to prove their intent, anytime during the course of the registration term and as deemed necessary by the registry.

2. Restrictions on Domain Name Strings
Registrants will be entitled to register domain names that are identical or similar to their current or future trademark, business name, trade name, business identifier, name of business entity or organization, names under which they are commonly known, slogans, acronyms, etc., including combinations thereof, in the .SHOP gTLD.

3. Usage Restrictions
The purpose of the domain name usage will be restricted as follows:
a. Registered .SHOP domain names must be used for commercial activities in an online or offline environment, or to provide information in relation thereto over the internet; or
b. Registered .SHOP domain names must be intended to be used primarily for commercial activities in an online or offline environment, or to provide information in relation thereto over the internet.
 
Registration of a .SHOP domain name solely for the purpose of selling, exchanging, trading, leasing the domain name shall be deemed as inappropriate use or intent.
 
4. Random Checks
The Applicant will conduct random checks to determine compliance with registrant eligibility, name selection, and usage restrictions (hereafter ʺeligibility requirementsʺ) using sampling methodologies. In case the Applicant determines a sampled domain is in violation of the eligibility requirements, the domain name may be deleted or placed on lock, hold, or similar status.
 
5. Draft Abusive Use Policy
The Applicant defines abuse as any activity that may harm the stability and security of the DNS and Internet, including, but not limited to:
 
- Illegal or fraudulent activities;
- Phishing;
- Pharming;
- Using or distributing malicious software (malware);
- Sending unsolicited bulk messages (spam);
- Posting, trading, or exchanging information that harms minors;
- Posting, trading, or exchanging child pornography;
- Posting information that encourages illegal acts, crimes, murders, or suicides; and
- Posting information that is offensive to public order or morals.
 
The Applicant reserves the right to deny, cancel or transfer any registration or transaction, or place any domain name on lock, hold or similar status, at its sole discretion, to enforce the policy.

In addition, the Applicant intends to set up an abuse support window (abuse report form and abuse support window) for .SHOP 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 Applicant will promptly take appropriate measures in accordance with the suspension flow provided separately (Please refer to Question 28).

6. Accuracy of Registration Information and Restriction of Whois Proxy
In order for Internet users to use the .SHOP name space with confidence, it is important that registration data associated with domain names is appropriate and accurate, and that there are not any fraudulent registrations and uses. The Applicant believes that it is important for .SHOP registrants to be identifiable, provide bona fide information, and not use their domain names in bad faith. Therefore, .SHOP registrants are obliged to provide and maintain correct, complete, and up-to-date registration information (Whois information). In addition, no Whois protection service of any kind will be permitted.

Failure to comply with this policy may result in the domain name registration being denied, cancelled, or transferred; the Applicant shall also be entitled, in such cases, to delete any such domain names, or place them on lock, hold, or similar status.
 
7. ICANN Policies
The Applicant will adopt and comply with the Uniform Rapid Suspension System, Uniform Domain Name Dispute Resolution Policy, and all other ICANN Consensus policies, regulations, and rules (the “ICANN policies”). In any case, all .SHOP domain name registration policies will apply, but nonetheless be subject to these ICANN policies.
 
8. Website Best Practices Information Page
In order to help .SHOP domain name registrants understand the purpose of the TLD, clearly publicize usage restrictions of the TLD, and encourage registrants to use .SHOP domain names in an appropriate manner, the Applicant will publish an information page on its website describing recommended ways to use .SHOP domain names. The information page is for information purposes only and will include best practices for web contents and a list of prohibited activities under the TLD.
 
All .SHOP registrars will be required to place the link to the information page on their website or include it in domain name registration⁄renewal confirmation emails sent to the registrants.
 
 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.
 
.SHOP will comply with the applicable laws of Japan, as well as applicable ICANN policies. As part of its responsibility as the registry operator of the .SHOP TLD, the Applicant will exercise due care to protect all information it receives from registrants or users through registrars, and will not disclose such information to any third party, with the exception of public Whois data.

As stated earlier, the Applicant believes that it is important that .SHOP registrants are identifiable in order to ensure registrants provide bona fide information, services, and products responsibly and do not use their domain names in bad faith. Also, the Applicant believes that Internet users gain a sense of safety and security when they have a means to access the registration information. As a consequence, as previously stated, no Whois proxy service of any kind will be allowed.
 
Describe whether and in what ways outreach and communications will help to achieve your projected benefits.
 
1. Communication with Registrars
In order to achieve the projected benefits, .SHOP must gain substantial mindshare among Internet users. The Applicant believes that the primary method of increasing recognition and registration numbers in the TLD is to gain strong support from .SHOP registrars. For that reason, the Applicant intends to:
- Maintain regular communication with registrars;
- Attend ICANN meetings and domain name⁄Internet related events and have face to face meetings with registrars; and
- Organize events for registrars
Feedback from registrars will then be taken into account and integrated into public relations and marketing activities where appropriate.
 
2. Other Outreach Activities and Communication
The Applicant believes that support from the community is also critical to achieving the projected benefits.
 
Therefore, it plans to establish communications and partnerships with related industries and their main representatives, and conduct joint promotional activities that will encourage development and growth of the industries as well as .SHOP. In addition, the Applicant will make an effort towards raising awareness of .SHOP in the relevant industries, working closely together with representatives of the community, and in particular those who have endorsed our bid for the .SHOP gTLD.

i. How will multiple applications for a particular domain name be resolved, for example, by auction or on a first-come⁄first-serve basis?
 
Multiple applications for a particular domain name for general registration will be resolved on a first-come-first-served basis as are other current gTLDs. However, multiple applications for a particular domain name during the .SHOP initial launch phase will be resolved as follows:
 
- Sunrise Registration Process: Auction
- Landrush Process: Auction

ii. Explain any cost benefits for registrants you intend to implement (e.g., advantageous pricing, introductory discounts, bulk registration discounts).
 
The Applicant intends to price .SHOP in a range reasonable enough to ensure it is universally accessible but not so low that it risks damaging its value as a TLD.
 
In order to encourage new registrations and renewals of .SHOP domain names, the Applicant will run campaigns or rebate programs from time to time. The Applicant believes it is important to run campaigns that meet the needs of registrars; therefore, it will exchange opinions with registrars and make an effort to run campaigns that reflect registrars’ needs. The Applicant promises equal treatment for all .SHOP registrars.
 
The planned campaigns⁄rebate programs are as follows:
 
New Registration Promotion
This is a promotion that provides discounts on first year registration fees of new domain names registered during a predetermined period. The discount will be provided in the form of a rebate credit to the registrar’s account at the end of the campaign period. Registrars interested in the promotion will need to sign up and may be required to deliver the benefit to registrants in some way (i.e. provide registrants with discounts on new registrations).
 
Bulk Registration Rebate Program
This is a promotion that provides a volume discount on the first year registration fee of new domain names registered during a predetermined period. The amount of rebate will depend on the volume of the new registrations made during the campaign. The discount will be provided in the form of a rebate credit to the registrar’s account, at the end of the campaign period. Registrars interested in the promotion will need to sign up.
 
Co-Marketing Program
This program is aimed at expanding recognition of the TLD whereby the Applicant will bear part of the marketing cost of promotions relating to the TLD, conducted by registrars. All registrars interested in the program will be required to sign up and discuss details of the marketing plan in advance with the Applicant.
 
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 .SHOP 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 Applicant will provide an advance written notice of price increases as required by the Registry Agreement. The Applicant does not intend to make contractual commitments to registrants regarding price escalation.

Yes

As is the case with any community, “membership” is based on common features, characteristics, activities, interests, etc.
The target community for .SHOP is business entities or organizations that deploy commercial activities in an online or offline environment or provide information in relation thereto over the Internet. Their common goal is to sell products and services to third parties, using the Internet as a direct or indirect sales channel.
However, with differences of experience, types of products and services, and conditions related to the purchase thereof, the way ebusinesses attempt to achieve such goals differs from that of brick-and-mortar stores.
Under .SHOP, only those who engage or intend to engage in commercial activities qualify to register domain names, if they meet requirements that – once finalized – will be laid down by the Applicant. Key features of the policy are described below.
COMMUNITY NAME
The target community does not have one “name”, members have several common characteristics and features, and their activities (and industry) are generally referred to as “online shopping”, “ecommerce”, “ebusiness”, etc.
DELINEATION
Community members, as opposed to Internet users generally, are business entities or organizations that deploy commercial activities in an online or offline environment or provide information in relation thereto on the Internet. In brief, Internet users in general are mainly on the demand side: generally seeking information about products or services, or purchasing them online. The intended registrants for .SHOP are always (but not necessarily only) on the supply side.
Although it is a broad and heterogeneous community not defined by any geographical borders, limited to certain cultures or form of trade, the community can be delineated more specifically as follows:
- community members deploy commercial activities with a certain continuity, whereas most Internet users only sporadically engage in commercial transactions, mainly as buyers (demand side);
- in some countries, to deploy commercial activities, registration with an official register is required prior to or shortly after engaging in such activities; and, in some countries, a VAT or sales tax number, or equivalent thereof is also required;
- those engaging in ecommerce related activities have 1 or more websites on which they offer products or services etc. Internet users in general do not usually have transactional websites, and use the Internet only for trading in their own name and for their own purpose. Also, generally, Internet users are not engaged in marketing activities or promotional campaigns for products or services;
- in some countries, specific commercial activities are regulated by an official or non-official body. These activities are not organized by Internet users in general, although they can benefit from this supervision, regulations and soft-law.
STRUCTURE AND ORGANIZATION
There is no worldwide coordinating body representing the entire community, though there are organizations and associations related to the industry at regional, national, state, and city levels, such as Chambers of Commerce, professional employer organizations, etc. The targeted community members are globally distributed, with organized activities undertaken by various organizations, stakeholder groups, etc.
Globally, various organizations represent the interests of businesses, including the International Chamber of Commerce (ICC), Business Europe, the International Fair Trade Association, etc. On a national or regional level, community members are organizing themselves in an attempt to promote use of the Internet in commercial activities, and establish trust in ecommerce.
DATE(S) OF FORMAL ORGANIZATION, IF ANY, AS WELL AS A DESCRIPTION OF COMMUNITY ACTIVITIES
Community activities include, but are not limited to, buying, selling, exchanging, trading and leasing of goods, services, information, or any other property on the Internet, or activities of a similar nature. Since the community is not represented by a single organization, there is no one establishment date.
REPRESENTATIVES OF THE COMMUNITY WHO HAVE ENDORSED THIS APPLICATION INCLUDE:
- European Multi-channel and Online Trade Association (EMOTA), an organization that represents, at European and international level, the interests of ecommerce companies and retailers interacting with customers through all distance sales channels - websites, call centers, direct mail, catalogues, TV etc. EMOTA was founded under Belgian law in May 1982, however it developed out of AEVPC (Association Européenne de Vente par Correspondence) which was already in existence in 1971. EMOTA speaks for organizations generating over a third of a trillion US dollars in annual online trade. It works closely with the European Commission and national governments and is continually consulted in areas of, ecommerce Governance and Self Regulation, Industry Data, Codes of Best Practice, Dispute Resolution, Investment, Trading Standards and Cross Border issues. The 15 countries directly represented are Austria, Czech Republic, Finland, Germany, Greece, Hungary, Italy, Portugal, Romania, Russia, Slovakia, Spain, Sweden, Switzerland and the United Kingdom.
http:⁄⁄.www.emota.eu⁄
- Belgian Digital Marketing Association, an organization established in January 2003 in conjunction with Safeshops.be;
http:⁄⁄www.bdma.be⁄
http:⁄⁄www.safeshops.be⁄
- EC Network, an organization established in April 2006;
http:⁄⁄www.ecnetwork.jp⁄en⁄
- Japan Foundation for Electronic Commerce (JFEC), an organization originally established as Electronic Commerce Conference (ECC) in 2003. After the inception of the Act on Authorization of Public Interest Incorporated Associations and Public Interest Incorporated Foundations in 2008, ECC became JFEC in January 2009.
http:⁄⁄www.j-fec.or.jp⁄
- Japan E-commerce Conference (JECC), an organization established in July 2004;
http:⁄⁄www.jecc.or.jp⁄
THE CURRENT ESTIMATED SIZE OF THE COMMUNITY, BOTH AS TO MEMBERSHIP AND GEOGRAPHIC EXTENT.
Given its nature, it is difficult to demonstrate community size: statistics vary from hundreds of thousands to millions of entities who sell products and services using the Internet. On a daily basis, new businesses appear, and existing merchants go out of business. However, there are strong reasons to believe that the net result will be positive.
Nonetheless, more insights exist into the number of potential beneficiaries of a dedicated, safe, secure and trustworthy .SHOP namespace:
According to a recent report by EURid, the registry operator for .EU, 26.5% of domain names in their sample pointed to websites used for business purposes. The authors of the Report analyzed 50,000 websites randomly selected across 11 TLDs, and classified these in 8 categories; “Business”, “Community”, “Institutional”, “Holding Page”, “Pornography”, “Error”, “Pay-per-Click”, and “Password Protected”.
According to the Report, a business website is “a website that clearly shows commercial activity and that is designed for customer interaction. Business websites provide information about the company, including contact details, company structure, and descriptions of products or services. Some also allow customers to shop online.”
If we extrapolate this result to the total number of domain names registered in the world, and conservatively estimate the number of community members, the result is that currently about 40-50 million websites exist with commercial characteristics.
According to World Retail Data and Statistics 6th Edition (ISBN: 978-1-84264-530-7) published by Euromonitor International Ltd, Per Household Internet Retail Sales between 2004 to 2009 grew by 175% in USA, 363% in France, and 686% in Brazil. From members of the G8 to the less developed countries, per household Internet retail sales in every country grew betw

- Relations to any community organizations and relations to the community and its Constituent parts⁄groups.
The applicant is a subsidiary of GMO Internet, Inc. (“GMO” – listed on the first section of the Tokyo Stock Exchange [9449]), and member of the GMO Internet Group with headquarters in Tokyo, Japan. GMO has always been a leading force in the Internet industry offering one of the most comprehensive ranges of Internet services worldwide. Its business operations offer a one-stop suite of web business solution services that include domain name registration, web hosting, web design, Internet security, ecommerce tools, and payment processing.
More than 700,000 members of the target community in Japan are already using business solutions offered by GMO. These services include ecommerce solution services, payment systems and gateways, hosting, and online security-related services including Security Socket Layer (SSL).
The applicant has proposed its .SHOP initiative to various organizations referred to previously, and has obtained various letters of endorsement and support for this initiative.
- Accountability mechanisms of the applicant to the community.
The Applicant has and will continue to reach out to various international, regional and national organizations that represent the interests of the targeted community, in particular if and when ICANN awards the .SHOP gTLD to the applicant. Following delegation, the applicant will devise clear policies together with some of these organizations that represent the community in a way that would benefit the members and their interests.
The Applicant will publish a charter containing self-imposed rules and guidelines with respect to the operation of the .SHOP TLD.
Also, with respect to the .SHOP initiative, the Applicant will set up a policy advisory committee, in which representatives of the targeted community can, together with representatives of the registry operator, develop new policies in relation to the operation of the .SHOP TLD. Expressions of interest for becoming a member of such a committee have already been received by the Applicant.
Furthermore, the Applicant will set up an oversight committee, comprising representatives of the targeted community, who will formulate recommendations with respect to the positioning, marketing and operation of the TLD.

The main purpose of applying for the TLD as a community-based application is to establish a clear, unambiguous and easy to remember online identity for the community and promote a defined, meaningful, and secure namespace in order to contribute to the further development of the community and the (commercial) activities of its members.
Therefore, the community-based character of the .SHOP TLD is closely linked to the requirements ICANN has defined in the Applicant Guidebook for community-based applications:
1) commitment from the Registry Operator to abide by the rules established with the assistance and support of the community and its representatives including European Multi-channel and Online Trade Association (EMOTA) and other industry associations;
2) establishment of eligibility requirements for .SHOP domain name registrants and establishment of usage, name selection and WHOIS accuracy requirements, in order to establish trust between the registrants and consumers;
3) support from various members of the community, who intend to use the .SHOP TLD as a platform that is based on international standards where they can engage with consumers.
In this respect, the .SHOP gTLD will have a number of benefits, not only for registrants, but also for the users of .SHOP websites.
First, it is not only in the common interest of the targeted registrants, but for the Internet community at large to have a safe, secure and reliable namespace within which they can engage in commercial transactions.
Second, the technical infrastructure of the .SHOP registry, as well as the terms and conditions that will govern the registration and use of .SHOP domain names will encourage and support the establishment of relationships that are based on trust (Whois review, verification of eligibility requirements, security tools and methodologies, etc.).
● Intended registrants in the TLD:
The intended registrants in the .SHOP TLD are business entities or organizations that deploy commercial activities in an online or offline environment or provide information in relation thereto over the internet.
Basically, the intended registrants are business entities or organizations on the supply side of commerce.
● Intended end-users of the TLD:
The end-users of .SHOP domain names are any individual, business entity or organization that is looking for trustworthy and genuine information, products and services on the Internet.
These individuals, business entities or organizations are generally on the demand side.
● Related activities the applicant has carried out or intends to carry out in service of this purpose:
The Applicant provides backend operation for the .SO and .ID ccTLDs and makes every effort to ensure a safe and secure namespace. Also, GMO has been serving the ecommerce community in Japan and other countries since the dawn of the industry. The group provides all the tools required to operate on the Internet including domain names and web hosting services as well as tools specifically required to operate online stores including shopping carts, payment gateway solutions and SSL security. The Group strives to achieve the same mission and objectives through the provision of these services.
● Explanation of how the purpose is of a lasting nature
Any current or future Internet user will have a genuine interest in having a safe and secure experience when browsing for information, products or services online. The Applicant will encourage usage of .SHOP in ways that support a safe, secure and trustworthy experience for Internet users when looking for genuine information, products and services, by imposing detailed guidelines and policies upon domain name registrants, and offering tools, methodologies and techniques.
The community that .SHOP will serve engages in activities such as retail, trading and commerce, which are basic activities that transcend societies, cultures, and time. Both the online and physical forms of such activities are expected to last, or even experience a significant growth, into the foreseeable future.
Commerce and business activities are a major driving force in the growth and evolution of the Internet. As Internet users grow more reliant on the Internet to conduct business and commerce, and as businesses increase their online offering in order to harness the benefits of the Internet and to augment their physical counterpart, the role that .SHOP plays in the ecosystem will be ever more important.

● relationship to the established name, if any, of the community
The word “SHOP” has many meanings.
First of all, it is a commonplace word for a location – in the real or virtual world – where commercial activities are deployed, products or services are offered for sale and can be bought. Therefore, it is the shortest and most appropriate term that encompasses the community of shopkeepers, big or small, and its pursuits.
Furthermore, the verb “to shop” or the word “shopping” is defined as the examining of goods or services with the intent to purchase at that time (source: http:⁄⁄www.merriam-webster.com⁄).
Finally, although the word “SHOP” originates from English, it has at least one of the above connotations in many languages around the world.
So, the word “SHOP” is clear, unambiguous, and describes both:
- the business entities or organizations offering information, products and services in its online or brick-and-mortar shop; and
- the activity carried out when looking for products and services with the intent to purchase them.
● relationship to the identification of community members
The target community of the .SHOP gTLD consists of business entities or organizations that conduct retail business or trade in an online or physical environment.
The applied-for string, “SHOP”, is – as explained above – a common generic term used for identifying the physical or virtual place of business operated by the community members. In modern usage, the term represents both place of business (i.e. shop) and the businesses operating them.
In addition, many businesses have adopted the term “shop” as part of their business names, e.g. “The Body Shop”.
As a consequence, the applied-for string and the identification of community members are identical.
● any connotation the string may have beyond the community
The string has no other known connotation that is unrelated to the purpose or mission of this gTLD, as described in response to Question 18. The word “shop” is used in many languages all over the world, and has the same connotation in each of these.

● Eligibility: who is eligible to register a second-level name in the gTLD, and how will eligibility be determined.
Registrants in the .SHOP gTLD will include the following:
- business entities or organizations that deploy commercial activities in an online or offline environment or provide information in relation thereto over the internet, including, but not limited to, merchants, retailers, business-to-business sales channels, marketplaces, etc.;
.SHOP domain name registrations will also be made available to business entities or organizations that currently do not deploy commercial activities, but that have expressed intention to engage in these activities within one year following the registration of a .SHOP domain name.
Therefore, the Applicant – when awarded the gTLD – will develop detailed guidelines and restrictions in regard to the use of a gTLD, and an Abusive Use Policy.
All .SHOP domain name registrants will be required to prove that they are legally established business entities or organizations by providing the following information at the time of domain name registration:
- Country name where the business entity or organization is established
- Business entity or organization identification number type (Business ID, Tax ID, VAT, etc.)
- Business entity or organization identification number
Furthermore, the registry operator, accredited registrars and registrants will be bound by applicable ICANN policies.
● Name selection: what types of second-level names may be registered in the gTLD
Registrants will be entitled to register domain names that are identical or similar to their current or future trademark, business name, trade name, business identifier, name of business entity or organization, names under which they are commonly known, slogans, acronyms, etc., including combinations thereof, in the .SHOP gTLD.
The Registry Operator will also make available certain premium domain names, which correspond to a generic word or product or service category. These premium domain names may be retained by the registry operator, leased or rented, or offered for registration to eligible members of the community.
Insofar and to the extent such premium domain names are registered in the name of the registry operator, these domain names will be used in order to generate additional platforms for community members. Such platforms may include but are not necessarily limited to directory services, social media platforms, and search engines, all intending to drive additional Internet traffic to the active websites resolving from a .SHOP domain name registration.
● Content and Use: what restrictions, if any, the registry operator will impose on how a registrant may use its registered name
The registry operator will impose the following restrictions for the use of domain names:
a. Registered .SHOP domain names must be used for commercial activities in an online or offline environment or to provide information in relation thereto over the internet; or
b. Registered .SHOP domain names must be intended to be used for commercial activities in an online or offline environment or to provide information in relation thereto over the internet.
Registering a .SHOP domain name solely for the purpose of selling, exchanging, trading, or leasing such domain name shall be deemed as inappropriate use or intent, and will be prohibited by the registry operator.
● Enforcement: what investigation practices and mechanisms exist to enforce the policies above, what resources are allocated for enforcement, and what appeal mechanisms are available to registrants
The registry operator will encourage domain name registrants to use digital certificates in conjunction with the websites deployed under their .SHOP domain name registrations.
In addition, the registry operator will conduct on a regular basis compliance checks to ascertain whether .SHOP registrants are acting in compliance with the registry operator’s policies.
Any such checks may be carried out by using sampling methodologies, thorough ex officio investigations, Whois accuracy requests, etc.
If the Registry Operator or a third party that it appoints for this purpose determines that a registered domain name or the content violates the policies mentioned hereunder, the Registry Operator or its appointee may do any of the following:
- depending on the nature of the domain name registrant’s noncompliance, the Registry Operator may provide the registrant, directly or through the registrar, with a grace period within which the registrant needs to demonstrate that registration and⁄or use of the domain name is compliant with the policies, and that the breach has been cured; and⁄or
- if it appears that the registrant’s breach may have significant consequences for the Internet, Registry Operator, the credibility or integrity of the .SHOP gTLD, the community, or the reputation of the Registry Operator and⁄or the extension, the Registry Operator may immediately suspend, block, revoke and⁄or delete the domain name(s) registered in the name of the registrant.
Please refer to Question 28 for a more detailed description of the takedown procedure.
In this respect, the Abuse Public Contact that will be established by the registry operator will play a pivotal role:
- first, the Abuse Public Contact will be the primary addressee of any complaints made in relation to a .SHOP domain name registration; of course, its intervention is without prejudice to procedures that can be initiated by a complainant under ICANN’s Consensus Policies as well as those developed in the context of the Applicant Guidebook;
- second, the Abuse Public Contact can play a moderating role in disputes between a .SHOP domain name registrant and an Internet user as regards the registrant’s compliance with the policies set by the registry operator;
- third, the Abuse Public Contact may carry out ex officio investigations in order to ensure registrant compliance with the policies that have been devised by the registry operator.
In addition to the above, the Applicant will also endeavor to facilitate resolution of conflict between consumers on the one hand
and .SHOP registrants on the other hand in relation to products or services purchased by such consumers with the registrant.
The Applicant may register certain names (for example geographic names) in the name of the government bodies or alternative dispute resolution agencies that are competent to decide upon disputes in relation to distance selling.
Therefore, for instance, a consumer residing in Australia and buying a product from a .SHOP registrant residing in the United States is able
to file a complaint with the competent authority in the US from within the .SHOP namespace.
Please refer to Question 22 for more details in this respect, in particular regarding the Applicant’s compliance with Specification 5 of the Registry Agreement.

Not Available

No

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

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

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

In the interest of protecting consumers and the .SHOP reputation, the Applicant will also endeavor to facilitate resolution of conflict between consumers on the one hand
and .SHOP registrants on the other hand in relation to products or services purchased by such consumers with the registrant. This is achieved by providing a consistent and easily discoverable website where consumers can file complaints. The Applicant may register certain names (for example geographic names) in the name of the government bodies or alternative dispute resolution agencies that are competent to decide upon disputes in relation to distance selling. 

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

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

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 .shop. GMO Registry (the 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 SNS@ISC service to provide a high performance, resilient and standards compliant worldwide IPv4+IPv6-anycast DNS resolution network.

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

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 .shop 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 .shop will utilize less than 35% of the infrastructure capacity reserved for .shop 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.

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

3.3.5. Company Information Extension

The .shop policies require registrants to provide information pertaining to the company or corporate entity associated to each domain registration. GMO Registry has developed an extension in support of the policy. A draft of the specification is attached as “q25_draft-sabadello-epp-companyinformation-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

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 (the 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.shop, 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.

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 .shop 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.

In order to safeguard the security and stability of .SHOP TLD, as well as the Internet at large, GMO Registry, Inc. (the Applicant) takes abuse very seriously and employs proactive measures to mitigate abusive activities.

In general, the Applicant’s abuse mitigation strategies fall into the following broad areas:
- developing and publishing a set of registration policies and enforcement mechanisms;
- developing and publishing a set of comprehensive abuse policies including clear definitions of abusive activities;
- establishing and publishing a single abuse Point of Contact to address and resolve abuse complaints at registry startup and on an ongoing basis;
- developing procedures for handling abuse complaints, including takedown requests, in a timely manner; and
- publishing Website Best Practices Information Page to introduce website best practices and prohibited activities under the TLD

REGISTRATION POLICIES
In order to mitigate abusive activities and maintain a secure namespace, the Applicant intends to put in place the following .SHOP registration policies:

REGISTRANT ELIGIBILITY REQUIREMENTS
.SHOP domain name registration will be made available to:
- A business entity or organization that deploys commercial activities in an online or offline environment or provides information in relation thereto over the internet; or

.SHOP domain name registrations will also be made available to business entities or organizations that currently do not deploy commercial activities, but that have expressed intention to engage in these activities within one year following the registration of a .SHOP domain name.

PROOF OF CORPORATION⁄COMPANY ESTABLISHMENT
All .SHOP domain name registrants will be required to prove that the business entities or organizations are legally established by providing the following information at the time of domain name registration:
- Country name where the business entity or organization is established
- Business entity or organization identification number type (Business ID, Tax ID, VAT, etc.)
- Business entity or organization identification number

RESTRICTIONS ON DOMAIN NAME STRINGS
Registrants will be entitled to register domain names that are identical or similar to their current or future trademark, business name, trade name, business identifier, company name, names under which they are commonly known, slogans, acronyms, etc., including combinations thereof, in the .SHOP gTLD.

USAGE RESTRICTIONS
The purpose of the domain name usage will be restricted as follows:
- Registered .SHOP domain names must be used for commercial activities in an online or offline environment or to provide information in relation thereto over the internet; or
- Registered .SHOP domain names must be intended to be used for commercial activities in an online or offline environment or to provide information in relation thereto over the internet.

Registration of a .SHOP domain name solely for the purpose of selling, exchanging, trading, leasing the domain name shall be deemed as inappropriate use or intent.
Please refer to Question 18 for more details in Usage Restrictions.


ENFORCEMENT MECHANISMS
The Applicant will conduct random checks to determine compliance with registrant eligibility, name selection, and usage restrictions (hereafter “eligibility requirements”) using sampling methodologies. In case the registry determines a sampled domain is in violation of the eligibility requirements, the domain name may be deleted or placed on lock, hold, or similar status.

DRAFT ABUSIVE USE POLICY
The Applicant defines abuse as any activity that may harm the stability and security of the DNS and Internet, including, but not limited to:

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

The Applicant reserves the right to deny, cancel or transfer any registration or transaction, or place any domain name on lock, hold or similar status, at its sole discretion, to enforce the policy.

ABUSE PUBLIC CONTACT INFORMATION
In order to comply with the Specification 6.4.1 of New gTLD Agreement, the Application will provide to ICANN its Abuse contact details. The information will include a valid email and mailing address and a primary contact, and the Applicant will promptly provide to ICANN a notice of any changes to the contact.

Also, the Applicant will also publish its abuse public contact information on its web site when it publicly releases the .SHOP domain name registration policies. The abuse public contact will be responsible for handling complaints concerning abusive activities relating to domains registered under the .SHOP 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 email 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 Applicant 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.
- Normal: open a ticket to inform the sponsoring registrar to take corrective actions. The registrar must inform the registry of actions taken. If the registrar does not take any action (that includes no response from the registrar) within a reasonable timeframe, the registry will suspend the domain name in question and close the complaint ticket.
 If the domain name was suspended by the registry, and the situation is remedied by the registrant, the registrar will contact the registry via the ticket number. 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 Applicant 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 Applicant 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 Applicant 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.

WEBSITE BEST PRACTICES INFORMATION PAGE
In order to ensure a high quality .SHOP namespace, the Applicant believes that it is important to mitigate abusive activities on websites.

In addition to the mitigation mechanism described above, the Applicant will publish an information page on its website. The information page will include a list of prohibited activities under the TLD as well as best practices for web contents. The Applicant believes that the information page will help registrants understand the purpose of the TLD, clearly publicize usage restrictions of the TLD, and help mitigate abusive activities.

ORPHAN GLUE RECORDS
The Applicant’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 Applicant 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 Applicant 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

Please refer to Question 31 for the overall FTE equivalent resources available to GMO Registry during the initial implementation and ongoing operations of the registry, of which abuse handlings a subset. Please note some of these roles will be included in outsourced functions. 

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
 Please note some of these roles will be included in outsourced functions. 

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

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

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


SUNRISE REGISTRATION PROCESS
Before any registration of .SHOP domain name registration processing starts, Sunrise registration process using the Trademark Clearinghouse required by ICANN will be available for trademark holders.

The Applicant will establish and publish a set of Sunrise Eligibility Requirements (SERs) and adopt a Sunrise Dispute Resolution Policy (SDRP). SERs and SDRP will be applicable to all .SHOP domain names registered during the Sunrise Registration and all .SHOP 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),” .SHOP 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 “shop⁄shops”, 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 Applicant 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 by auction 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 .SHOP 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 Applicant 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 .SHOP 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 .SHOP domain name registrations and all .SHOP 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 Applicant sets forth the Abusive Use Policy to minimize abusive activities. Not all abusive activities necessarily affect rights but some abusive activities do affect the rights when the activities are in conjunction with abusive registrations. A description of the policy and takedown procedure is provided in Question 28.

WEBSITE BEST PRACTICES INFORMATION PAGE
In order to ensure a high quality .SHOP namespace, the Applicant believes that it is important to mitigate abusive activities on websites.

In addition to the mitigation mechanism described above, the Applicant will publish an information page on its website. The information page will include a list of prohibited activities under the TLD as well as best practices for web contents. The Applicant believes that the information page will help registrants understand the purpose of the TLD, clearly publicize usage restrictions of the TLD, and help mitigate abusive activities.

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

Please refer to Question 31 for the overall FTE equivalent resources available to GMO Registry during 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

1. Overview

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 .shop.

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.

.shop, as a generic top level domain with broad appeal, 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.