Back

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

gTLDFull Legal NameE-mail suffixDetail
.sakuraSAKURA Internet Inc.sakura.ad.jpView
23.1. Definition
For the purpose of this answer, we have defined the following in the alphabetical order:

-Critical Registry Functions:
Functions that are critical to the operation of a gTLD registry:
1) Domain Name System (DNS) Resolution
2) Domain Name System Security Extensions (DNSSEC)
3) Shared Registration System (SRS) by means of the Extensible Provisioning Protocol (EPP)
4) Registration Data Publication Service by means of the WHOIS protocol
5) Registry Data Escrow

Domain Name Users:
The users of ʺ.sakura:ʺ SAKURA Internet will be the users of the gTLD.

SAKURA:
Japanese Cherry Blossoms

SAKURA Internet:
SAKURA Internet Inc. (Tokyo Stock Exchange MOTHERS:3778)

.sakura Registrant:
The registrant of ʺ.sakura:ʺ SAKURA Internet Inc. is the sole registrant of the gTLD.

.sakura Registrar:
An ICANN accredited Registrar for .sakura:SAKURA Internet will designate the registrar.

.sakura Registry Operator:
The registry operator which will operate the front and back-end registry services and necessary operations to support those services:SAKURA Internet intends to outsource the registry operation to a particular third party.

SLD (s) :
The Second Level Domain (s)

23.2. Introduction
SAKURA Internet is one of the leading data center services providers in Japan, and our proposed concept of ʺ.sakura Initiativesʺ is a significant opportunity for SAKURA Internet. The proposed concept (goals) of the ʺ.sakura Initiativesʺ encompass several ideas: (A) protecting the momentum of our business growth and 16 years worth of our penetration with the ʺSAKURAʺ internet brand, by applying ICANN for ʺ.sakura;ʺ (B) leveraging ʺ.sakuraʺ effectively to achieve advanced user-friendliness and to gain the loyalty of our customers for the purposes of consumer trust and choice; (C) taking advantages of a safer and more secure domain name environment by providing ʺ.sakuraʺ for the purposes of creating new projects and conducting various research and studies; and (D) implementing an environment where we plan =〉 develop =〉 commercialize new features to establish an optimized and most advanced ʺservice value chain,ʺ by adopting ʺ.sakuraʺ for the purpose of promoting robust competition.

In our initial stage of this plan, SAKURA Internet will implement the eight main services, on the premise of providing registrations for .sakura SLDs.
We believe that by providing a comprehensive range of proposed registry services, SAKURA Internet will be able to support and achieve our defined objectives for .sakura.

23.3. Our Premise:Business Considerations
*We intend to utilize .sakura effectively for improving the vital use, promoting, expanding and growing the new gTLD as well as our existing TLDs.

*SAKURA Internet will be the sole Registrant of the proposed .sakura, and we will primarily control the use of the SLDs by our own registration policies and through a process of qualification, restricting the use within ourselves. Therefore, as an assumption, we expect no multiple domain name applications for the same name space. Example of the SLDs:rentalservername.sakura, r&dprojectname.sakura

*As we have the liberty of selecting a Registrar for .sakura at our discretion from the existing ICANN Accredited Registrars, we plan to identify and appoint a Registrar of our choice, and outsource our entire Registry operations for the proposed .sakura. Registry Services are further explained in the answer for #23 (Registry Services).

*SAKURA Internet will offer initial domain name registration for a period of 1 to 10 years, complying with the Registry Agreement. We do not intend to charge for the .sakura registrations; however, should we decide to charge fees for the registrations, we will notify the Registrar in advance, as per the Registry Agreement.

*Our measures to protect the privacy and confidential information of the .sakura users are explained in the answers for #30 (Security).

*As per the cost benefits of .sakura, we anticipate the most impact on our core business domain⁄market. We will take full and direct advantage in maintaining our branded business momentum. Meanwhile, by using .sakura proactively, we will encourage the domain name markets to expand the new gTLD and the existing TLDs. Consequently, we anticipate the impacts and influences in ʺcreating future valuesʺ by improving the vital use and expanding the scale of the domain name usage.

*In terms of the benefits offered to the customer market, .sakura will promote customer trust and choice (for both business and consumer) by simplified domain names and easier internet search and access, and by exclusive and authenticated access to the correct and desired information (by more direct keyword ʺgTLDstringʺ search). For specific descriptions of the purposes and benefits, please see ʺ6. OUR OBJECTIVES & PURPOSESʺ

*As described in #18.9 (OUR EFFORTS ON .sakura EXPANSION), we believe our proposed marketing and public relations activities, as well as our communications outreach, are efficient and effective measures to achieve our projected benefits.

*SAKURA Internet projects the number of .sakura SLD registrations, based on the existing services offered, to be around 10 during the initial year, 20 during the second year, and 100 in the third year. Even with a maximum estimation, the numbers may increase up to no more than 1000 during the planned three years.

