ICANN New gTLD Application

I. WHAT IS THE GOAL OF YOUR PROPOSED GTLD IN TERMS OF AREAS OF SPECIALTY, SERVICE LEVELS, OR REPUTATION?

Specialty
.suzuki is a TLD for SUZUKI and its stakeholders (i.e. SUZUKI and companies listed on the securities reports of SUZUKI). .suzuki is different from other common TLDs in that second level domain name registrations will not be open to the public. .suzuki is a company⁄brand TLD, which is a new type of TLD that is expected to have increased marketing and branding power. Registrants of .suzuki domain names will be pioneers in benefitting from the value of a company⁄brand TLD. Also, all information sent or published from .suzuki will be official and that means the information is dependable. .suzuki directly expresses the name of the company⁄brand, making it easy to remember and associate with products and services of SUZUKI and its brand names. SUZUKI hopes that the .suzuki character string will be easy-to-understand, easy-to-remember and that people recognize it as trustworthy.

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

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

II. WHAT DO YOU ANTICIPATE YOUR PROPOSED GTLD WILL ADD TO THE CURRENT SPACE, IN TERMS OF COMPETITION, DIFFERENTIATION, OR INNOVATION?

SUZUKI believes that company⁄brand name TLDs such as .suzuki will promote competition, differentiation, and innovation for domain name registrants, internet users, and business.

.suzuki is a new type of TLD in that the top-level string, not the second level, represents the company⁄brand name. It has several important elements of a good Internet address: direct, simple, easy-to-understand, and memorable. These elements are also important for marketing and branding activities, therefore SUZUKI expects that the TLD will play a stronger part than ever in marketing activities.

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

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

III. WHAT GOALS DOES YOUR PROPOSED GTLD HAVE IN TERMS OF USER EXPERIENCE?

In terms of user experience, .suzuki aims to provide a name space
1. where Internet users can access information on SUZUKI safely and effectively,
2. where Internet users can discover new things about SUZUKI, and
3. that Internet users recognize as meaningful and trustworthy.

IV. PROVIDE A COMPLETE DESCRIPTION OF THE APPLICANT’S INTENDED REGISTRATION POLICIES IN SUPPORT OF THE GOALS LISTED ABOVE.

In order to achieve the goals stated above, the plans for .suzuki domain name registration policies are as follows. All .suzuki TLD registrars and registrants must agree to abide by the policies. Failure to comply with the policies may result in denial, cancelation or transfer of any registration or transaction, or domain name being placed on lock, hold or similar status.

Registration Eligibility
Domain name registrations for .suzuki will be limited to the following organizations:
1. SUZUKI MOTOR CORPORATION
2. Companies listed on the asset securities reports of SUZUKI MOTOR CORPORATION

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

Verification of Registration Eligibility
Registration and management of .suzuki domain names will be via the .suzuki dedicated account provided by a .suzuki accredited registrar. Access to the .suzuki 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 applicant, and organizations that wish to apply for a .suzuki dedicated account will be required to provide proof of registration eligibility to the applicant via a .suzuki accredited registrar. All .suzuki domain name registration phases are subject to the verification. Proposed valid forms of documentary proof include, but are not limited to,
- company seal (registered or unregistered)
- signature of management staff

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

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

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

- Illegal or fraudulent activities;
- Phishing;
- Pharming;
- Using or distributing malicious software (malware);
- Sending unsolicited bulk messages (spam);
- Posting, trading, or exchanging information that harms minors; and
- Posting information that is offensive to public order or morals.

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

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

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

URS System
The applicant is committed to adopting and abiding by the URS System for trademark owners who seek a rapid system to take down domain names which infringe on their rights.

UDRP
UDRP is applicable to all .suzuki domain name registrations.

V. WILL YOUR PROPOSED GTLD IMPOSE ANY MEASURES FOR PROTECTING THE PRIVACY OR CONFIDENTIAL INFORMATION OF REGISTRANTS OR USERS? IF SO, PLEASE DESCRIBE ANY SUCH MEASURES.

.suzuki will comply with the applicable laws of Japan, as well as applicable ICANN consensus policies. As part of its responsibility as the registry operator of the .suzuki TLD, the applicant will exercise due care to protect all information it receives from registrants or users through registrars, with the exception of registration data to be published on Whois.

The .suzuki registration policies only allow registrations by companies and not individuals. As such, the applicant will publish on Whois all information required by ICANN as it regards all required information to be public. The applicant believes that it is important to maintain Whois data accuracy, and no Whois protection service of any kind will be allowed.

DESCRIBE WHETHER AND IN WHAT WAYS OUTREACH AND COMMUNICATIONS WILL HELP TO ACHIEVE YOUR PROJECTED BENEFITS.

