New gTLD Application Submitted to ICANN by: JCB Co., Ltd.

Application Downloaded On: 05 Sep 2014

String: jcb

Application ID: 1-1806-69861

Applicant Information

1. Full legal name
JCB Co., Ltd.

2. Address of the principal place of business
Aoyama Rise Square 5-1-22 Minami Aoyama Minato-ku, Tokyo - 107-8686 JP

3. Phone number
+81 3 5778 8369

4. Fax number
+81 3 5778 7925

5. If applicable, website or URL
http://www.jcbcorporate.com

Primary Contact

6(a). Name
Yuji Yamada

6(b). Title
Senior Vice President

6(c). Address

6(d). Phone Number
+81 3 5778 8369

6(e). Fax Number
+81 3 5778 7925

6(f). Email Address
yuji.yamada@jcb.co.jp

Secondary Contact

7(a). Name
Aiko Shiroma

7(b). Title
Assistant Vice President

7(c). Address

7(d). Phone Number
+81 3 5778 8369

7(e). Fax Number
+81 3 5778 7925

7(f). Email Address
aiko.shiroma@jcb.co.jp

Proof of Legal Establishment

8(a). Legal form of the Applicant
Corporation

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

8(c). Attach evidence of the applicant's establishment.
Attachments are not displayed on this form.

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

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

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

Applicant Background

11(a). Name(s) and position(s) of all directors
Name
Position
Atsushi MurakamiBoard Member
Hiroshi AketaBoard Member, Senior Executive Officer
Hiroyuki OkutaniBoard Member
Koremitsu SannomiyaBoard Member, Senior Executive Officer
Naoki MatsumotoDeputy President
Nobuaki TanakaBoard Member, Senior Executive Officer
Takao KawanishiPresident & Chief Executive Officer
Takuo SasakiBoard Member
Toshinori OdaBoard Member, Senior Executive Officer
Tsuyoshi HamaguchiBoard Member, Senior Executive Officer

11(b). Name(s) and position(s) of all officers and partners
Name
Position
Naoki MatsumotoDeputy President
Takao KawanishiPresident & Chief Executive Officer

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

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

Applied-for gTLD string

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


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



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



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



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



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



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



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



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



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



15C. List any variants to the applied-for gTLD string according to the relevant IDN tables.



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

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

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

Due to the positive results of these checks, JCB Co., Ltd. does not believe that the .jcb gTLD will be subject to any operational or rendering problems.


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



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

The mission and purpose of the new restricted .jcb gTLD is to benefit internet users by ensuring increased trust and confidence through the elimination of user confusion and assurance of brand authenticity, free from false impersonation of third parties.

The new .jcb gTLD will operate as a restricted registry, in which JCB Co., Ltd. (JCB) can create and control domain spaces that promote its brand identity, authenticity and online presence. In this regard, the .jcb gTLD will be used by JCB to provide accurate information, unique high quality services and resources to consumers in a way that promotes a sense of security, a user-friendly address structure, brand credibility and utility. The .jcb gTLD will provide an authoritative internet space for JCB, accessible via an intuitive and catchy address. Second and third level domains can then be utilized to provide geographically relevant content, information and unique services, with internet users assured of brand authenticity.

JCB was established in 1961 and is the only international credit card company based in Asia, with its headquarters in Tokyo, Japan. JCB established dominance over the Japanese credit card market in 1968 and has been a Japanese top brand for over 50 years. JCB has been pursuing independent expansion since 1981 to make the JCB brand an internationally accepted global brand. JCB currently has over 61 million card members, of those approximately 9.75 million customers are using JCB cards issued in countries and areas outside of Japan. Over 20 million merchants worldwide across 190 countries and territories, representing a wide range of businesses, accept JCB credit cards, offering endless possibilities to JCB card holders. JCB has over 2,500 employees with a net revenue of USD 2,609 million and a profit of USD 304 million (as at September 2011) as well as an annual turnover of 9,662 billion Yen for the 2010 financial year. At the 64th ʺDent Su Advertising Awardsʺ for lifestyle and culture for both Newspaper Advertising and Television Advertising, JCB has won Outstanding Awards. The winners were selected from a total of 2,081 entries.

As JCB intends to proactively develop consumer trust and the credibility of its brand, continuous innovation and consumer confidence are paramount considerations in all its activities.

Since the inception of the current domain name system, business activities conducted on the internet are constantly changing and evolving with increased complexity. The volume of commercial transactions over the internet is constantly growing and bringing benefits of simplicity and lowered transaction costs to businesses and consumers. However, at the same time, criminal activities over the internet including data breach, hacking and phishing activities have also become more sophisticated resulting in loss of consumer confidence beyond mere monetary harm. The .jcb gTLD will facilitate greater trust and assurance from internet users connecting with JCB online and will provide a sense of security free from false impersonation by third parties, whilst still allowing convenient and efficient interaction.

JCBʹs mission and purpose of the proposed new gTLD share ICANNʹs initiatives to promote public interest. JCB is committed to contribute towards achieving such initiatives in line with ICANNʹs Affirmation of Commitments, which includes:

- consumer trust: the .jcb gTLD registry will be operated in a centralized manner with a restrictive registration policy. Registration of domain names will only be available to JCB, at this stage, which will provide added consumer trust that .jcb domain names are trustworthy and secure. As .jcb domain names are subject to registration standards, policies and procedures under JCBʹs control, this eliminates the possibility of malicious conduct within the .jcb domain space;

- competition: the proposed new gTLD is not intended to instigate competition and consumer choice at the level of registration of domain names among prospective registrants. Instead it is anticipated to contribute to ICANNʹs initiatives to promote public interest through its operation focused on promoting consumer trust. Increased trust in the .jcb gTLD will drive existing and new top level domain (TLD) registry operators to make improvements in mechanisms to improve consumer trust of their TLDs; and

- consumer choice: the proposed new gTLD will provide internet users with a wider range of choices with economic transaction costs. .jcb will also enable user-driven improvements and innovations assisting JCBʹs marketing efforts through its ability to create new second and third level domain names on demand. These names will provide the consumers with more choices for interacting with JCB online. As JCB has effective control over the registration and use of domain names under .jcb domain space, this will also contribute towards general service innovations on the internet.

Given the restricted nature of the .jcb gTLD, the projected number of registration is likely to be limited. It is anticipated that a more limited number of domain names (up to 50) will be registered in the first year. However, over the next few years, the number of registrations is likely to increase to 150 to 300 domain names as JCB develops and implements new services and marketing campaigns.

JCB intends to create relevant domain names for use including product, services or geographic names in the second or third level domain names. In accordance with registration policy and the proposed measures for protection of geographic names as outlined in response to Question 22, JCB will use geographic names to localize its websites in Japan and the countries in which JCB has presence and⁄or representation. The use of geographic names is intended to:
- connect internet users with relevant information as applicable to the territory; and
- comply with required rules and regulations in the national territory.

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

JCB is a well-recognized global brand with its ʺJCBʺ trademarks and trademarks including the term ʺJCBʺ (222 in total ) registered in 18 countries and categories covering JCBʹs credit card business as its core business, including classes 36 (insurance, financial affairs, monetary affairs) and 35 (advertising, business management, business administration, office functions).
Further, JCB has existing domain names in the following spaces:
- gTLDs: jcbcard.com
- country-code TLDs (ccTLDs): jcb-card.jp, jcb-eit.jp, jcb.co.jp, jcb.tw, jcbcard.cn, jcb-card.jp, jcbcards.jp, jcbcard.kr, jcbtravel.co.jp

Recently, JCB was successful in securing sunrise application for the following domain spaces based on existing trademark registration: .asia, .xxx

JCB believes that the .jcb gTLD is unlikely to cause confusion with either a generic term or any existing TLDs. JCB has over 200 trademarks registered and has been a top credit card brand for over 50 years with a strong global reputation with over 70 million card members and over 20 million merchants worldwide accepting JCB credit cards. JCB has used the term ʺJCBʺ in conjunction with its credit card business since its establishment, as such, JCB is a well-established global credit card company with a strong reputation.


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

18(b)i.
The key goals of the proposed new .jcb gTLD are in line with ICANNʹs Affirmation of Commitments: to promote consumer trust, competition and consumer choice. JCB also seeks to foster its online reputation and provide an authoritative internet space through which JCB is able to communicate with its customers directly and effectively. JCB aims to achieve ʺSpiral Growthʺ which will develop various business functions and value-added services within JCB and will provide unique value to consumers worldwide. The ability to create domain names on demand related to specific marketing, specialty service and product development supports these goals. Strengthened security measures, service levels and more effective functionality will provide a trusted and positive user experience.


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

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

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

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


18(b)iii.
The proposed .jcb gTLD will provide a positive user experience, which meets the changing and growing needs of the global internet community. JCB will maintain control in the registration and use of domain names and will ensure that the new gTLD will only be used for purposes authorized by JCB. Therefore, .jcb gTLD will:
- provide an easy and intuitive reference and easy access point for internet users;
- represent authenticity thus promoting user confidence and security;
- direct internet users to relevant information in a timely manner by creating domain names on demand;
- use IDNs to enable customers to interact directly in their native language;
- use geographic names to localize its websites to connect with internet users in the relevant regions and to comply with local laws;
- enhance security and minimize security risks by implementing necessary technical and policy measures;
- strengthen brand reputation, brand image and user confidence by eliminating user confusion; and
- prevent potential abuses in the registration process reducing overall costs to businesses and users.

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


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

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


18(b)v.
JCB is committed to protection of privacy and confidential information in accordance with its objective of increasing consumer trust and providing a safe and legitimate internet space for internet users. Privacy and confidential information will be protected in accordance with all applicable laws and regulations relating to internet security, privacy and userʹs confidential information such as compliance with the Private Information Protection Law (Japan). JCB is also compliant with industrial standards managed by the ʺJapan Credit Information Reference Center Corp.ʺ(JICC) and the ʺCredit Information Centreʺ(CIC). JCB also has implemented internal policies governing its collection, use, disclosure and handling of personal information relating to its credit card business.

Privacy is of fundamental concern to most of JCBʹs customers as such JCB has a strong interest in ensuring a high level of privacy protection for its customers