23.4. Intended Services⁄Functions:Technical Considerations
As SAKURA Internet being the sole registrant, at its own discretion, we will choose a Registrar for .sakura among the ICANN accredited registrars, who should be able to manage and operate an evaluation process to qualify the potential users and objectives, and should be capable of operating the .sakura Registry.

Given the business considerations and our specific objectives along with the continued ongoing evolution of the domain name market, SAKURA Internet proposes a following comprehensive range of registry services to support .sakura, which are almost universal across most if not all the gTLDs.
1. Domain Name Registration and Renewal
2. Transfer of Registration between Registrars
3. Name Server and Zone File Administration
4. Operation of WHOIS Database
5. Registrar Support Services
6. Data Escrow
7. DNSSEC
8. Internationalized Domain Names

23.4.1. Domain Name Registration and Renewal
One of the most basic services that a Registry Operator provides is the registration and renewal of a domain name. We intend the Domain Name Registration of .sakura to be a FSFC registration registered in one year annual increments for up to a maximum of ten (10) years. SAKURA Internet will also provide the ability to renew a domain in annual increments. Details of Registration Life Cycle of .sakura are described in the answer for #27 (Registration life cycle).
This Registry Service will be provided by accessing the Shared Registry System (SRS) through a securing SSL connection using the Extensible Provisioning Protocol (EPP) that ICANN has mandated for all new gTLD operators. There are various EPP commands involved in registering⁄maintaining a domain name which are identified in more detail in the answer for #25.1 (EPP).

23.4.2. Transfer of Registration between Registrars
Since the creation of ICANN, there has been a dichotomy within the domain name marketplace between Registrars and Registries. Domain name portability, the ability of a Registrant to transfer sponsorship of a domain name at the Registry Operator from one Registrar to another Registrar, has been one of ICANNʹs initial success stories.
To safeguard a Registrantʹs ability to transfer sponsorship of a domain name between Registrars, ICANN has adopted a consensus policy (ICANN Consensus Policy) that largely regulates the domain name transfer process between a Gaining and Losing Registrar. This policy specifically sets forth the limited circumstances in which a Losing Registrar can deny a transfer request, as well as dispute providers that have been approved to administer the Transfer Dispute Resolution Policy.
Reference
Approved Providers for Transfer Dispute Resolution Policy
http:⁄⁄www.icann.org⁄en⁄dndr⁄tdrp⁄approved-providers.htm
Policy on Transfer of Registrations between Registrars (Revision Adopted November 7, 2008, Effective March 15, 2009)
http:⁄⁄www.icann.org⁄en⁄transfers⁄policy-en.htm
SAKURA Internet will adopt the use of the ʺAuth Info codesʺ coupled with the implementation of ʺICANN Consensus Policyʺ recommendations that has mitigated the number of hijacking incidents. The ʺAuth Infoʺ safeguard is largely dependent upon a Registrant being able to control access and assignment of unique ʺAuth Info codes.ʺ
SAKURA Internet will also provide the Bulk Transfer service for .sakura, which is a mandated Registry Service set forth in ICANNʹs Consensus Policy on Transfer of Registrations between Registrars (following is an excerpt from the policy) :
Registry Operator shall make the necessary one-time changes in the Registry database for no charge, for transfers involving 50,000 name registrations or fewer. If the transfer involves registrations of more than 50,000 names, then the Registry Operator shall charge the gaining Registrar a one-time flat fee of US$ 50,000.

23.4.3. Nameserver and Zone File Administration
This is the primary self-service function that the Registry provides for the consumer to use directly. If this service fails, then the TLD will essentially go dark on the Internet. SAKURA Internet will offer the Name Server and the zone file administration services with the best practice adopted by the existing gTLD Registry Operators. The technical considerations for .sakura in connection with the name server and the zone file administration are explained in the answer for #35 (DNS service compliance).
Historically, ICANN accredited registries have been required to provide bulk zone file access to third parties that requested such data at no cost, on terms set forth in all incumbent ICANN registry agreements. SAKURA Internet will provide the Bulk Zone File Access service to users. More details on Bulk Zone File Access are described in the answer for #26 (Whois).

23.4.4. Operation of Whois Database
All Registry Operators are required to provide both Web-based and port 43 interfaces to the registryʹs Whois database servers.
SAKURA Internet will provide public access to the Whois database servers as required under the Registry Agreement.
SAKURA Internet will ensure that those servers will be a part of the Registry Architecture, detailed in the answers for #24 (SRS performance) and #26 (Whois), focused on redundancy. In connection with the Web-based and port 43 interfaces, SAKURA Internet will employ reasonable safeguards to prevent the mining of Whois data through high volume queries. Please refer to the answer for #28 (Abuse prevention & mitigation) and #29 (Rights protection mechanisms) with regard to maintaining redundancy of Whois.
As described in #23.3 (Our Premise:Business Considerations), SAKURA Internet will apply its own evaluation criteria to review and evaluate the potential users and objectives, and SAKURA Internet will register only the qualified second level domain names⁄strings. Additionally, we will be able to provide the most current and accurate .sakura contact information through the Whois search, because the .sakura users will mainly be the SAKURA Internet itself.