.suzuki is intended exclusively for SUZUKI MOTOR CORPORATION and its stakeholders. Therefore, SUZUKI will direct its outreach and communications efforts towards raising awareness of the .suzuki identity among Internet users. By consolidating the company-related domain names under the .suzuki umbrella, SUZUKI hopes to gain mindshare of the .suzuki TLD among users, thereby contributing to the projected benefits stated above.

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

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

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

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

1.     In order for specific country and territory names to be released and become available for SUZUKI and its stakeholders to register, the applicant shall submit a proposal letter to ICANN and the GAC including, at minimum, the following:
A.    The list of country and territory names which the applicant requests for release; and
B.    Purpose of releasing the names listed above;

2.     ICANN and the GAC review the proposal letter and inform of the proposal to the relevant government(s);

3.     Each of the relevant governments takes the following action:
A.    If the government approves or does not object to the proposal, it replies with its decision of “approval” or “non-objection” by a due date set and agreed upon by ICANN, the GAC, and the applicant; or
B.    If the government does not approve the proposal, it replies with a “non-approval” decision by a due date set and agreed upon by ICANN, the GAC, and the applicant.

4.     If a reply is not received by the due date agreed upon by ICANN, the GAC and the applicant, or the government replied with an “approval” or “non-objection” decision, the names may be released for registration.

5.     In case the government replied with a “non-approval” decision, the government and the applicant may enter negotiation to attempt to reach agreement, and only upon reaching agreement shall the names be released.

6.     Potential registrants of the names shall send registration requests to the applicant. The request must include the following information:
A.    Domain name(s) the registrant wishes to register;
B.    A pledge the registrant understands the purpose and rules of the domain name registration and use included in the proposal letter described 1.A. above; and
C.    A pledge the registrant abides by the purpose and rules of the domain name registration and use included in the proposal letter described 1.A. above;

7.     The applicant reviews the request and checks availability of the requested name. In case the applicant approves the request, it issues a “code.”
Note: The availability check is conducted to see whether the requested domain name has been already requested and registered by another registrant.

8.     Using the code, the registrant requests the domain name registration through a .suzuki accredited registrar.

1. Overview

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

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

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

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

2.1 EPP Service

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

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

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

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

2.2 Web Management Interface

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

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

2.2.1 Functions

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

3. Dissemination of TLD Zone Files

3.1 DNS

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

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

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

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

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

4. Registration Data Publication Services

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

4.1 Registration Data Directory Services (Whois)

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

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

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

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

4.2 Zone File Access

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

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

4.3 Bulk Registration Data Access by ICANN

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

5. Registry Data Escrow

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

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

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

7. Internationalized Domain Name (IDN)

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

- Japanese (tag: ja)

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

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

8. Policies

8.1 Grace periods

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

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

Details are described in Question 27 “Registration Lifecycle”.

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

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

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

9. Rights Protection Services

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

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

2. Architecture

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

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

2.1. Provisioning interfaces

2.1.1. EPP Interface

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

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

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

2.1.2. Web Management Interface

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

2.2. Internal components

2.2.1. Application Server

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

2.2.2. SRS Database

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

2.3. Interfaces to other registry systems

2.3.1 DNS Publication Subsystem

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

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

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

2.3.2. Whois Publication Subsystem

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

2.3.3. Billing & Reporting Subsystem

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

2.3.4. Data Export Subsystem

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

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

3. Infrastructure

3.1. Sites

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

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

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

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

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

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

3.1.1 SRS Primary Site

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

Location: Tokyo
Equipment manifest:

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

3.1.2. SRS Hot Standby Site

Location: Sydney
Equipment manifest:

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

3.2. Synchronisation Scheme

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

3.2.1. SRS Database

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

3.2.2. Whois Database

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

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

3.2.3. Zone Data

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

3.2.4 Applications and Configurations

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

3.3 Network

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

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

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

4. SRS Performance

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

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

4.1. Availability

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

4.2. EPP Command Response Times

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

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

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

4.2.1. Service Level Parameters

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

4.2.1.1. EPP Query Command RTT

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

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

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

4.2.1.2. EPP Session Command RTT

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

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

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

4.2.1.3. EPP Transform Command RTT

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

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

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

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

4.3. Capacity

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

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

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

5. Resourcing Plans

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

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

5.1. Initial Implementation

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

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

5.2. Ongoing Maintenance

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

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

1. Overview

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

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

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

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

2. Architecture

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

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

EPP and Application Servers Architecture

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

2.1. Front End Servers

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

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

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

2.2. Back End Application Servers

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

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

EPP and Application Servers Interaction

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

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

3. Interface Specification

3.1. Transport

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

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

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

3.2. Base EPP Standards

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

3.3. Extensions

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