JCB also has implemented its own privacy policy to demonstrate its commitment to the protection of user privacy and confidential information. JCBʹs personal information protection policy informs internet users regarding the collection, use and provision of personal information in which JCB:
- collects personal information by way of legally compliant and appropriate methods;
- uses and provides personal information only for the purposes specified when the data is collected;
- will not disclose personal information to any third party without the prior consent of the concerned user, unless compelled by law.

JCB also responds in good faith to requests for access, modification and deletion of personal information at the request of the relevant user.

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

JCB will deploy Domain Name System Security Extensions (DNSSEC) which is intended to benefit both JCB and its users interacting with JCB online. DNSSEC provides additional security by validating information in the transmission, therefore it is intended to benefit those who publish information in the domain name system (DNS) and the users who retrieve information from the new .jcb gTLD. JCB already implements systematic and operational security measures to protect privacy or confidential information of its users against misuse, loss, alteration and unauthorized access, in which:
- only authorized managers and employees can access personal information;
- personal information is collected and used only when required to provide service and manage business;
- when giving access to information to a third party service provider (with consent from its users), JCB confirms that the company handles personal information in compliance with JCBʹs standards and monitors compliance; and
- JCB revises or deletes incorrect personal information as soon as it is discovered.

JCB has also implemented security measures such as the use of Secure Sockets Layers (SSL), firewall and password.

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


18(b)vi.
The proposed new gTLD will be publicized by a media plan to promote recognition of the new gTLD within the internet community to be a trusted site and as a sign of authenticity.

During the initial stage of the operation of the proposed new gTLD, it is anticipated that internet users will be re-directed to current websites. However, over time, it is foreseen that communication to the internet community of the existence of the proposed new gTLD and encouragement to utilize the trusted site will contribute towards minimizing malicious abuses and protecting internet users.


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

As a restricted gTLD, registration will only be open to internal users at this stage and no third parties will be able to register domain names under .jcb domain space. Therefore, it is not anticipated that third party trademark owners will incur costs in relation to the .jcb gTLD. JCB will utilise the services of the proposed Trademark Clearinghouse to ensure that domain names registered and the use of those domain names, do not infringe any registered third party intellectual property rights.

No unaffiliated third party will be permitted to register domain names at this stage. It is estimated that time and money spent by consumers who have been targeted by malicious abuse in utilising services on the internet will reduce over time as a result of the new, trusted .jcb gTLD.

18(c)i.
The initial use of the proposed new gTLD will be restricted to internal business use and JCB intends to be the registrant under the .jcb gTLD. Therefore conflicts between multiple applications are
not anticipated to occur.

18(c)ii.
This gTLD will be used for internal purposes only, at this stage, so pricing incentives are not applicable or relevant.

18(c)iii.
This gTLD will be used for internal purposes only, at this stage, so pricing incentives or pricing increases are not applicable or relevant as no additional fees are to be charged.


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

No


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



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



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



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



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



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



21A. Is the application for a geographic name?

No


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

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

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

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

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

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

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

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

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


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

JCB Co., Ltd. has chosen GMO Registry, Inc as the registry infrastructure provider for .jcb. Any information regarding technical and operational capability of the proposed the TLD registry (answers to questions 23 – 44) therefore refers to GMO’s registry infrastructure systems.

 GMO Registry, Inc (GMO) is working with CentralNic Ltd to establish its gTLD registry system. Please see Appendix 23.1 for the acceptance letter from CentralNic. Any information regarding technical and operational capability of the proposed TLD registry (answers to questions 23 – 44) therefore refers to a new registry installed in and operated from Tokyo, Japan, replicating CentralNic’s registry infrastructure systems and set up and managed under CentralNic’s supervision.

GMO hereby explicitly confirms that all registry services stated below are engineered and will be provided in a manner compliant with the new gTLD Registry Agreement, ICANN consensus policies (such as Inter-Registrar Transfer Policy and AGP Limits Policy) and applicable technical standards. Except for the registry services described, no other services will be provided by the Registry that relate to (i) receipt of data from registrars concerning registrations of domain names and name servers; (ii) provision to registrars of status information relating to the zone servers for the TLD;(iii) dissemination of TLD zone files; (iv) operation of the Registry zone servers; or (v) dissemination of contact and other information concerning domain name server registrations in the TLD as required by the Registry Agreement.

There are no other products or services, except those described above that the Registry Operator would provide (i) because of the establishment of a Consensus Policy, or (ii) by reason of GMO being designated as the Registry Operator.

Any changes to the registry services that may be required at a later time in the course of GMO operating the TLD registry will be addressed using rules and procedures established by ICANN such as the Registry Services Evaluation Policy.

GMO proposes to operate the following registry services, utilising CentralNic's registry system as the model for the new Registry, to be built and managed with the support and under the supervision of CentralNic:


23.1. Receipt of Data From Registrars

GMO Registry will operate a Shared Registry System (SRS) for the TLD. The SRS consists of a database of registered domain names, host objects and contact objects, accessed via an Extensible Provisioning Protocol (EPP) interface, and a web based Registrar Console. Registrars will use these interfaces to provide registration data to the registry.

The SRS will be hosted in the primary operations centre in Tokyo, Japan. The primary operations centre comprises a resilient, fault-tolerant network infrastructure with multiple high quality redundant links to backbone Internet carriers. The primary operations centre is hosted in a telco-grade data centre and boasts significant physical security capabilities, including 24x7 patrols, CCTV and card-based access controls.

CentralNic's existing SRS system currently supports more than 350,000 domain names managed by over 1,500 registrars, and this system will be replicated for GMO.  GMO will have effective and efficient 24x7 customer support capabilities to support these domain names and registrars, and this capability will be expanded to meet the requirements of the TLD and provide additional capacity during periods of elevated activity (such as during Sunrise periods).

The SRS and EPP systems are described more fully in §24 and §25. The Registrar Console is described in §31.

EPP is an extensible protocol by definition. Certain extensions have been put in place to comply with the new gTLD registry agreement, ICANN Consensus Policies and technical standards:

  1. Registry Grace Period Mapping - compliant with RFC 3915
  2. DNSSEC Security Extensions - compliant with RFC 5910
  3. Launch Phase Extension - will be only active during the Sunrise phase, before the SRS opens for the general public. The extension is compliant with the current Internet Draft https://github.com/wil/EPP-Launch-Phase-Extension-Specification/blob/master/draft-tan-epp-launchphase.txt

More information on EPP extensions is provided in §25.

The SRS will implement and support all ICANN Consensus Policies and Temporary Policies, including:


23.2. Provision to Registrars of Status Information Relating to the Zone Servers

GMO will operate a communications channel to notify registrars of all operational issues and activity relating to the DNS servers which are authoritative for the TLD. This includes notifications relating to:

  1. Planned and unplanned maintenance;
  2. Denial-of-service attacks;
  3. Unplanned network outages;
  4. Delays in publication of DNS zone updates;
  5. Security incidents such as attempted or successful breaches of access controls;
  6. Significant changes in DNS server behaviour or features;
  7. DNSSEC key rollovers.

Notifications will be sent via email (to preregistered contact addresses), with additional notifications made via an off-site maintenance site and via social media channels.


23.3. Dissemination of TLD Zone Files

GMO will make zone files available via the Centralized Zone Data Access Provider according to specification 4, section 2 of the Registry Agreement.

GMO will enter into an agreement with any Internet user that will allow such user to access an Internet host server or servers designated by GMO and download zone file data. The agreement will be standardized, facilitated and administered by a Centralized Zone Data Access Provider (the “CZDA Provider”). GMO will provide access to zone file data using the file format described in Section 2.1.4 of Specification 4 of the New gTLD Registry Agreement.

GMO, through the facilitation of the CZDA Provider, will request each user to provide it with information sufficient to correctly identify and locate the user. Such user information will include, without limitation, company name, contact name, address, telephone number, facsimile number, email address, and the Internet host machine name and IP address.

GMO will provide the Zone File FTP (or other Registry supported) service for an ICANN-specified and managed URL for the user to access the Registry’s zone data archives. GMO will grant the user a non-exclusive, non-transferable, limited right to access GMO’s Zone File FTP server, and to transfer a copy of the top-level domain zone files, and any associated cryptographic checksum files no more than once per 24 hour period using FTP, or other data transport and access protocols that may be prescribed by ICANN.

GMO will provide zone files using a sub-format of the standard Master File format as originally defined in RFC 1035, Section 5, including all the records present in the actual zone used in the public DNS.

GMO, through the CZDA Provider, will provide each user with access to the zone file for a period of not less than three (3) months. GMO will allow users to renew their Grant of Access.

GMO will provide, and CZDA Provider will facilitate, access to the zone file to user at no cost.


23.4. Operation of the Registry Zone Servers

No matter how good the registration system, Internet users require that domain names resolve quickly and reliably. GMO’s DNS service provides name resolution for all domain names in the registry.

This service will be constructed on top of an already-operational worldwide publication/distribution system and network of name servers. These name servers employ IP-Anycast technology for scalable geographic redundancy, strong defense from Denial of Service attacks, high quality of service, and to give excellent response to widely geographically diverse clients.

DNSSEC and IPv6 are already fully integrated into this network and its component servers.

The DNS system fully complies with all relevant RFCs and all ICANN specifications, and has been engineered to ensure resilience and stability in the face of denial-of-service attacks, with substantial overhead and geographical dispersion.

The DNS system is described further in §35.


23.5. Dissemination of Contact and Other Information Concerning Domain Name Server Registrations

GMO will operate a Whois service for the TLD. The Whois service will provide information about domain names, contact objects, and name server objects stored in the Shared Registry System via a port-43 service compliant with RFC 3912. The Whois service will permit interested parties to obtain information about the Registered Name Holder, Administrative, Technical and Billing contacts for domain names in the TLD. The Whois service will return records in a standardised format that complies with ICANN specifications.

GMO will provide access to the Whois service at no cost to the general public.

The Whois service supports a number of features, including rate limiting to prevent abuse, privacy protections for natural persons, and a secure Searchable Whois Service. The Whois service is more fully described in §26.

Should ICANN specify alternative formats and protocols for the dissemination of Domain Name Registration Data, such as RDAP, GMO will implement such alternative specifications as soon as reasonably practicable.


23.6. DNSSEC