23.4.5. Registrar Support Services
The implementation of Registrar Support Services will be limited, due to the fact that SAKURA Internet, having the liberty of selecting an ICANN accredited Registrar for .sakura at its own discretion, plans to choose a specific Registrar that is capable of managing and operating the .sakura proprietary evaluation process to qualify the potential users and objectives. However, in the event that we provide the Registrar Support Services for multiple ICANN accredited registrars sometime in the future, we will provide the following support services to the selected Registrars:
A) Registrar OT&E:
As a prerequisite for Registry Operatorʹs granting an ICANN Accredited Registrar access to the SRS, SAKURA Internet will facilitate (test and certify) the Operational Test and Evaluation (OT&E) certification process for the Registrars.
B) Registry Operatorʹs Website:
SAKURA Internet will provide access to Registry Operatorʹs Website for Registrars to download various support documentations. In order to secure the access to the Website, each Registrar will be assigned a user ID and password.
While EPP provides a polling function for some transactions, most Registrar reports are accessible through a secure web-based portal.

23.4.6. Data Escrow
This is a mandated Registry Service incorporated into the baseline Registry Agreement by ICANN to ensure the security and stability of Registry Operations for the benefit of Registrants and the broader Internet community. The technical criteria associated with the data escrow requirements are set forth in the Specification 2 of the ʺICANN draft new gTLD Registry Agreement.ʺ More details on Registry Service for .sakura are set forth in the answer for #38 (Escrow).

23.4.7. DNSSEC
This is a mandated Registry Service in accordance with Specification 6 of the ʺICANN draft new gTLD Registry Agreement.ʺ SAKURA Internet adopts DNSSEC into .sakura. The technical implementation of DNSSEC is explained in the answered for #43 (DNSSEC).

23.4.8. Internationalized Domain Names
SAKURA Internet will support IDN in .sakura in a fully standards-compliant fashion at the time of transition. SAKURA Internet has implemented IDN in Japanese, and in line with ICANN guidelines and IETF standards.
The Japanese language will be used for .sakura and the IDN tables, presented in the answer for #44 (IDNs), and will be provided as required for the second level domain. SAKURA Internet has been offering the IDN for .jp for more than 10 years, and there are approximately 120,000 IDNs currently registered in .jp Detailed considerations of IDN are described in the answer for #44 (IDNs).

23.5. Security ⁄ Stability
As we strive for achieving our objectives⁄goals for .sakura, SAKURA Internet will apply the most appropriate information security measures and provide safe registry services to the users.
SAKURA Internet acknowledges that protecting the registrant information and ensuring 100% availability of DNS services are critical. Hence, we will implement extensive security measures to protect information confidentiality, safety and high availability in practice for .sakura registry services.
Below, we have listed the major categories of our planned security measures for .sakura registry services:
* Network Control and Access Control
* Secure network communications and data encryption
* Digital data signature and DNSSEC Resolution
* Software, hardware and network architectures, as well as multi-site redundancy
For more detailed information about the .sakura security, please see the answer for #30 (Security).
In the following sections, we will describe the security and stability considerations for the provided services and functions.

23.5.1. Domain Name Registration and Renewal
As SAKURA Internet will be the sole registrant and the user of .sakura, concerns on unauthorized access to .sakura will be limited by security protocols in place.
As per the users of .sakura second level domain, we will apply our proprietary evaluation criteria to review and evaluate the potential users and objectives, and SAKURA Internet will register only the qualified second level domain names⁄strings. Therefore, we believe that we will be able to avoid unauthorized access and abusive uses.
We are confident that the operational system that we will outsource, in connection with domain names registrations and renewals will handle the various business use cases. SAKURA Internet will select an experienced Registry Operator for the entire registry operations, and it is one of our prerequisites to be selected as our Registry Operator to have an SLA which will address all the requirements and considerations pertaining potential security and stability issues.
SAKURA Internet will not rely on a third party validation agent. Therefore, the concerns relative to ensuring the security of electronic communications will be minimized and not subject to interception and or manipulation.
Although there should be no security⁄stability concerns beyond those referenced in the ʺStandard Domain Name Registration Service,ʺ SAKURA Internet acknowledges that it may have to exercise some enhanced security protocols when transferring EPP Auth Codes to successful Registrants to allow them to transfer the domain name to a registrar of their choice.
SAKURA Internet will work to determine the best technical implementation to address the business needs of the .sakura registry. In addition, SAKURA Internet will ensure that the security and stability weaknesses identified in the SSAC reports are proactively addressed for the benefit of SAKURA Internet and .sakura users.