3.3.1. RFC 3915 - Grace Period Mapping

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

3.3.2. RFC 5910 - DNSSEC Mapping

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

3.3.3. Launch Phase Mapping

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

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

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

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

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

3.3.4. IDN Extension

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

4. Operations

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

5. Resourcing Plans

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

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

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

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

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

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

1. Overview

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

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

2. Compliance

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

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

3. Whois System Description

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

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

3.1. Whois Publication Subsystem

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

3.2. Whois Service Network

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

3.2.1. Whois Instances

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

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

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

3.3. Interconnectivity with Other Registry Systems

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

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

3.3.1. Update Frequency

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

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

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

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

3.4. Abuse Prevention

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

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

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

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

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

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

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

RDDS Anycast Network

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

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

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

The Whois instance infrastructure is depicted below.

RDDS Node Infrastructure

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

5. Resourcing Plans

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

5.1. Initial Implementation

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

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

5.2. Ongoing Maintenance

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

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

Overview

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

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

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

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

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

EPP Statuses

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

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

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

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

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

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

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

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

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

Grace Periods

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Overlapping Grace Period

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

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

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

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

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

Pending Periods

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

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

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

Resourcing Plan

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

Initial Implementation

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

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

Ongoing Maintenance

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

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

In order to safeguard the security and stability of .suzuki, as well as the Internet at large, SUZUKI Motor Corporation (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:

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


Pre-Verification of Registration Eligibility

.suzuki is a domain for SUZUKI Motor Corporation 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 .suzuki registration phases.

Registration and management of .suzuki domain names will be carried out via the .suzuki dedicated account provided by a .suzuki accredited registrar. Access to the .suzuki 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 .suzuki dedicated account will be required to provide proof of registration eligibility to the registry via a .suzuki 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 .suzuki dedicated account, through which it may apply for multiple .suzuki 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 .suzuki 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.


Draft Abusive Use Policy

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

-	Illegal or fraudulent activities;
-	Phishing;
-	Pharming;
-	Using or distributing malicious software (malware);
-	Sending unsolicited bulk messages (spam);
-	Posting, trading, or exchanging information that harms minors; and
-	Posting information that is offensive to public order or morals.

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


Abuse Public Contact Information

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

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


Abuse Complaint Form

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


Draft Takedown Procedure

-	Complaint is submitted using the abuse complaint form via email or the registry web site;
-	Upon receiving a complaint, the registry’s operational and registrar support team will
	assign a ticket number
	review complaint form
- request additional information if complaint form is deemed insufficient to carry out effective investigation
	investigate the complaint to verify accuracy, and to record proof of abuse
	based on the nature of the abuse, assign level of severity: normal or emergency
- Emergency: the registry will suspend the domain name in question and close the complaint ticket. At the same time, it will open a ticket to inform the sponsoring registrar of the suspension along with the reason.
- Nomal: open a ticket to inform the sponsoring registrar to take corrective actions. The registrar must inform the registry of actions taken. If the registrar does not take any action (that includes no response from the registrar) within a reasonable timeframe, the registry will suspend the domain name in question and close the complaint ticket.
	If the domain name was suspended by the registry, and the situation is remedied by the registrant, the registrar will contact the registry via the ticket number. The registry operational and registrar support team will verify that the issue has indeed been remedied and re-enable the domain name, closing the ticket.
	All actions by the operational and registrar support team will be logged

The registry understands that the Registration Abuse Policies Working Group has been working on developing best practices for registries and registrars addressing the fraudulent use of domain names. The registry will closely follow the working group discussions and documents, with a view of adopting the best practices to enhance abuse mitigation capabilities.
 
In addition, the registry will participate in security forums to keep track of the latest developments in abuse mitigation best practices and refine our abuse policies and procedures from time to time.


Orphan Glue Records

The registry’s view on orphan glue records is consistent with the Security and Stability Advisory Committee Comment on Orphan Glue Records
 〈http:⁄⁄www.icann.org⁄en⁄committees⁄security⁄sac048.pdf〉. The registry supports the use of orphan glue records for legitimate purposes. Upon receiving a complaint relating to an orphaned glue record used in connection with malicious activities, the registry will verify and take corrective actions in accordance with its takedown procedures.


Resourcing Plans

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

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


Initial Implementation

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

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


Ongoing Maintenance

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


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

SUZUKI Motor Corporation (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


Pre-Verification of Registration Eligibility

Since .suzuki is a domain for SUZUKI Motor Corporation 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 .suzuki registration phases.

Registration and management of .suzuki domain names will be carried out via the .suzuki dedicated account provided by a .suzuki accredited registrar. Access to the .suzuki 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 .suzuki dedicated account will be required to provide proof of registration eligibility to the registry via a .suzuki 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 .suzuki dedicated account, through which it may apply for multiple .suzuki 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 .suzuki 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.


Sunrise Registration Process

Before any registration of .suzuki 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 .suzuki domain names registered during the Sunrise Registration and all .suzuki TLD registrars and registrants must agree to abide by the SERs and SDRP

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

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

Other Rules for Sunrise Registration Process
-	The Sunrise Registration Process will be run for at least 30 days which is the period required by ICANN. However, the registry may run the process longer at its own discretion.
-	During the Sunrise Registration Process, a domain name can be registered for 2-10 years.
-	Multiple validated applications for the same domain name will be resolved on a first-come-first-served basis.
-	Deletion, renewal, and transfer of a Sunrise domain name will be prohibited for 60 calendar days after the domain name is successfully registered.

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


Trademark Claims Service

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

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

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


URS System

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


UDRP

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


Abusive Use Policy

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


Resourcing Plans

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

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

Initial Implementation

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

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

Ongoing Maintenance

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

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

1. Overview

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

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

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

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

GMO Registry promotes a culture of security throughout the whole organization based on the nine generally accepted principles from the OECDʹs guidelines for the Security of Information Systems and Networks. Whilst not intending to be certified, GMO Registry implements many of the ISO⁄IEC 27001 and ISO⁄IEC 27002 security controls.

Security Levels and Commitments

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

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

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

3. Summary of Security Policies

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

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

- Availability
- Integrity
- Confidentiality
- Accountability

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

SCOPE

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

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

RESPONSIBILITIES OF OWNERS, CUSTODIANS, AND USERS

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

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

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

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

SYSTEM AND NETWORK ACCESS CONTROLS

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

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

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

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

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

SYSTEM AND NETWORK CHANGES

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

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

AVAILABILITY

All critical registry services are delivered utilizing fault tolerant mechanisms.

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

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

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

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

BACKUPS

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

INCIDENT DETECTION AND RESPONSE

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

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

INTERNAL SYSTEMS COMMUNICATIONS AND DATA EXCHANGE

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

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

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

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

4. Summary of Security Procedures

INDUCTION AND TRAINING

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

SYSTEM AND NETWORK ACCESS CONTROLS

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

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

SYSTEM AND NETWORK CHANGES

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

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

CONTINUITY AND FAILOVER TESTING

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

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

MONITORING

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

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

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

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

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

Eiji Mochizuki	Director and Senior Managing Officer
Masanori Atsumi	Director and Senior Managing Officer
Minoru Tamura	Representative Director and Executive Vice President
Naoki Aizawa	Director and Senior Managing Officer
Osamu Honda	Representative Director and Executive Vice President
Osamu Suzuki	Chairman & CEO
Shinzo Nakanishi	Director and Senior Managing Officer
Toshihiro Suzuki	Representative Director and Executive Vice President
Toyokazu Sugimoto	Director and Senior Managing Officer
Yasuhito Harayama	Representative Director and Executive Vice President

Eiji Mochizuki	Director and Senior Managing Officer
Masanori Atsumi	Director and Senior Managing Officer
Minoru Tamura	Representative Director and Executive Vice President
Naoki Aizawa	Director and Senior Managing Officer
Osamu Honda	Representative Director and Executive Vice President
Osamu Suzuki	Chairman & CEO
Shinzo Nakanishi	Director and Senior Managing Officer
Toshihiro Suzuki	Representative Director and Executive Vice President
Toyokazu Sugimoto	Director and Senior Managing Officer
Yasuhito Harayama	Representative Director and Executive Vice President

New gTLD Application Submitted to ICANN by: SUZUKI MOTOR CORPORATION

String: suzuki

Originally Posted: 13 June 2012

Application ID: 1-1858-80460

Applicant Information

1. Full legal name

2. Address of the principal place of business

3. Phone number

4. Fax number

5. If applicable, website or URL

Primary Contact

6(a). Name

6(b). Title

6(c). Address

6(d). Phone Number

6(e). Fax Number

6(f). Email Address

Secondary Contact

7(a). Name

7(b). Title

7(c). Address

7(d). Phone Number

7(e). Fax Number

7(f). Email Address

Proof of Legal Establishment

8(a). Legal form of the Applicant

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

8(c). Attach evidence of the applicant's establishment.

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

Mission/Purpose

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

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

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

Community-based Designation

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

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

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

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

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

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

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

Geographic Names

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

Protection of Geographic Names

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

Registry Services

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

Demonstration of Technical & Operational Capability

24. Shared Registration System (SRS) Performance

25. Extensible Provisioning Protocol (EPP)

26. Whois

27. Registration Life Cycle

28. Abuse Prevention and Mitigation

29. Rights Protection Mechanisms

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

© Internet Corporation For Assigned Names and Numbers.