The TLD zone will be signed by DNSSEC. Zone files will be signed using NSEC3 with opt-out, following a DNSSEC Practice Statement detailed in §43 and based on RFC 6841.

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


23.7. Rights Protection Mechanisms

GMO will provide all mandatory Rights Protection Mechanisms that are specified in the Applicant Guidebook, namely the Trademark Claims Service and Sunrise service. All the required RPM-related policies and procedures such as UDRP, URS, PDDRP and RRDRP will be adopted and used in the TLD. More information is available in §29.

In addition to such RPMs, GMO may develop and implement additional RPMs that discourage or prevent registration of domain names that violate or abuse another party’s legal rights. GMO will include all ICANN mandated and independently developed RPMs in the registry-registrar agreement entered into by ICANN-accredited registrars authorised to register names in the TLD. GMO shall implement these mechanisms in accordance with requirements established by ICANN in each of the mandatory RPMs set forth in the Trademark Clearinghouse.

The "LaunchPhase" EPP extension (described above) will be used to implement an SRS interface during the Sunrise period for the TLD. Depending on the final specification for the Trademark Claims Service (details of which have not yet been published), an additional EPP extension may be required in order to implement this service. If this is necessary, the extension will be designed to minimise its effect on the operation of the SRS and the requirements on registrars, and will only be in place for a limited period while the Trademark Claims Service is in effect.


23.8. Registrar Support and Account Management

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


23.9. Reporting to ICANN

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


23.10. Personnel Resources

 

23.10.1. Initial Implementation

The .jcb registry system will be established on a new registry platform designed by CentralNic, and built and operated by GMO on its own dedicated infrastructure. The initial implementation of the registry system will be carried out jointly by both companies.

The implementation project has been divided into two separate tasks: the setup of the physical (network and server) infrastructure, which will be carried out by GMO, and the setup of the logical (software and database) infrastructure, which will be carried out by CentralNic.

For the implementation phase, GMO will assign the necessary personnel resources to complete its part of the project from its existing HR resources. The Full-Time Equivalent persons (FTEs) assigned by GMO to this phase of operations is described in Appendix 23.2.

CentralNic will also contribute personnel to the implementation team. The FTEs assigned to the project are shown in Appendix 23.3. These roles are funded by GMO under the agreement between GMO and CentralNic (see §46).

 

23.10.2 Ongoing Operation

Once established, the ongoing operation of the registry will be primarily carried out by GMO, with support and assistance from CentralNic. The Full-Time Equivalent persons (FTEs) assigned by GMO and CentralNic to this phase of operations are described in Appendices 23.2 and 23.3 CentralNic’s contribution to the ongoing operations of the system are funded by GMO under the agreement between GMO and CentralNic (see §46).

Ongoing operations are divided into three areas: Technical Operations, Technical Development, and Technical Support. The resources assigned to these areas are described below.


23.10.2.1. Technical Operations

Technical Operations refers to the deployment, maintenance, monitoring and security of the registry system, including the SRS and the other critical registry functions. Technical Operations staff design, build, deploy and maintain the technical infrastructure that supports the registry system, including power distribution, network design, access control, monitoring and logging services, and server and database administration. Internal helpdesk and incident reporting is also performed by the Technical Operations team. The Technical Operations team performs 24x7 monitoring and support for the registry system and mans the Network Operations Centre (NOC) from which all technical activities are coordinated.

During the initial implementation and startup of the registry system, the Technical Operations function of the registry will be conducted jointly by GMO and CentralNic. The FTEs assigned to this function by each company are described in Appendices 23.2 and 23.3. After three years from delegation, this function will be handed off to GMO’s engineering team, who will provide the Technical Operations function on an ongoing basis.


23.10.2.2. Technical Development

CentralNic’s Technical Development team develops and maintains the software which implements the critical registry functions, including the EPP, Whois, Zone File generation, data escrow, reporting, backoffice and web-based management systems (intranet and extranet), and open-source registrar toolkit software. All critical registry software has been developed and maintained in-house by this team and will be provided under license to GMO, together with the appropriate training to ensure the optimal operation of the registry.

CentralNic intends to maintain a Technical Development team consisting of the following positions. These persons will be responsible for maintaining and developing the registry software that will support GMO in operating the TLD:

The estimated FTEs dedicated to the GMO registry platform (shown in Appendix 23.3) are drawn from the above personnel.


23.10.2.3. Technical Support

Technical Support refers to 1st, 2nd and 3rd line support for registrars and end-users. Areas covered include technical support for systems and services, billing and account management. Support personnel also deal with compliance and legal issues such as UDRP and URS proceedings, abuse reports and enquiries from law enforcement.

1st line support issues are normally dealt with by these personnel. 2nd and 3rd line support issues (relating to functional or operational issues with the registry system) are escalated to Technical Operations or Technical Development as necessary.

During the initial implementation and startup of the registry system, the Technical Support function of the registry will be conducted jointly by GMO and CentralNic. The FTEs assigned to this function by each company are described in Appendices 23.2 and 23.3. Once the initial implementation is completed and three years have passed since delegation, this function will be handed off to GMO’s engineering team, who will provide the Technical Support function on an ongoing basis.

GMO’s Technical Support team will be trained in accordance with CentralNic standards.



24. Shared Registration System (SRS) Performance:
describe

JCB Co., Ltd. has chosen GMO Registry, Inc as the registry infrastructure provider for .jcb. Any information regarding technical and operational capability of the proposed TLD registry (answers to questions 23 – 44) therefore refers to GMO’s registry infrastructure systems.

 

24.1. Registry Type

GMO Registry, Inc.(GMO) will operate a "thick" registry, in which the registry maintains copies of all information associated with registered domains. Registrars maintain their own copies of registration information, thus registry-registrar synchronization is required to ensure that both registry and registrar have consistent views of the technical and contact information associated with registered domains. The Extensible Provisioning Protocol (EPP) adopted supports the thick registry model. See §25 for further details.


24.2. Architecture

Figure 24.1 provides a diagram of the overall configuration of the SRS. This diagram should be viewed in the context of the overall architecture of the registry system described in §32.

The SRS is hosted GMO’s primary operations centre in Tokyo, Japan. It will be connected to the public Internet by diverse upstream transit providers. Figure 32.1 provides a diagram of the outbound network connectivity. Interconnection with upstream transit providers is via two BGP routers that connect to the firewalls, which implement access controls over registry services.

Within the firewall boundary, connectivity is provided to servers by means of resilient gigabit ethernet switches implementing Spanning Tree Protocol.

The registry system will implement two interfaces to the SRS: the standard EPP system (described in §25) and the Registrar Console (described in §31). These systems will interact with the primary registry database (described in §33). The database is the central repository of all registry data. Other registry services also interact with this database.

GMO personnel will perform management of the registry system using an internal "Staff Console".


24.3. EPP System Architecture

A description of the characteristics of the EPP system is provided in §25. This response describes the infrastructure that supports the EPP system.

A network diagram for the EPP system is provided in Figure 24.2. The EPP system is hosted at the primary operations centre in Tokyo. During failover conditions, the EPP system operates from the hot standby site in San Jose, USA (see §34).

GMO’s EPP system will have a three-layer logical and physical architecture, consisting of load balancers, a cluster of front-end protocol servers, and a pool of application servers. Each layer can be scaled horizontally in order to meet demand.

Registrars establish TLS-secured TCP connections to the load balancers on TCP port 700. Load is balanced using DNS round-robin load balancing.

The load balancers pass sessions to the EPP protocol servers. Load is distributed using a weighted-least-connections algorithm. The protocol servers run the Apache web server with the mod_epp and mod_proxy_balancer modules. These servers process session commands (hello, login and logout) and function as reverse proxies for query and transform commands, converting them into plain HTTP requests which are then distributed to the application servers. EPP commands are distributed using a weighted-least-connections algorithm.

Application servers receive EPP commands as plain HTTP requests, which are handled using application business logic. Application servers process commands and prepare responses which are sent back to the protocol servers, which return responses to clients over EPP sessions.

Each component of the system is resilient: multiple inbound connections, redundant power, high availability firewalls, load balancers and application server clusters enable seamless operation in the event of component failure. This architecture also allows for arbitrary horizontal scaling: commodity hardware is used throughout the system and can be rapidly added to the system, without disruption, to meet an unexpected growth in demand.

The GMO EPP system will comprise of the following systems:

Load balancers: 2x IBM x3550M3 (2x Xeon E5620 2.4GHz 4C, 32GB mirrored, 6x 500GB SAS RAID10)

EPP Protocol Servers: 3x IBM x3550M3 (2x Xeon E5620 2.4GHz 4C, 32GB mirrored, 6x 500GB SAS RAID10)

EPP Application Servers: 6x IBM x3550M3 (2x Xeon E5620 2.4GHz 4C, 32GB mirrored, 6x 500GB SAS RAID10)


24.3.1. mod_epp

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


24.3.2. mod_proxy_balancer

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


24.4. Performance

GMO will perform continuous remote monitoring of its EPP system, and this monitoring will include measuring the performance of various parts of the system. As of writing, the average round-trip times (RTTs) for various functions of CentralNic’s EPP system, which will be used as a model for GMO, were as follows:

connect time: 52ms

login time: 46ms

hello time: 12ms

check time: 30ms

logout time: 13ms

These figures include an approximate latency of 2.4ms due to the distance between the monitoring site and the EPP system. They were recorded during normal weekday operations during the busiest time of the day (around 1300hrs UTC) and compare very favourably to the requirement of 4,000ms for session commands and 2,000ms for query commands defined in the new gTLD Service Level Agreement. RTTs for overseas registrars will be higher than this due to the greater distances involved, but will remain well within requirements.


24.5. Scaling

Horizontal scaling is preferred over vertical scaling. Horizontal scaling refers to the introduction of additional nodes into a cluster, while vertical scaling involves using more powerful equipment (more CPU cores, RAM etc) in a single system. Horizontal scaling also encourages effective mechanisms to ensure high-availability, and eliminate single points of failure in the system.

Vertical scaling leverages Moore's Law: when units are depreciated and replaced, the new equipment is likely to be significantly more powerful. If the average lifespan of a server in the system is three years, then its replacement is likely to be around four times as powerful as the old server.

For further information about Capacity Management and Scaling, please see §32.


24.6. Registrar Console