23.5.2. Transfers of Registration between Registrars
The Auth Info safeguard is largely dependent upon a Registrant being able to control access and assignment of the unique Auth Info codes.
SAKURA Internet acknowledges the importance of the specific security provisions regarding Auth Info Codes described in the ʺICANN Consensus Policy on Transfer of Registrations between Registrarsʺ (following is an excerpt) :
Registrars must provide the Registered Name Holder with the unique ʺAuthInfoʺ code within five (5) calendar days of the Registered Name Holderʹs initial request if the Registrar does not provide facilities for the Registered Name Holder to generate and manage their own unique ʺAuthInfoʺ code.
Registrars may not employ any mechanism for complying with a Registered Name Holderʹs request to obtain the applicable ʺAuthInfo Codeʺ that is more restrictive than the mechanisms used for changing any aspect of the Registered Name Holderʹs contact or name server information.
The Registrar of Record must not refuse to release an ʺAuthInfo Codeʺ to the Registered Name Holder solely because there is a dispute between the Registered Name Holder and the Registrar over payment.
Registrar-generated ʺAuthInfoʺ codes must be unique on a per-domain basis.
We understand that the reason for these safeguards is for the Registrars during the initial implementation of EPP to assign a common Auth Code for all domain name registrations, and therefore effectively defeating any security aspects.

23.5.3. Name Server and Zone File Administration
Our Backend Registry Operations will constantly upgrade our DNS resolution services, preventing continued sophisticated attacks. Any RFP will focus on both active and passive efforts that Backend Registry Operations employ to defend against such attacks.
We ensure 100% availability of the DNS Resolution service. This we allow us to diversify our entire solutions for our software, hardware, network architectures, and multiple server hosting sites. Therefore, even if we are under DoS and DDoS attacks, we wonʹt lose all our capabilities of DNS servers in service over 18 sites.
Also, maintaining the zone data integrity in the DNS servers is critically important. Thus, we have a process in place to check data before generating the zone data, and moreover, we protect the network communications by encryptions and digital signatures until the data arrives safely to the DNS servers.

23.5.4. Operation of WHOIS Database
The Whois databases will be divided into the primary site and the secondary sites, constantly synchronizing data so that both servers will always be ready for service. The primary site will normally provide the service, and the secondary site will always be in stand-by mode. The servers within each site will be redundant and therefore achieving high availability.
The Whois database will be designed as Read only, unless it receives most current updated information from the SRS database, and it will keep the integrity to protect from unauthorized access and tampering attempts from the external networks.
Additionally, we will secure data confidentiality by controlling and preventing internet users from acquiring high volume search results through automatic⁄systematic queries.

23.5.5. Registrar Support Services
SAKURA Internetʹs designated Registry Operatorʹs know-how and familiarity of the established Backend Registry Operation will minimize the potential for unknown security and stability issues.
The purpose of restricting Registrars access to the ʺsand boxʺ until they pass OT&E is to minimize the potential for unintended actions by a registrar that would negatively impact Registry operations.

23.5.6. Data Escrow
In order to minimize the impact to the .sakura Registry services, we will provide the Registry Data Escrow service in the case of business failures. It is a key component of ICANN providing a safety net to ensure registry continuity.
SAKURA Internet will select an appropriate Escrow Agent following the predefined set of standards. In the event that we put the data in escrow at regular intervals, we will encrypt the data and apply digital signatures to maintain confidentiality and security.

23.5.7. DNSSEC
In order for the Registry operator to validate the accuracy of the DNS response, SAKURA Internet will provide the DNSSEC service. Providing DNSSEC is a long term investment that will increase the level of security, stability and trust within the .sakura.
Also, SAKURA Internet has published the .sakura DNSSEC Practice Statement (.sakura DPS) in order to declare that operates DNSSEC of .sakura registry services properly:Please refer to the answer of #43 (DNSSEC) for more detailed information.
The following RFCs will be used in .sakura:
* RFC4033:DNS Security Introduction and Requirements
* RFC4034:Resource Records for the DNS Security Extensions
* RFC4035:Protocol Modifications for the DNS Security Extensions
* RFC4509:Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
* RFC4641:DNSSEC Operational Practices
* RFC5155:DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
* RFC5702:Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC
* RFC5910:Domain Name System (DNS) Security Extensions Mapping for the Extensible
Provisioning Protocol (EPP)