The Registrar Console is a web-based registrar account management tool. It provides a secure and easy-to-use graphical interface to the SRS. The Registrar Console will be hosted on a virtual platform at the primary operations centre in Tokyo. As with the rest of the registry system, during a failover condition it will be operated from the hot standby site in San Jose. The virtual platform is described in Figure 24.3.

The features of the Registrar Console are described in §31.

The virtual platform is a utility platform based on KVM that supports systems and services which do not operate at significant levels of load, and which therefore do not require multiple servers or the additional performance that running on "bare metal" would provide. The platform functions as a private cloud, with redundant storage and failover between hosts.


24.7. Quality Assurance

GMO will employ the following quality assurance (QA) methods:

24x7x365 monitoring provides reports of incidents to NOC

Quarterly review of capacity, performance and reliability

Monthly reviews of uptime, latency and bandwidth consumption

Hardware depreciation schedules

Unit testing framework

Frequent reviews by QA working group

Schema validation and similar technologies to monitor compliance on a real-time, ongoing basis

Additionally, CentralNic will use the following measures to ensure the quality of the registry software:

Revision control software with online annotation and change logs

Bug Tracking system to which all employees have access

Code Review Policy in place to enforce peer review of all changes to core code prior to deployment

Software that incorporates built-in error reporting mechanisms to detect flaws and report to Operations team

GMO and CentralNic will jointly use the following:

Four stage deployment strategy: development environment, staging for internal testing, OT&E deployment for registrar testing, then finally production deployment

Evidence-based project scheduling

Specification development and revision

Weekly milestones for developers

Gantt charts and critical path analysis for project planning

Registry system updates will be performed on an ongoing basis, with any user-facing updates (ie changes to the behaviour of the EPP interface) being scheduled at specific times. Disruptive maintenance is scheduled for periods during which activity is lowest.


24.8. Billing

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

Once ICANN notifies GMO that a registrar has been issued accreditation, GMO will begin the registrar on-boarding process, including setting up the registrar's financial account within the SRS.


24.9. Registrar Support

GMO will provide a multi-tier support system on a 24x7 basis with the following support levels:

1st Level: initial support level responsible for basic customer issues. The first job of 1st Level personnel is to gather the customer’s information and to determine the customer’s issue by analyzing the symptoms and figuring out the underlying problem.

2nd Level: more in-depth technical support level than 1st Level support containing experienced and more knowledgeable personnel on a particular product or service. Technicians at this level are responsible for assisting 1st Level personnel solve basic technical problems and for investigating elevated issues by confirming the validity of the problem and seeking for known solutions related to these more complex issues.

3rd Level: the highest level of support in a three-tiered technical support model responsible for handling the most difficult or advanced problems. Level 3 personnel are experts in their fields and are responsible for not only assisting both 1st and 2nd level personnel, but with the research and development of solutions to new or unknown issues.

GMO will provide a support ticketing system for tracking routine support issues. This is a web-based system (available via the Registrar Console) allowing registrars to report new issues, follow up on previously raised tickets, and read responses from GMO’s support personnel.

When a new trouble ticket is submitted, it is assigned a unique ID and priority. The following priority levels are used:

Normal: general enquiry, usage question, or feature enhancement request. Handled by 1st level support.

Elevated: issue with a non-critical feature for which a work-around may or may not exist. Handled by 1st level support.

Severe: serious issue with a primary feature necessary for daily operations for which no work-around has been discovered and which completely prevents the feature from being used. Handled by 2nd level support.

Critical: A major production system is down or severely impacted. These issues are catastrophic outages that affect the overall Registry System operations. Handled by 3rd level support.

Depending on priority, different personnel will be alerted to the existence of the ticket. For example, a Priority 1 ticket will cause a notification to be emailed to the registrar customer support team, but a Priority 4 ticket will result in a broadcast message sent to the pagers of senior operations staff including the CTO. The system permits escalation of issues that are not resolved within target resolution times.


24.10. Enforcement of Eligibility Requirements

The SRS supports enforcement of eligibility requirements, as required by specific TLD policies.


24.11. Interconnectivity With Other Registry Systems

The registry system is based on multiple resilient stateless modules. The SRS, Whois, DNS and other systems do not directly interact with each other. Interactions are mediated by a distributed network of databases, which replicate from the primary registry database, which is the single authoritative source of data for the registry as a whole. Individuals modules perform "CRUD" (create, read, update, delete) actions upon the database. For performance reasons, the remote Anycast Whois sites use a replicated subset of the primary database.

Changes to the primary database made by one module will affect the behaviour of other registry systems: for example, when a registrar adds the "clientHold" status to a domain object, this is recorded in the database. When a query is received for this domain via the Whois service, the presence of this status code in the database results in the "Status: CLIENT HOLD" appearing in the whois record. It will also be noted by the zone generation system, resulting in the temporary removal of the delegation of the domain name from the DNS.


24.12. Resilience

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


24.12.1. Synchronisation Between Servers and Sites

GMO’s system will be implemented as multiple stateless systems which interact via a central registry database. As a result, there will only be few situations where synchronisation of data between servers is necessary:

Replication of data from the primary operations centre to the Anycast Whois sites (see §26).

Replication is also used to synchronise the primary operations centre with the hot standby site hosted in San Jose (see §34). Database updates are replicated to the standby site in real-time via a secured VPN.


24.13. Operational Testing and Evaluation (OT&E)

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


24.14. Resourcing

The .jcb registry system will be established on a new registry platform designed by CentralNic, and built and operated on GMO’s dedicated infrastructure. The project plan for this is described in §23. As can be seen in the Resourcing Chart found in Appendix 23.2, during the ongoing operations of the registry, GMO will contribute to the development and maintenance of this aspect of the registry system. This team will not work on specific registry subsystems full-time, but a certain percentage of their time will be dedicated to each area.

Additionally, GMO will draw upon CentralNic’s own team of engineers and developers, as described in the FTE resource assignment described in Appendix 23.3. This contribution is slightly less than one full-time position. CentralNic personnel will work closely with GMO during the initial implementation of the registry, and will provide technical support and advice during ongoing operations through Year 3. CentralNic will provide enhancements to the performance and functionality of the registry system to GMO under the terms of the agreement between the two companies.


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

JCB Co., Ltd. has chosen GMO Registry, Inc as the registry infrastructure provider for .jcb. Any information regarding technical and operational capability of the proposed TLD registry (answers to questions 23 – 44) therefore refers to GMO’s registry infrastructure systems.

The Extensible Provisioning Protocol (EPP) is an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. EPP defines generic object management operations and an extensible framework that maps protocol operations to objects. EPP has become established as the common protocol by which domain registrars can manage domains, nameservers and contact details held by domain registries. It is widely deployed in the gTLD and ccTLD registry space.

CentralNic has operated its EPP system since 2005 and it currently operates at significant load in terms of registrars, sessions and transaction volumes. This system will be replicated for GMO Registry, Inc (GMO). GMO’s EPP system will be fully compliant with the following RFC specifications:


25.1. Description of Interface

EPP is a stateful XML protocol layered over TCP (see RFC 5734). Protected using lower-layer security protocols, clients exchange identification, authentication, and option information, and engage in a series of client-initiated command-response exchanges. All EPP commands are atomic (there is no partial success or partial failure) and designed so that they can be made idempotent (executing a command more than once has the same net effect on system state as successfully executing the command once).

EPP provides four basic service elements: service discovery, commands, responses, and an extension framework that supports definition of managed objects and the relationship of protocol requests and responses to those objects.

EPP servers respond to client-initiated communication (which can be either a lower-layer connection request or an EPP service discovery message) by returning a greeting to a client. The server then responds to each EPP command with a coordinated response that describes the results of processing the command.

EPP commands fall into three categories: session management, queries, and transform commands. Session management commands are used to establish and end persistent sessions with an EPP server. Query commands perform read-only object information retrieval operations. Transform commands perform read-write object management operations.

Commands are processed by a server in the order they are received from a client. The protocol includes features that allow for offline review of transform commands before the requested action is completed. In such situations, the response clearly notes that the command has been received but that the requested action is pending. The corresponding object then reflects processing of the pending action. The server will also notify the client when offline processing of the action has been completed. Object mappings describe standard formats for notices that describe completion of offline processing.

EPP uses XML namespaces to provide an extensible object management framework and to identify schemas required for XML instance parsing and validation. These namespaces and schema definitions are used to identify both the base protocol schema and the schemas for managed objects.


25.1.1. Objects supported

Registrars may create and manage the following object types in GMO’s EPP system:


25.1.2. Commands supported

GMO will support the following EPP commands:


25.2. EPP state diagram

Figure 25.1 describes the state machine for the EPP system. Clients establish a connection with the server, which sends a greeting. Clients then authenticate, and once a login session is established, submits commands and receive responses until the server closes the connection, the client sends a logout command, or a timeout is reached.


25.3. EPP Object Policies

The following policies apply to objects provisioned via the EPP system:


25.3.1. domains

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


25.3.2. Host objects

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


25.3.3. Contact objects

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


25.4. EPP Extensions

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


25.4.1. Registry Grace Period Mapping

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


25.4.2. DNSSEC Security Extensions Mapping

Registrars may submit Delegation Signer (DS) record information for domains under their sponsorship. This permits the establishment of a secure chain-of-trust for DNSSEC validation.

GMO will support the specification defined in RFC 5910. This supports two interfaces: the DS Data Interface and Key Data Interface. GMO will support the former interface (DS Data), where registrars submit the keytag, algorithm, digest type and digest for DS records as XML elements, rather than as key data. Key data is stored if provided as a child element of the secDNS:dsData element. The maxSigLife element is optional in the specification and is not currently supported.


25.4.3. Launch Phase Extension

CentralNic has assisted development of a standard EPP extension for registry "launch phases" (ie Sunrise and Landrush periods), during which the steady-state mode of "first-come, first-served" operation does not apply. This extension permits registrars to submit requests for domains with claimed rights such as a registered trademark. The extension is currently described in an Internet-Draft which is included in Appendix 25.1. It is hoped that this draft will eventually be published as an RFC which can be implemented by other registries and registrars.

GMO’s system will implement this extension and will support the most recent version of the draft during the initial launch of the TLD.

 

25.4.4. IDN Language Tag Extension

The IDN Language Tag extension permits a registrar to unambiguously identify the language associated with an internationalized domain name when submitting a domain:createcommand. This extension is described in an Internet-Draft which is included in Appendix 25.2.

GMO’s system will implement this extension and will support the most recent version of the draft during the initial launch of the TLD.

 


25.5. Registrar Credentials and Access Control

Registrars are issued with a username (their registrar ID) and a password. This password cannot be used to access any other service and only this password can be used to access the EPP system. Registrar officers with the "Management" access level can change their EPP password via the Registrar Console.

RFC 5730 requires "mutual, strong client-server authentication". GMO requires that all registrars connect using an SSL certificate. This certificate may be obtained from a recognised certificate authority, or it may be a self-signed certificate registered with GMO via the Registrar Console. Registrar officers with the "Management" access level can upload SSL certificates for their account.


25.6. Session Limits and Transaction Volumes

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


25.7. Transaction Logging and Reporting

All "transform" commands are logged. Transform commands are: create, renew, update, delete and transfer. The system logs the time and date when the command was received, the registrar which submitted it, the request and response frames, the result code and message. All commands, whether successful or not, are logged.

The transaction log is stored in the primary registry database. Registrars have access to the log for their account via the Registrar Console. The log viewer permits filtering by command, object type, object ID (domain, host name, contact ID), result code and timestamp.

“Query” commands (ie check, info, poll op="req") are logged via a separate logging system, in order to reduce unnecessary load on the primary database system. These logs are used to generate the monthly reports which will be submitted to ICANN.


25.8. EPP Message Queue

The EPP protocol provides a message queue to provide registrars with notifications for out-of-band events. CentralNic’s infrastructure currently supports the following EPP message notifications which will be replicated for GMO:


25.9. Registrar Support, Software Toolkit

CentralNic has supported EPP for many years. CentralNic has released a number of open source client libraries for several popular programming languages. These are used by registrars and registries around the world. CentralNic maintains the following open source EPP libraries:

These libraries are available for anyone to use, at no cost. CentralNic develops these libraries, and accepts submissions and bug reports from users around the world.


25.10. Quality Assurance, RFC Compliance

To ensure that its EPP system fully complies with the relevant specifications documents, GMO will implement the following:


25.10.1. Schema Validation

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


25.10.2. Multi-stage Deployment and Testing

EPP system code is developed, tested and deployed in a multi-stage environment:

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


25.10.3. Registrar Feedback

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


25.11. EPP System Resourcing

As can be seen in the Resourcing Chart found in Appendix 23.2, during the ongoing operations of the registry, GMO will contribute to the development and maintenance of this aspect of the registry system. This team will not work on specific registry subsystems full-time, but a certain percentage of their time will be dedicated to each area.

Additionally, GMO will draw upon CentralNic’s own team of engineers and developers, as described in the FTE resource assignment described in Appendix 23.3. This contribution is slightly less than one full-time position. CentralNic personnel will work closely with GMO during the initial implementation of the registry, and will provide technical support and advice during ongoing operations through Year 3. CentralNic will provide enhancements to the performance and functionality of the registry system to GMO under the terms of the agreement between the two companies.



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

JCB Co., Ltd. has chosen GMO Registry, Inc as the registry infrastructure provider for .jcb. Any information regarding technical and operational capability of the proposed TLD registry (answers to questions 23 – 44) therefore refers to GMO’s registry infrastructure systems.

 

Whois is one of the oldest Internet protocols still in use. It allows interested persons to retrieve information relating to Internet resources (domain names and IP addresses). Whois services are operated by the registries of these resources, namely TLD registries and RIRs.

Whois is described by RFC 3912, which serves as a description of existing systems rather than requiring specific behaviours from clients and servers. The protocol is a query-response protocol, in which both the query and the response are opaque to the protocol, and their meanings are known only to the server and to the human user who submits a query. Whois has a number of limitations, but remains ubiquitous as a means for obtaining information about name and number resources.


26.1. Compliance

The Whois service will comply with RFC3912 and Specifications 4 and 10 of the New gTLD Registry Agreement. The service will be provided to the general public at no cost. If ICANN specify alternative formats and protocols (such as RDAP) then GMO Registry, Inc (GMO) will implement these as soon as reasonably practicable.

GMO will monitor its Whois system to confirm compliance. Monitoring stations will check the behaviour and response of the Whois service to ensure the correctness of Whois records. GMO will maintain a public Whois contact to which bug reports and other questions about the Whois service can be directed.


26.2. Domain Name Query

By default, any query is assumed to be a domain name unless a keyword is prepended to the query. If the domain exists, then registration is returned, including the following fields:

An example of a domain whois response is included in Appendix 26.1. The Domain ROID is the Repository Object Identifier as described in RFC 5730, §2.8. The ROID field corresponds to the domain:roid  element of EPP “info” responses.

A domain may be associated with one or more status codes. These are represented in Whois responses as phrases rather than EPP mnemonics. A domain may have any of the following status codes:

The Registrant, Administrative, Technical and Billing Contact sections of the Whois record display the contact information for the contact objects that are associated with the domain. The information displayed replicates the information showed for a contact query (see below). The server shows similar information for the sponsoring registrar.

Domains may have 0-13 DNS servers. If a domain name has no DNS servers, then the "INACTIVE" status code appears in the Status section. If the registrant provided DS records for their DNSSEC-signed domain, then these are included. For each DS record, then the key tag, algorithm, digest type and digest are displayed.


26.3. Contact Object Query

Users can query for information about a contact by submitting a query of the form "contact [ID]", where "[ID]" is the contact ID equivalent to the contact:id element in EPP info responses. This is also the ID used when referring to contacts in domain responses.

The following information is included in Contact records:

An example of a contact object whois response is included in Appendix 26.2. A contact object may be associated with one or more status codes. These are represented in Whois responses as phrases rather than EPP code mnemonics. A contact object may have any of the following status codes:


26.4. Host Objects

Users can query for information about a host object by submitting a query of the form "nameserver [HOST]". The following information is included in host records:

An example of a host whois response is included in Appendix 26.3. A host object may have an IPv4 or IPv6 address if the host is "in-bailiwick", ie subordinate to a domain name within a TLD operated by the registry. IP address information is not shown for "out-of-bailiwick" hosts.

Host objects may only have two status codes:

The Referral URL is the website of the Sponsoring Registrar for this host. If the host is subordinate to a domain name in the TLD, this will be the sponsoring registrar of the parent name. If the host is out-of-bailiwick, then the sponsoring registrar is the registrar who issued the original “create” request.


26.5. Character Encoding

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


26.6. IDN Support

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


26.7. Bulk Access

GMO will provide up-to-date registration data to ICANN on a weekly basis (the day to be designated by ICANN). GMO will provide the following data for all registered domain names: domain name, repository object id (roid), registrar id (IANA ID), statuses, last updated date, creation date, expiration date, and name server names. For sponsoring registrars it will provide: registrar name, registrar repository object id (roid), hostname of registrar Whois server, and URL of registrar. Data will be provided in the format specified in Specification 2 for Data Escrow (including encryption, signing, etc.) but including only the fields mentioned in the above.

At ICANN's request, GMO will provide ICANN with up-to-date data for the domain names of de-accredited registrars to facilitate a bulk transfer. The data will be provided in the format specified in Specification 2 for Data Escrow. The file will only contain data related to the domain names of the losing registrar. GMO will provide the data within 2 business days.


26.8. Load Projections

As described in §31, CentralNic's existing Whois system receives an average of 0.36 queries per day for each domain name in the registry, including misses for non-existent objects as well as hits.

The number of daily queries per domain for each existing gTLD was calculated using figures for the month of November 2011 published by ICANN. This analysis may be found in Appendix 26.6. It shows little correlation between the number of domains in the TLD and the number of queries that each domain receives. Smaller gTLDs such as .aero and .museum receive more queries per domain than larger gTLDs, but .jobs (which is much larger than either .aero or .museum) received more queries per domain than either. It should be noted that the high volumes observed for .XXX are very likely due to activities surrounding the Landrush and initial launch of that TLD.

CentralNic believes that the query rate observed for its own registry system is mainly affected by its efforts to deter abuse, and outreach to registrars, who often use Whois to perform availability checks, to encourage them to use EPP instead. CentralNic believes this query rate will also apply for GMO’s Whois service. A projection of query load for the Whois system for the first 24 months of operation can be found in Appendix 26.4. This model also includes data transit rates and bandwidth projections for the same period. As can be seen, the data and bandwidth requirements are relatively small compared to those for the Shared Registry System and authoritative DNS.


26.9. Technical Implementation

A diagram describing the infrastructure supporting the Whois service may be found in Figure 26.1. During normal operations, the Whois service will be operated at the primary operations centre in Tokyo. During failover conditions, it is operated at the Disaster Recovery site in San Jose (see §34).

Queries pass through the firewalls to one of two front-end load balancers. Round-robin DNS distributes queries between the devices. Load balancers are configured in High Availability mode so that if one server fails, the other will resume service on its IP address until the server can be restored. Queries are distributed to backend application servers via weighted least connections algorithm.


26.9.1. Application Server Architecture

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


26.9.2. Caching

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


26.9.2. Database

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


26.10. Web based Whois Service

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


26.11. Searchable Whois Service

GMO will provide a Searchable Whois Service (SWS). This service will be made available on the registry website. The SWS provides third parties with a search interface that allows queries for partial matches against a number of domain name properties, including:

Access to the SWS is restricted. Users must submit an account request via the website, and agree to the terms and conditions which governs their access to the system. These terms are included as Appendix 26.5. Once their request has been reviewed and approved, they are issued with credentials that permit them to login to the SWS.

To prevent abuse of the SWS, users may only make fifty queries per day initially. This limit can be increased upon request and demonstration of legitimate need.


26.12. Anti-Abuse Mechanisms

CentralNic has implemented measures to mitigate the threat of abuse of the Whois service and these will be observed by GMO. The primary threat to the Whois service are so-called "dictionary" attacks, where an attacker attempts to enumerate the database by flooding the server with queries for domains taken from a precompiled list: as zone files are easy to obtain, this presents a threat to the privacy of contact information in the registry database. The information harvested can be used to compile email databases for spamming, or to send domain renewal scam letters, for example.