23.5.8. Internationalized Domain Names
The IDN tables are prepared and submitted presented in the answer for #44 (IDNs). We will implement these by correlating the IDNs to be registered with the language in reference to RFC3743, issued by IETF.
We plan to use Japanese language for the second level of .sakura, and the IDN tables mentioned above will be applied. When and if any languages other than Japanese are used, we will prepare and register an appropriate IDN table in reference to the existing IDN tables registered in IANA.
In order to achieve a most safe and secure IDN operation for the .sakura domain we will address the Japanese-specific issues by restricting the applicable strings⁄characters (only ASCII and Japanese characters can be registered) and by normalizing double-byte numerals and alphabet to one-byte letter.
In addition, our operation will be able to promptly respond to the changes in the IDN-related conditions and to the relevant RFC issuances, and incorporate the latest trends and updates in our services.
gTLDFull Legal NameE-mail suffixDetail
.nttNIPPON TELEGRAPH AND TELEPHONE CORPORATIONml.hco.ntt.co.jpView
23.1. Definition
For the purpose of this answer the following terms are defined as follows:
NTT:
An acronym for Nippon Telegraph and Telephone Corporation.
.ntt Registrant:
The registrant of .ntt:NTT is the sole registrant of .ntt in this proposal.
.ntt Registrar:
An ICANN accredited Registrar for .ntt:NTT will designate the registrar
Registry Operations:
Front and back-end registry operations which include registry services and necessary operations to support those services:NTT intends to outsource the registry operation to a particular third party.
NTT Subsidiaries:
Subsidiaries of NTT:There are 756 subsidiaries as of March 2011.
NTT Group:
NTT Group consists of NTT Subsidiaries and other 102 affiliated companies.
.ntt Domain Name Users:
The users of .ntt:NTT and NTT Subsidiaries will be the .ntt users.
NGN:
An acronym for ʺNext Generation Networkʺ
ICT:
An acronym for ʺInformation and Communication Technologyʺ
SLD:
An acronym for ʺSecond Level Domainʺ
Critical Functions:
Functions that are critical to the operation of a gTLD registry:
1. Domain Name System (DNS) Resolution
2. Domain Name System Security Extensions (DNSSEC)
3. Shared Registration System (SRS) by means of the Extensible Provisioning
Protocol (EPP)
4. Registration Data Publication Service by means of the Whois protocol
5. Registry Data Escrow
23.2. Introduction
NTT, as Japanʹs largest telecommunications carrier, is proposing the concept, ʺ.ntt INITIATIVES.ʺ This concept serves the purpose of acquiring and protecting the iconic Japanese brand of NTT, by applying for ʺ.nttʺ and being accredited by ICANN as the sponsor Registry, and meanwhile providing a safer and more secure domain name environment in order to extend and elevate the brand value of NTT in the borderless global market:
(1) Acquire .ntt brand:
Our objective is to apply ICANN for ʺ.nttʺ and acquire the brand as a precautious defense measure to protect the NTT brand as early as possible.
(2) Provide .ntt TLD:
Our objective is to expand more secure and safe authenticated domain name space, under our management control, enabling us to demonstrate a safer and more secure NTT and .ntt in practice.
(3) Leverage .ntt TLD:
Our objective is to build a new corporate brand and image by making ʺ.nttʺ as a symbol or an icon for the ʺnew NTT,ʺ and associate the key words such as ʺubiquitous broadband servicesʺ with ʺ.nttʺ to gain leverage in the internet marketing activities.
In our initial stage of this plan, NTT will implement the eight main services, on the premise of providing registrations for .ntt SLDs.
We believe that by providing a comprehensive range of proposed registry services, NTT will be able to support and achieve our defined objectives for .ntt.
23.3. OUR PREMISE:BUSINESS CONSIDERATIONS
-As stated in the answer for #18.4 (OUR PREMISE), NTT will be the sole registrant of .ntt. We intend to provide the second level domain of .ntt for our NTT Subsidiaries.
-Examples of the SLDs:NTTSubsidiaryname.ntt, r&dprojectname.ntt
-Because NTT will be the sole registrant of .ntt, as an assumption, we will have no multiple applications or competitions for our second level domain name. NTT will apply its own evaluation criteria to review and evaluate the potential users and objectives, and NTT will register only the qualified second level domain names⁄strings. If by any chance we face another application for the same particular second level domain name (i.e. ʺsubsidiaryname.nttʺ), then we will resolve the matter on a first-come and first-serve basis.
-As a Registry providing services to Registrar for .ntt, NTT will offer initial domain name registration for a period of 1 to 10 years, complying with the Registry Agreement.
-We do not intend to charge for the .ntt registrations. However, should we decide to charge for the registrations, we will notify the Registrar in advance, complying with the Registry Agreement.
-Our measures regarding the registration of .ntt second level domain, in terms of the registration lifecycle as well as the policies to protect the registrants and proprietors of trademarks, are described in the answers for #27 (Registration life cycle), #28 (Abuse prevention & mitigation) and #29 (Rights protection mechanisms).
-Our measures to protect the privacy and confidential information of the .ntt users are explained in the answers for #30 (Security).
-As per the cost efficiency and benefits of .ntt, we believe that servicing⁄sharing .ntt for the NTT Subsidiaries at no charge, should provide cost benefits, advantages and immediate impact to usersʹ operations. By achieving goals of the .ntt initiatives, we believe that NTT and the NTT Group companies will mutually enjoy the benefit. In terms our specific financial cost information, please refer to our answers for #46 (Projections template: costs and funding) and #47 (Costs: setup and operating).
We estimate that the .ntt SLD registrations during the initial 1 to 3 years will be approximately 50. As mentioned in #18.4 (OUR PREMISE), NTT has approximately 800 Subsidiaries, and they will be the potential SLD users. Based on that potential number, we forecast 2 registrations in the first year, 15 in the second year and 50 in the third year.
We will select a Registry Operator for .ntt, who has adequate level of experiences in building and operating the Registry services, and we will outsource our entire Registry operations for the proposed .ntt Registry services.
23.4. INTENDED SERVICES⁄FUNCTIONS:TECHNICAL CONSIDERATIONS
Although NTT will be the sole registrant of .ntt, we intend to share the second level domain of .ntt with the NTT Subsidiaries.
As NTT being the registrant, NTT, at its own discretion, will choose a Registrar for .ntt among the ICANN accredited registrars, who should be able to manage and operate an evaluation process to qualify the potential users and objectives, and should be capable of the operating .ntt Registry.
Given the business considerations and our specific objectives along with the continued ongoing evolution of the domain name market, NTT proposes a following comprehensive range of registry services to support .ntt, which are almost universal across most if not all the gTLDs.
1. Domain Name Registration and Renewal
2. Transfer of Registration between Registrars
3. Name Server and Zone File Administration
4. Operation of WHOIS Database
5. Registrar Support Services
6. Data Escrow
7. DNSSEC
8. Internationalized Domain Names