The Whois service implements rate-limiting to impede dictionary attacks. For each query, a counter associated with the client IP address is incremented. For subsequent queries, this counter determines the number of queries received within the previous hour. If the number of queries exceeds a pre-set maximum (currently 240 queries per hour), then the server returns an error, warning the user that they have exceeded the permitted query rate. If the user stops sending queries, then eventually the query rate will drop below the limit, and subsequent queries will be permitted. If the user continues to send queries, and the query rate exceeds the limit by a further 25% (300 queries per hour), then the IP address is permanently blocked. For queries over IPv6 (where an attacker might have access to billions of IP addresses), the enclosing /48 will be blocked.

Experience indicates that is an effective mechanism for preventing abuse of the Whois. The rate limit has been tuned to ensure that legitimate uses of the Whois are allowed, but abusive use of the Whois is restricted to levels which are unappealing for attackers.

GMO will keep a "white list" of IP addresses used by legitimate users of the Whois service, including law enforcement agencies and other research and anti-abuse entities. Registrar access lists will also be incorporated into the white list, and IP addresses registered on ICANN's RADAR system will also be included. Queries from IP addresses that appear on the white list will not be rate-limited. Interested parties can request addition to the white list by contacting GMO’s public customer service team.

The web-based Whois will not implement rate-limiting, but users of this service must complete a CAPTCHA to access Whois records.


26.12.1. Denial-of-Service attacks

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


26.13. Monitoring and Logging

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


26.14. Resourcing

As can be seen in the Resourcing Chart found in Appendix 23.2, during the ongoing operations of the registry, GMO will contribute to the development and maintenance of this aspect of the registry system. This team will not work on specific registry subsystems full-time, but a certain percentage of their time will be dedicated to each area.

Additionally, GMO will draw upon CentralNic’s own team of engineers and developers, as described in the FTE resource assignment described in Appendix 23.3. This contribution is slightly less than one full-time position. CentralNic personnel will work closely with GMO during the initial implementation of the registry, and will provide technical support and advice during ongoing operations through Year 3. CentralNic will provide enhancements to the performance and functionality of the registry system to GMO under the terms of the agreement between the two companies.



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

JCB Co., Ltd. has chosen GMO Registry, Inc as the registry infrastructure provider for .jcb. Any information regarding technical and operational capability of the proposed TLD registry (answers to questions 23 – 44) therefore refers to GMO’s registry infrastructure systems.

 

The lifecycle of a domain in the registry is described in Figure 27.1, and closely follows that of domain names in existing gTLD registries. The lifecycle is described below.


27.1. Available

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


27.2. Registered

A registrar submits an EPP create command or registers the domain name via the Registrar Console. The registration fee is deducted from the registrar's balance. The initial registration period may be any whole number of years between one (1) and ten (10).

For five (5) calendar days after the registration of the domain, the registrar can delete the domain and receive a credit for the registration fee (subject to the Add Grace Period Limits Policy).

While the domain is registered, it is delegated to the specified name servers and will resolve normally. During this time, the registrar may update the domain name's DNS settings, lock statuses and contact associations, and may extend the registration period (subject to a maximum of ten (10) years) by submitting a renew EPP command or using the Registrar Console.

The domain may also be transferred to a different sponsoring registrar. Upon such transfer the domain name is automatically renewed for one year.


27.3. Expired

When the expiry date is reached, the domain name is automatically renewed for a period of one year, and the renewal fee is deducted from the registrar's account.

For forty-five (45) days after the auto-renewal (Auto-Renew Grace Period), the registrar can delete the domain and receive a credit for the renewal fee.


27.4. Redemption Grace Period

Should the registrar delete the domain, the domain enters the Redemption Grace Period. During this period, the domain name will no longer resolve as all delegation information is removed from the zone.

For the first thirty (30) days after receipt of the delete request, the domain is in the "Pending Delete Restorable" state. During this time, the registrar may submit an RGP restore request via EPP or the Registrar Console. The domain is then placed into the "Pending Restore" state.

The registrar must then submit an RGP Restore Report detailing the reason why the restore request has been submitted. If the Restore Report is received within five (5) calendar days of the original restore request, then the domain is restored. However, if the Restore Report is not received within this period, then the domain falls back into the "Pending Delete Restorable" state.


27.5. Redemption Period State Diagram

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


27.6. Pending Delete

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


27.7. Released

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


27.8. Other Grace Periods

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


27.8.1. Add Grace Period

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


27.8.2. Auto-renew Grace Period

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


27.8.3. Renew Grace Period

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


27.8.4. Transfer Grace Period

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


27.9. Hold Periods

GMO Registry, Inc (GMO) will implement the following hold periods:


27.9.1. Registration Hold Period

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


27.9.2. Transfer Hold Period

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


27.10. Lock Statuses

GMO will permit the following lock statuses for domain names:


27.10.1. clientHold

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


27.10.2. clientDeleteProhibited

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


27.10.3. clientRenewProhibited

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


27.10.4. clientUpdateProhibited

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


27.10.5. clientTransferProhibited

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


27.10.6. serverHold

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


27.10.7. serverDeleteProhibited

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


27.10.8. serverUpdateProhibited

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


27.10.9. serverRenewProhibited

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


27.10.10. serverTransferProhibited

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


27.11. Lifecycle Processing

Domain names move through the lifecycle in one of two ways: in real-time as a result of registrar activity, or during daily billing runs.

Billing runs take place once per day. The billing run performs the following batch jobs:

The billing runs also perform registrar account management functions such as generation of invoices, sending balance warnings, and generation of internal reports.

27.11.1. Grace Period Processing

Unlike other billing processes, which run once per day, the system that causes domain names to exit the Add, Renew and Auto-Renew Grace Periods runs every sixty (60) seconds. This ensures that domains exit these grace periods exactly 86,400 seconds (times 5 or 45 days) after they entered them.


27.12. Inter-Registrar Transfer Period

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


27.13. pendingCreate Status

The registry systems supports the "pendingCreate" status for domain names, as described in RFC 5731, §3.3. Domains in this state are fully registered in the database (subsequent create commands would fail with an Object Exists error) but are not present in the DNS.

This status is used when a particular TLD implements a policy whereby registration requests are verified by a third party such as a Sponsoring Organisation or Validation Agent. Following out-of-band review of the request, the registration may be approved or denied.

If a request is denied, then the domain is immediately purged from the registry system, and the registrar notified via email and the EPP message queue. The registrar also receives a credit for the registration fee. If approved, then the pendingCreate status is removed from the domain that begins to resolve.

This status code will not be used unless registry policy requires it.


27.14. Resourcing

As can be seen in the Resourcing Chart found in Appendix 23.2, during the ongoing operations of the registry, GMO will contribute to the development and maintenance of this aspect of the registry system. This team will not work on specific registry subsystems full-time, but a certain percentage of their time will be dedicated to each area.

Additionally, GMO will draw upon CentralNic’s own team of engineers and developers, as described in the FTE resource assignment described in Appendix 23.3. This contribution is slightly less than one full-time position. CentralNic personnel will work closely with GMO during the initial implementation of the registry, and will provide technical support and advice during ongoing operations through Year 3. CentralNic will provide enhancements to the performance and functionality of the registry system to GMO under the terms of the agreement between the two companies.


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

In order to safeguard the security and stability of .jcb, as well as the Internet at large, JCB Co., Ltd. (the registry) takes abuse very seriously and employs proactive measures to mitigate abusive activities.

In general, the registry’s abuse mitigation strategies fall into the following broad areas:

·         Conducting pre-verification of registration eligibility

·         Developing and publishing a set of comprehensive abuse policies including clear definitions of abusive activities;

·         Establishing and publishing a single abuse point of contact to address and resolve abuse complaints at Registry startup and on an ongoing basis; and

·         Developing procedures for handling complaints, including takedown requests, in a timely manner.

 

28.1. Pre-Verification of Registration Eligibility

.jcb is a domain for JCB Co., Ltd. and its stakeholders, and the registry believes that it is important to prevent unqualified registrations in order to keep the TLD space safe and reliable; therefore, the registry will conduct registrant pre-verification in all .jcb registration phases.

Registration and management of .jcb domain names will be carried out via the .jcb dedicated account provided by a .jcb accredited registrar. Access to the .jcb dedicated account will be limited to the registrants and their authorized administrative contacts, subject to verification of registration eligibility. The verification will be conducted by the registry, and organizations that wish to apply for a .jcb dedicated account will be required to provide proof of registration eligibility to the registry via a .jcb accredited registrar. Proposed valid forms of documentary proof include, but are not limited to,

·         Company seal (registered or unregistered)

·         Signature of management staff

The registry will conduct verification on a per-registrant basis only. Once verified, the registrant or its authorized administrative contact will have access to the .jcb dedicated account, through which it may apply for multiple .jcb domain names without further verification, under the condition that the registrant and administrative contact information of an applied-for domain name is identical to that which the registry has verified. If there are any material changes to the verified information, the registrant or administrative contact must notify the registry of the change. Failure to comply with the policies may result in the suspension or cancellation of the .jcb dedicated account, and/or the denial, cancellation or transfer of any registration or transaction, as well as the placement of lock, hold or similar statuses on applying-for and/or existing domain names.

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

 

28.2. Draft Abusive Use Policy

The registry defines abuse as any activity that may harm the stability and security of the DNS and Internet, including, but not limited to:

·         Illegal or fraudulent activities;

·         Phishing;

·         Pharming;

·         Using or distributing malicious software (malware);

·         Sending unsolicited bulk messages (spam);

·         Posting, trading, or exchanging information that harms minors; and

·         Posting information that is offensive to public order or morals.

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

 

28.3. Abuse Public Contact Information

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

Also, the registry will also publish its abuse public contact information on its web site when it publicly releases the .jcb domain name registration policies, The abuse public contact will be responsible for handling complaints concerning abusive activities relating to domains registered under the .jcb TLD that violate the Abuse Use Policy and require expedited attention. The abuse public contact will be available 24 hours a day 7 days a week. A person who wishes to contact the abuse public contact will be required to submit the Abuse Complaint Form via e-mail or via the online Abuse Complaint Form on the Registry web site.

28.4. Abuse Complaint Form

In order to gather pertinent information about a reported incident, facilitate accurate investigation, and avoid false alarms / positives, the registry will provide an Abuse Complaint form on the registry website. The Abuse complaint form is required at the time a person contacts the abuse public contact and can be submitted online or by email in the format specified on the registry website.

 

28.5. Draft Takedown Procedure

 

·         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

o    assign a ticket number

o    review complaint form

o    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

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

o    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 registry understands that the Registration Abuse Policies Working Group has been working on developing best practices for registries and registrars addressing the fraudulent use of domain names. The registry will closely follow the working group discussions and documents, with a view of adopting the best practices to enhance abuse mitigation capabilities.

In addition, the registry will participate in security forums to keep track of the latest developments in abuse mitigation best practices and refine our abuse policies and procedures from time to time.

 

28.6.  Orphan Glue Records

The registry’s view on orphan glue records is consistent with the Security and Stability Advisory Committee Comment on Orphan Glue Records

 <http://www.icann.org/en/committees/security/sac048.pdf>. The registry supports the use of orphan glue records for legitimate purposes. Upon receiving a complaint relating to an orphaned glue record used in connection with malicious activities, the registry will verify and take corrective actions in accordance with its takedown procedures.

 

28.7. Resourcing Plans

As can be seen in the Resourcing Chart found in Appendix 23.2, during the ongoing operations of the registry, GMO will contribute to the development and maintenance of this aspect of the registry system. This team will not work on specific registry subsystems full-time, but a certain percentage of their time will be dedicated to each area.

Additionally, GMO will draw upon CentralNic’s own team of engineers and developers, as described in the FTE resource assignment described in Appendix 23.3. This contribution is slightly less than one full-time position. CentralNic personnel will work closely with GMO during the initial implementation of the registry, and will provide technical support and advice during ongoing operations through Year 3. CentralNic will provide enhancements to the performance and functionality of the registry system to GMO under the terms of the agreement between the two companies.



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

JCB Co., Ltd. (the registry) is committed to implementing and adhering to any rights protection mechanisms that may be mandated from time to time by ICANN, as required by Specification 7 of the New gTLD Agreement.

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

·         Pre-Verification of Registration Eligibility

·         Sunrise Registration Process

·         Trademark Claims service

·         Uniform Rapid Suspension (URS) system

·         Uniform Domain Name Dispute Resolution Policy (UDRP)

·         Abusive Use Policy

 

29.1. Pre-Verification of Registration Eligibility

Since .jcb is a domain for JCB Co., Ltd. and its stakeholders, it is important to prevent unqualified registrations in order to maintain a safe and trusted TLD space, as well as to protect the legal rights of others; therefore, the registry will conduct registrant pre-verification in all .jcb registration phases.

Registration and management of .jcb domain names will be carried out via the .jcb dedicated account provided by a .jcb accredited registrar. Access to the .jcb dedicated account will be limited to the registrants and their authorized administrative contacts, subject to verification of registration eligibility. The verification will be conducted by the registry, and organizations that wish to apply for a .jcb dedicated account will be required to provide proof of registration eligibility to the registry via a .jcb accredited registrar. Proposed valid forms of documentary proof include, but are not limited to,

·         Company seal (registered or unregistered)

·         Signature of management staff

The registry will conduct verification on a per-registrant basis only. Once verified, the registrant or its authorized administrative contact will have access to the .jcb dedicated account, through which it may apply for multiple .jcb domain names without further verification, under the condition that the registrant and administrative contact information of an applied-for domain name is identical to that which the registry has verified. If there are any material changes to the verified information, the registrant or administrative contact must notify the registry of the change. Failure to comply with the policies may result in the suspension or cancellation of the .jcb dedicated account, and/or the denial, cancellation or transfer of any registration or transaction, as well as the placement of lock, hold or similar statuses on applying-for and/or existing domain names.

 

29.2. Sunrise Registration Process

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

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

 

29.3. Sunrise Eligibility Requirements

In accordance with the section entitled “Trademark Clearinghouse” of the Application Guidebook (January 11, 2012 version), .jcb SER will at least include

·         Acceptable marks:

o    Nationally or regionally registered and for which proof of use (which may be a declaration and a single specimen of current use) was submitted to, and validated by, the Trademark Clearinghouse;

o    That have been court-validated; or

o    That are specifically protected by a statute or treaty currently in effect and that was in effect on or before 26 June, 2008

·         Representation that all provided information is true and correct;

·         Provision of data sufficient to document rights in the trademark; and

·         The registrant of the domain name must be the owner of a corresponding registered mark in the Trademark Clearinghouse.

 

29.4. Acceptable Domain Name Strings during the Sunrise Registration Process

The domain name strings applied for during the Sunrise registration process must be exactly identical to the applicant’s trademark and be in the Trademark Clearinghouse database. Exceptions (i.e. for trademarks that contain special characters, spaces, punctuations, images, the word jcb, etc.) will be developed by the registry before the registration phase opens.

 

29.5. Other Rules for Sunrise Registration Process

·         The Sunrise Registration Process will be run for at least 30 days which is the period required by ICANN. However, the registry may run the process longer at its own discretion.

·         During the Sunrise Registration Process, a domain name can be registered for 2-10 years.

·         Multiple validated applications for the same domain name will be resolved on a first-come-first-served basis.

·         Deletion, renewal, and transfer of a Sunrise domain name will be prohibited for 60 calendar days after the domain name is successfully registered.

 

29.6. Sunrise Dispute Resolution Policy

As required by ICANN, proposed .jcb SDRP will allow challenges based on at least the following four grounds:

·         At the time the challenged domain name was registered, the registrant did not hold a trademark registration of national effect (or regional effect) or the trademark had not been court-validated or protected by statute or treaty;

·         The domain name is not identical to the mark on which the registrant based its Sunrise registration;

·         The trademark registration on which the registrant based its Sunrise registration is not of national effect (or regional effect) or the trademark had not been court-validated or protected by statute or treaty; or

·         The trademark registration on which the domain name registrant based its Sunrise registration was not issued on or before the effective date of the Registry Agreement and was not applied for on or before ICANN announced the applications received.

 

 

29.7. Trademark Claims Service

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

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

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

 

29.8. URS System

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

 

29.9. UDRP

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

 

29.10. Abusive Use Policy

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

 

29.11. Resourcing Plans

As can be seen in the Resourcing Chart found in Appendix 23.2, during the ongoing operations of the registry, GMO will contribute to the development and maintenance of this aspect of the registry system. This team will not work on specific registry subsystems full-time, but a certain percentage of their time will be dedicated to each area.

Additionally, GMO will draw upon CentralNic’s own team of engineers and developers, as described in the FTE resource assignment described in Appendix 23.3. This contribution is slightly less than one full-time position. CentralNic personnel will work closely with GMO during the initial implementation of the registry, and will provide technical support and advice during ongoing operations through Year 3. CentralNic will provide enhancements to the performance and functionality of the registry system to GMO under the terms of the agreement between the two companies.



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

30(a).1. Introduction

JCB Co., Ltd. has delegated all technical and information processing facilities for jcb to GMO Registry, Inc (GMO). Neither the Applicant, nor any of its officers and staff, nor any of its affiliates, have any access to, or control over, the information processing facilities or critical registry services for jcb, which are operated in their entirety by GMO. Therefore, the response to this question focuses primarily on GMO’s security policies.

The Information Security Management System (ISMS) developed by CentralNic for the registry system used by GMO has been certified against EIC/ISO 27001:2005 by Lloyd's Register Quality Assurance (LRQA), a UKAS accredited certification body. A copy of the certificate issued by LRQA is included in Appendix 30(a).1.

 The ISMS and supporting documents, including the Access Control Policy and others, will be used as the basis for the information security policy for the registry being established by GMO.


30(a).2. Security Policy

GMO promotes a culture of security throughout the whole organization based on the nine generally accepted principles from the OECD's guidelines for the Security of Information Systems and Networks.

In establishing a new registry system for jcb and others, GMO Registry will draw upon the expertise and experience of CentralNic to develop its security policy to meet its obligations as a gTLD Registry Operator. GMO will establish a security policy for jcb based on CentralNic’s ISO 27001-certified security policy, with a view to achieving ISO 27001 certification in the future.


30(a).3. Augmented Security Levels

GMO believes that jcb requires no additional security levels above those expected of any gTLD registry operator. Nevertheless, GMO will operate jcb to a high level of security and stability in keeping with its status as a component of critical Internet infrastructure.

Registry systems are hardened against attack from external and internal threats. Access controls are in place and all systems are monitored and audited to mitigate the risk of unauthorised access, distribution or modification of sensitive data assets. The Authoritative DNS System has been designed to meet the threat of Distributed Denial-of-Service (DDoS) attacks by means of over-provisioning of network bandwidth, and deployment of Shared Unicast ("Anycast") addresses on nameservers. Whois services have been designed with built-in rate limiting and include mechanisms for protection of personal information. The stability of the registry is supported by use of high-availability technologies including a "hot" Disaster Recovery site in San Jose, United States, as well as a backup provider relationship with CentralNic in the United Kingdom.


30(a).4. Commitments to Registrars

GMO will make the following commitments to jcb registrars:


30(a).5. Access Controls

GMO will operate a comprehensive Access Control Policy for the registry system. For example, the web-based Staff Console which will be used to administer the SRS and manage registrar accounts will support a total of ten different access levels, ranging from "Trainee", who have read-only access to a subset of features, to "System Administrator" who have full access to all systems.

Underlying server and network infrastructure will also be subjected to access control. A centralised configuration manager will be used to centrally control access to servers. Individual user accounts will be created, managed and deleted via the configuration server. Access to servers will be authenticated by means of SSH keys: only authorised keys may be used to access servers. Operations personnel can escalate privileges to perform administration tasks (such as updating software or restarting daemons) using the "sudo" command which is logged and audited as described below.

Only operations personnel will have access to production environments. Development personnel will be restricted to development, staging and OT&E environments.


30(a).6. Security Enforcement

Security controls will be continually monitored to ensure that they are enforced. Monitoring will include use of intrusion detection systems on firewalls and application servers. Attempted breaches of access controls (for example, port scans or web application vulnerability scans) will trigger NOC alerts and may result in the execution of the Security Incident Response Policy (see below).

 

30(a).7. Logging and Monitoring