23.4.1. Domain Name Registration and Renewal
One of the most basic services that a Registry Operator provides is the registration and renewal of a domain name. We intend the Domain Name Registration of .ntt to be a FSFC registration registered in one year annual increments for up to a maximum of ten (10) years. NTT will also provide the ability to renew a domain in annual increments. Details of Registration Life Cycle of .ntt are described in the answer for #27 (Registration life cycle).
This Registry Service will be provided by accessing the Shared Registry System (SRS) through a securing SSL connection using the Extensible Provisioning Protocol (EPP) that ICANN has mandated for all new gTLD operators. There are various EPP commands involved in registering⁄maintaining a domain name which are identified in more detail in the answer for #25.1 (EPP).

23.4.2. Transfer of Registration between Registrars
Since the creation of ICANN, there has been a dichotomy within the domain name marketplace between Registrars and Registries. Domain name portability, the ability of a Registrant to transfer sponsorship of a domain name at the Registry Operator from one Registrar to another Registrar, has been one of ICANNʹs initial success stories.
To safeguard a Registrantʹs ability to transfer sponsorship of a domain name between Registrars, ICANN has adopted a consensus policy (ICANN Consensus Policy) that largely regulates the domain name transfer process between a Gaining and Losing Registrar. This policy specifically sets forth the limited circumstances in which a Losing Registrar can deny a transfer request, as well as dispute providers that have been approved to administer the Transfer Dispute Resolution Policy.
Reference
Approved Providers for Transfer Dispute Resolution Policy
http:⁄⁄www.icann.org⁄en⁄dndr⁄tdrp⁄approved-providers.htm
Policy on Transfer of Registrations between Registrars (Revision Adopted November 7, 2008, Effective March 15, 2009)
http:⁄⁄www.icann.org⁄en⁄transfers⁄policy-en.htm
NTT will adopt the use of the ʺAuth Info codesʺ coupled with the implementation of ʺICANN Consensus Policyʺ recommendations that has mitigated the number of hijacking incidents. The ʺAuth Infoʺ safeguard is largely dependent upon a Registrant being able to control access and assignment of unique ʺAuth Info codes.ʺ
NTT will also provide the Bulk Transfer service for .ntt, which is a mandated Registry Service set forth in ICANNʹs Consensus Policy on Transfer of Registrations between Registrars (following is an excerpt from the policy) :
Registry Operator shall make the necessary one-time changes in the Registry database for no charge, for transfers involving 50,000 name registrations or fewer. If the transfer involves registrations of more than 50,000 names, then the Registry Operator shall charge the gaining Registrar a one-time flat fee of US$ 50,000.

23.4.3. Nameserver and Zone File Administration
This is the primary self-service function that the Registry provides for the consumer to use directly. If this service fails, then the TLD will essentially go dark on the Internet. NTT will offer the Name Server and the zone file administration services with the best practice adopted by the existing gTLD Registry Operators. The technical considerations for .ntt in connection with the name server and the zone file administration are explained in the answer for #35 (DNS service compliance).
Historically, ICANN accredited registries have been required to provide bulk zone file access to third parties that requested such data at no cost, on terms set forth in all incumbent ICANN registry agreements. NTT will provide the Bulk Zone File Access service to users. More details on Bulk Zone File Access are described in the answer for #26 (Whois).

23.4.4. Operation of Whois Database
All Registry Operators are required to provide both Web-based and port 43 interfaces to the registryʹs Whois database servers.
NTT will provide public access to the Whois database servers as required under the Registry Agreement.
NTT will ensure that those servers will be a part of the Registry Architecture, detailed in the answers for #24 (SRS performance) and #26 (Whois), focused on redundancy. In connection with the Web-based and port 43 interfaces, NTT will employ reasonable safeguards to prevent the mining of Whois data through high volume queries. Please refer to the answer for #28 (Abuse prevention & mitigation) and #29 (Rights protection mechanisms) with regard to maintaining redundancy of Whois.
As described in #23.3 (OUR PREMISE:BUSINESS CONSIDERATIONS), NTT will apply its own evaluation criteria to review and evaluate the potential users and objectives, and NTT will register only the qualified second level domain names⁄strings. Additionally, we will be able to provide the most current and accurate .ntt contact information through the Whois search, because the .ntt users will mainly be the NTT Subsidiaries.

23.4.5. Registrar Support Services
The implementation of Registrar Support Services will be limited, due to the fact that NTT, having the liberty of selecting an ICANN accredited Registrar for .ntt at its own discretion, plans to choose a specific Registrar that is capable of managing and operating the .ntt proprietary evaluation process to qualify the potential users and objectives. However, in the event that we provide the Registrar Support Services for multiple ICANN accredited registrars sometime in the future, we will provide the following support services to the selected Registrars:
A) Registrar OT&E:
As a prerequisite for Registry Operatorʹs granting an ICANN Accredited Registrar access to the SRS, NTT will facilitate (test and certify) the Operational Test and Evaluation (OT&E) certification process for the Registrars.
B) Registry Operatorʹs Website:
NTT will provide access to Registry Operatorʹs Website for Registrars to download various support documentations. In order to secure the access to the Website, each Registrar will be assigned a user ID and password.
While EPP provides a polling function for some transactions, most Registrar reports are accessible through a secure web-based portal.

23.4.6. Data Escrow
This is a mandated Registry Service incorporated into the baseline Registry Agreement by ICANN to ensure the security and stability of Registry Operations for the benefit of Registrants and the broader Internet community. The technical criteria associated with the data escrow requirements are set forth in the Specification 2 of the ʺICANN draft new gTLD Registry Agreement.ʺ More details on Registry Service for .ntt are set forth in the answer for #38 (Escrow).

23.4.7. DNSSEC
This is a mandated Registry Service in accordance with Specification 6 of the ʺICANN draft new gTLD Registry Agreement.ʺ NTT adopts DNSSEC into .ntt. The technical implementation of DNSSEC is explained in the answered for #43 (DNSSEC).

23.4.8. Internationalized Domain Names
NTT will support IDN in .ntt in a fully standards-compliant fashion at the time of transition. NTT has implemented IDN in Japanese, and in line with ICANN guidelines and IETF standards.
The Japanese language will be used for .ntt and the IDN tables, presented in the answer for #44 (IDNs), and will be provided as required for the second level domain. NTT has been offering the IDN for .jp for more than 10 years, and there are approximately 120,000 IDNs currently registered in .jp Detailed considerations of IDN are described in the answer for #44 (IDNs).

23.5. Security ⁄ Stability
As we strive for achieving our objectives⁄goals for .ntt, NTT will apply the most appropriate information security measures and provide safe registry services to the users.
NTT acknowledges that protecting the registrant information and ensuring 100% availability of DNS services are critical. Hence, we will implement extensive security measures to protect information confidentiality, safety and high availability in practice for .ntt registry services.
Below, we have listed the major categories of our planned security measures for .ntt registry services:
* Network Control and Access Control
* Secure network communications and data encryption
* Digital data signature and DNSSEC Resolution
* Software, hardware and network architectures, as well as multi-site redundancy
For more detailed information about the .ntt security, please see the answer for #30 (Security).
In the following sections, we will describe the security and stability considerations for the provided services and functions.

23.5.1. Domain Name Registration and Renewal
As NTT will be the sole registrant and the user of .ntt, concerns on unauthorized access to .ntt will be limited by security protocols in place.
As per the users of .ntt second level domain, we will apply our proprietary evaluation criteria to review and evaluate the potential users and objectives, and NTT will register only the qualified second level domain names⁄strings. Therefore, we believe that we will be able to avoid unauthorized access and abusive uses.
We are confident that the operational system that we will outsource, in connection with domain names registrations and renewals will handle the various business use cases. NTT will select an experienced Registry Operator for the entire registry operations, and it is one of our prerequisites to be selected as our Registry Operator to have an SLA which will address all the requirements and considerations pertaining potential security and stability issues.
NTT will not rely on a third party validation agent. Therefore, the concerns relative to ensuring the security of electronic communications will be minimized and not subject to interception and or manipulation.
Although there should be no security⁄stability concerns beyond those referenced in the ʺStandard Domain Name Registration Service,ʺ NTT acknowledges that it may have to exercise some enhanced security protocols when transferring EPP Auth Codes to successful Registrants to allow them to transfer the domain name to a registrar of their choice.
NTT will work to determine the best technical implementation to address the business needs of the .ntt registry. In addition, NTT will ensure that the security and stability weaknesses identified in the SSAC reports are proactively addressed for the benefit of NTT and .ntt users.