GMO will operate a centralised logging and monitoring system (see §42), analyzing access logs in order to generate access reports which will then be reviewed by NOC personnel. This will include access to servers via SSH, to web-based administration systems, and to security and networking equipment. Unexpected access to systems will be investigated with a view to correcting any breaches and/or revoking access where appropriate.


30(a).8. Security Incident Response Policy

GMO will operate a Security Incident Response Policy which will apply to all events and incidents as defined by the policy, and to all computer systems and networks operated by GMO.

The Policy will provide a mechanism by which security events and incidents are defined (as observable change to the normal behaviour of a system attributable to a human root cause). It will also define the conditions under which an incident may be defined as escalated (when events affect critical production systems or requires that implementation of a resolution that must follow a change control process) and emergencies (when events impact the health or safety of human beings, breach primary controls of critical systems, or prevent activities which protect or may affect the health or safety of individuals).

The Policy will establish an Incident Response Team which regularly reviews status reports and authorises specific remedies. The IRT will conduct an investigation which seeks to determine the human perpetrator who is the root cause for the incident. Very few incidents will warrant or require an investigation. However, investigation resources like forensic tools, dirty networks, quarantine networks and consultation with law enforcement may be useful for the effective and rapid resolution of an emergency incident.

The Policy will make use of GMO’s support ticketing and bug tracking systems to provide a unique ID for the event, and means by which the incident may be escalated, information may be reported, change control processes put into effect, and ultimately resolved. The Policy will also describe the process by which an incident is escalated to invoke an Emergency Response, which involves Lock-Down and Repair processes, monitoring and capturing of data for forensic analysis, and liaison with emergency services and law enforcement as necessary.


30(a).9. Role of the Network Operations Centre (NOC)

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


30(a).10. Information Security Team

GMO will maintain an Information Security Team (IST) to proactively manage information security. The IST will be a cross-functional team from relevant areas of GMO and parent-company GMO Internet. These key members of staff will be responsible for cascading rules, regulations and information to their respective departments. They will also be the first port of call for their departmental staff to report potential security incidences and breaches. The IST will be members of an internal email group used to co-ordinate and discuss security related issues.

The IST will comprise the CEO, CTO, Operations Manager, Senior Operations Engineer and Security Engineer.

IST responsibilities will include:


30(a).11 Auditing and Review

ISO 27001 includes processes for the auditing and review of security systems and policies. Audits are performed annually by an independent assessor. GMO’s IST will periodically review the ISMS and conduct gap analyses, identifying areas where performance does not comply with policy, and where the Risk Assessment has identified the need for further work.


30(a).12. Testing of Controls and Procedures

GMO will conduct bi-annual penetration tests of its registry systems to ensure that access controls are properly enforced and that no new vulnerabilities have been introduced to the system. Penetration tests will include both "black box" testing of public registry services such as Whois and the Registrar Console, "grey box" testing of authenticated services such as EPP, and tests of physical security at GMO’s offices and facilities.

GMO will retain the services of a reputable security testing company. The results of this test will be used in annual reviews and audits of the ISMS.


30(a).13. GMO Security Policies

The following policies relate to GMO’s non-technical facilities such as its offices, rather than to the jcb registry system.

30(a).13.1. Controls on Confidential Data

 

Data that relate to jcb are only accessible by authorized staff. Access to the system is via keys and passwords, no other staff can access the server and cabinets which store backups and confidential physical documents.

 

30(a).13.2. Storage of Records

 

Physical documents will be placed under lock and key accessible only to authorized persons. Regular auditing ensures that all information is secure.

 

Soft-copy data will be kept in a secured server with encryption that will ensure that data is not accessible to any third party. The server will be isolated from the rest of the network at all times to ensure that it is not accessible except for authorized access.

 

 

30(a).13.3. Storage of Credentials

 

Credentials (such as usernames and passwords used to access third-party systems) are stored in a secure online vault application, which uses PKI infrastructure to securely share items with specific users.

 

 

30(a).13.4. Logging of Access

 

Access logs are monitored in a regular basis, all logins are recorded as well as a log sheets that lists the specific times that systems were accessed and the person that accessed the system.

 

 

30(a).13.5. Physical Access Controls

 

Access to GMO’s office is controlled by security gates at the main entrance as well as the sub-entrance. All security gates, as well as the entrances to offices on each floor are secured with contactless IC cards, and access can be restricted to specific floors using the IC card. Visitors receive temporary IC cards by registering at the reception. Human security personnel are located at the gate 24x7.

 

 

30(a)13.6. Physical Security

 

 

30(a).13.6.1. Buildings

 

·         Security, Access Control and CCTV

·         Cameras installed at every entrance and at the perimeter of the facility

·         Security access control is centralized

·         Fence surrounds the facility backed up by security patrols.

·         Logbook at entrance for records of all entrances into the Premises

 

30(a).13.6.2. Offices

 

·         Proximity card with pin grants access to authorized personnel only.

·         Cameras installed at every entrance into the building

 

 

30(a).13.6.3. Computer Equipment

 

·         Proximity card with pin grants access to authorized personnel only.

·         Every user has a designated workstation with monitored network access.

·         Each workstation, laptop and tablet is password protected, and all passwords are changed regularly in line with policy.

 

 

30(a).13.6.4. Network Equipment and Infrastructure

 

·         Equipment is located in a secured area that has an electric door with Logbook at the entrance for records of entry into the data centre.

·         No staff are allowed to access equipment except authorized engineers

·         Proximity card with pin grants access to authorized personnel only.

·         All network infrastructure is secured in trunking and conduits, routine maintenance ensures that trunking is well secured and intact

·         Wireless transmitters are placed beyond reach and well secured in braces.

 

 

30(a).13.6.5. Portable Media

 

·         Staff are assigned USB sticks that are only authorized for internal storage and transfers.

·         No portable media that belongs to company is allowed outside without express permission

 

 

30(a).13.6.6. Physical Documents

 

·         Each business unit has a designated cabinet where they keep documents under lock and key

·         All company documents are required to be filed and archived as necessary in chronological order. 

·         Access to these files is restricted to the said business unit unless by express authorization from the unit manager

 

 

30(a).13.7. Network Access Controls

 

·         Network equipment is located in a secured area that has an electric door with Logbook which records all entry into the data centre.

·         No staff are allowed to access equipment except authorized engineers

·         All workstations, laptops, tablets, and printers are configured not to allow access to network settings except to the network administrator.

·         Firewalls, routers and all network equipment have secured passwords that are changed regularly

·         Each business unit has its own VPN which restricts users from access beyond their own VPN

·         Users have access times and tickets which ensure that no one can access devices except during authorized hours.

 

 

30(a).13.8. Malware

 

·         Staff are not allowed to access websites that are not work related and an access log for each PC is produced periodically to check this.

·         Scanning for malware is required for media from outside of the organization  before it can be used.

·         Email file attachments, including compressed files (e.g., .zip files), must be saved to local drives or media and scanned before they are opened.

·         The sending or receipt of certain types of files (e.g., .exe files) via email is prohibited and certain additional file types are blocked for a period of time in response to an impending malware threat.

·         Use of unnecessary software, such as user applications that are often used to transfer malware (e.g., personal use of external instant messaging, desktop search engine, and peer-to-peer file sharing services), and services that are not needed or duplicate the organization-provided equivalents (e.g., email) and might contain additional vulnerabilities that could be exploited by malware is restricted or forbidden.

·         The use of administrator privileges by users is restricted, which limits the privileges available to malware introduced to systems by users.

·         Systems must be kept up-to-date with OS and application upgrades and patches

·         The use of removable media (e.g., floppy disks, compact discs, USB flash drives) is restricted, particularly on systems that are at high risk of infection.

·         The types of preventive software (e.g., antivirus software, spyware detection, and removal utilities) required for each type of system (e.g., file server, email server, proxy server, workstation, personal digital assistant [PDA]) and application (e.g., email client, Web browser) are specified, and the high-level requirements for configuring and maintaining the software are listed.

·         Access to other networks (including the Internet) is permitted only through organization-approved and secured mechanisms

·         Firewall configuration changes must be approved through a formal process

·         The types of mobile code may be used from various sources (e.g., internal Web servers, other organizations’ Web servers) is specified.

·         The use of mobile devices on trusted networks is restricted.

·         All workstations, laptops and servers are installed with antivirus software which automatically updates virus signature files to detect malicious software.

 

 

30(a).13.9. User Accounts and Passwords

 

·         All the devices that are connected to the network are accessed via a domain logon which mean that they must connect to a domain and cannot be accessed as standalones except during repairs and maintenance by authorized staff.

·         Users are not allowed to have the same password on multiple systems.

·         Account Lockout Policy settings disable accounts after a specific number of unsuccessful logins. Disabled accounts can then be restored by the system administrator after proper explanation of the reasons why account was disabled.

·         The system has an enforceable password history to ensure that all new passwords are unique, also there is a maximum password age after which the user is required by the system to automatically change passwords.

·         Passwords must meet complexity requirements, i.e. contain uppercase, lowercase, numerals, non-alphanumeric and Unicode characters. This ensures that all passwords are strong enough.

·         All accounts and devices connected to specific domains are subject to a routine audit to ensure that vulnerabilities and illegal attempts to log in are mitigated and assessed.

 

 

30(a).13.10. Communications with Stakeholders

 

·         GMO has in place mechanisms to enable unrestricted access to the local law enforcement officers that are in proximity to the organizations offices.

·         GMO will establish a code of communication and format with which to reach ICANN as the authority , these communications will include mandatory routine communications required between the registry and ICANN as per normal registry operations

·         In conjunction to above normal operations, GMO intends to communicate to ICANN in cases where there is need for urgent mitigation measures arising from issues related to running of registry, conflicts and all other issues that may arise in the course of normal business.

·         GMO will keep a log of all relevant emails, fax and telephone numbers to be used appropriately for each communication.

·         Alternative ways to complete all remittances have been made in advance should the normal authorized channels be unavailable due to unavoidable circumstances to ensure that all regular operations are sustained.

·         In cases where such measures cannot be carried out completely, appropriate notifications shall be made to ICANN or any other affected persons in advance to explain failure to perform the regular actions thereof via email.




© Internet Corporation For Assigned Names and Numbers.