23.5.2. Transfers of Registration between Registrars
The Auth Info safeguard is largely dependent upon a Registrant being able to control access and assignment of the unique Auth Info codes.
NTT acknowledges the importance of the specific security provisions regarding Auth Info Codes described in the ʺICANN Consensus Policy on Transfer of Registrations between Registrarsʺ (following is an excerpt) :
Registrars must provide the Registered Name Holder with the unique ʺAuthInfoʺ code within five (5) calendar days of the Registered Name Holderʹs initial request if the Registrar does not provide facilities for the Registered Name Holder to generate and manage their own unique ʺAuthInfoʺ code.
Registrars may not employ any mechanism for complying with a Registered Name Holderʹs request to obtain the applicable ʺAuthInfo Codeʺ that is more restrictive than the mechanisms used for changing any aspect of the Registered Name Holderʹs contact or name server information.
The Registrar of Record must not refuse to release an ʺAuthInfo Codeʺ to the Registered Name Holder solely because there is a dispute between the Registered Name Holder and the Registrar over payment.
Registrar-generated ʺAuthInfoʺ codes must be unique on a per-domain basis.
We understand that the reason for these safeguards is for the Registrars during the initial implementation of EPP to assign a common Auth Code for all domain name registrations, and therefore effectively defeating any security aspects.

23.5.3. Name Server and Zone File Administration
Our Backend Registry Operations will constantly upgrade our DNS resolution services, preventing continued sophisticated attacks. Any RFP will focus on both active and passive efforts that Backend Registry Operations employ to defend against such attacks.
We ensure 100% availability of the DNS Resolution service. This we allow us to diversify our entire solutions for our software, hardware, network architectures, and multiple server hosting sites. Therefore, even if we are under DoS and DDoS attacks, we wonʹt lose all our capabilities of DNS servers in service over 18 sites.
Also, maintaining the zone data integrity in the DNS servers is critically important. Thus, we have a process in place to check data before generating the zone data, and moreover, we protect the network communications by encryptions and digital signatures until the data arrives safely to the DNS servers.

23.5.4. Operation of WHOIS Database
The Whois databases will be divided into the primary site and the secondary sites, constantly synchronizing data so that both servers will always be ready for service. The primary site will normally provide the service, and the secondary site will always be in stand-by mode. The servers within each site will be redundant and therefore achieving high availability.
The Whois database will be designed as Read only, unless it receives most current updated information from the SRS database, and it will keep the integrity to protect from unauthorized access and tampering attempts from the external networks.
Additionally, we will secure data confidentiality by controlling and preventing internet users from acquiring high volume search results through automatic⁄systematic queries.

23.5.5. Registrar Support Services
NTTʹs designated Registry Operatorʹs know-how and familiarity of the established Backend Registry Operation will minimize the potential for unknown security and stability issues.
The purpose of restricting Registrars access to the ʺsand boxʺ until they pass OT&E is to minimize the potential for unintended actions by a registrar that would negatively impact Registry operations.

23.5.6. Data Escrow
In order to minimize the impact to the .ntt Registry services, we will provide the Registry Data Escrow service in the case of business failures. It is a key component of ICANN providing a safety net to ensure registry continuity.
NTT will select an appropriate Escrow Agent following the predefined set of standards. In the event that we put the data in escrow at regular intervals, we will encrypt the data and apply digital signatures to maintain confidentiality and security.

23.5.7. DNSSEC
In order for the Registry operator to validate the accuracy of the DNS response, NTT will provide the DNSSEC service. Providing DNSSEC is a long term investment that will increase the level of security, stability and trust within the .ntt.
Also, NTT has published the .ntt DNSSEC Practice Statement (.ntt DPS) in order to declare that operates DNSSEC of .ntt registry services properly:Please refer to the answer of #43 (DNSSEC) for more detailed information.
The following RFCs will be used in .ntt:
* RFC4033:DNS Security Introduction and Requirements
* RFC4034:Resource Records for the DNS Security Extensions
* RFC4035:Protocol Modifications for the DNS Security Extensions
* RFC4509:Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
* RFC4641:DNSSEC Operational Practices
* RFC5155:DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
* RFC5702:Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC
* RFC5910:Domain Name System (DNS) Security Extensions Mapping for the Extensible
Provisioning Protocol (EPP)

23.5.8. Internationalized Domain Names
The IDN tables are prepared and submitted presented in the answer for #44 (IDNs). We will implement these by correlating the IDNs to be registered with the language in reference to RFC3743, issued by IETF.
We plan to use Japanese language for the second level of .ntt, and the IDN tables mentioned above will be applied. When and if any languages other than Japanese are used, we will prepare and register an appropriate IDN table in reference to the existing IDN tables registered in IANA.
In order to achieve a most safe and secure IDN operation for the .ntt domain we will address the Japanese-specific issues by restricting the applicable strings⁄characters (only ASCII and Japanese characters can be registered) and by normalizing double-byte numerals and alphabet to one-byte letter.
In addition, our operation will be able to promptly respond to the changes in the IDN-related conditions and to the relevant RFC issuances, and incorporate the latest trends and updates in our services.