ICANN New gTLD Application

18.1.  DEFINITION
For the purpose of this answer the following terms are defined as follows:
Corporate Information Referenced in this Proposal:
All of the information referenced and quoted in this proposal, such as corporate information (i.e.  organizations, operation offices, financials and operations), business information (i.e.  products and services including R&D), business management (i.e.  management policies, business plans and management strategies), etc.  are current as of the end of February 2012.
.ntt Registrant:
The registrant of .ntt:Nippon Telegraph and Telephone Corporation (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 are the primary .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
18.2.  OUR MISSION
Nippon Telegraph and Telephone Corporation (NTT), as Japanʹs largest telecommunications carrier, is promoting wide use of the worldʹs highest level broadband network, and actively involved in creating a wide range of broadband and ubiquitous services with a unified effort of the NTT Group, in accordance with our Medium-Term Management Strategy ʺRoad to Service Creation Business Group.ʺ
Our proposed concept, ʺ.ntt INITIATIVES,ʺ 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.
As per our corporate branding, in addition to our worldʹs highest level broadband network infrastructure, we are promoting and enhancing the fiber-optic video services and the cloud computing services, driving enthusiastically to create new services, and well-positioning to serve the total ICT solutions globally.  These ongoing progresses will allow us to deploy a new service⁄business model in the global market, bringing about a greater synergy among the NTT Group companies as a whole, and through that process we hope that .ntt will contribute in gaining recognition and building a new corporate image for NTT.
18.3.  GENERAL BACKGROUND
Nippon Telegraph and Telephone Corporation (NTT) was incorporated in April 1985 after the privatization of Nippon Telegraph and Telephone Public Corporation (established in 1952), and it has been Japanʹs largest and most recognized public telecommunications carrier.  NTT Group, on a consolidated basis, currently has approximately 220,000 employees, 756 NTT Subsidiaries and 102 affiliated companies, and they have five core business segments:1) Regional Communications Business; 2) Domestic Long-Distance and International Communications Businesses; 3) Mobile Communications Businesses; 4) Data Communications Businesses; and 5) Other Businesses.
Please see our Web site for more information about the NTT Group:http:⁄⁄www.ntt.co.jp⁄about_e⁄group.html
In November 2004, NTT Group announced its ʺMedium-Term Management Strategy,ʺ which focused on goals in response to the quick shift in the broadband⁄IP networks and the ongoing convergence of fixed and mobile communications, as well as significant changes in telecommunications and broadcasting in terms of their business collaboration and technology fusion.  NTT Group has established a broadband access infrastructure that includes the Next-Generation Network (NGN) with high reliability and security, offering ubiquitous broadband services to meet diverse customer needs.
In line with the Medium-Term Management Strategy, we steadily promoted business activities, such as commencing commercial-use NGN services.  Through this effort, we clearly saw the opportunities in streamlining our infrastructure for future services.  Foreseeing the Groupʹs future business activities and structure, in May 2008 we announced a new Medium-Term Management Strategy, the ʺRoad to a Service Creation Business Group,ʺ with the aim of developing and offering new services compatible with full IP networks that cover both fixed-line and mobile communications.
As a Service Creation Group, the NTT Group intends to engage in its business activities toward the full-scale development of ubiquitous broadband services in fiscal 2012.
Please see our Web site for more information about the NTT Medium-Term Management Strategy:http:⁄⁄www.ntt.co.jp⁄ir⁄mgt_e⁄managementstrategy.html
NTT Group is proactively expanding its business abroad, in order to make its global business as one of the main pillars of revenue.  NTT have acquired Dimension Data Holdings, plc.  and Keane International, Inc.  As a result, we added Australia, South America, the Middle East and Africa to our existing operations in Asia, Europe and the United States, which enhanced our capabilities and enabled us to establish a framework to provide one-stop total ICT services on a global basis.
We are also working on reinforcing our business infrastructures for the services, such as enhancing data centers and networks, overseas, and opening additional business offices in support of local sales capabilities for Japanese (or Japanese-affiliated) companies.
Please see our Web site for more information about eth NTT Global Business:http:⁄⁄www.ntt.co.jp⁄about_e⁄global2.html
Meanwhile, under the NTT R&D vision of creating technologies that lead the world and contributing to the development of society, industry and academic pursuits, approximately 2,500 researchers engage in a wide range of diverse research activities from basic research to R&D, which support business development of operating companies.  The NTT Groupʹs R&D activities include cutting-edge fundamental research that creates new technologies such as the worldʹs highest level fiber-optic technologies; NGN and other network technologies, which the NTT Group led the world in commercializing them; and the network-oriented applications.  We engage in diverse R&D activities and commercialization to rapidly link the R&D results to business development.  With R&D as a key driver of the NTT Groupʹs growth capabilities, the NTT Group creates competitive technologies and collaborates with various corporations, universities and research institutions, thereby ensuring ongoing innovation.
Please see our Web site for more information about the NTT R&D:http:⁄⁄www.ntt.co.jp⁄RD⁄OFIS⁄index_en.html
As the NTT Group enhances its business specialties and various activities described above, we have conceived an idea for a proposal that will contribute to the innovative use of domain name as well as to the TLD market for the future, and decided to apply ICANN for the new gTLD.

18.4.  OUR PREMISE
- We intend to utilize .ntt effectively for the promotion and expansion of our internet marketing (especially for the purpose of our corporate branding), and for improving the vital use of the new gTLD as well as our existing NTT TLD brands.
- NTT will be the primary user of the proposed .ntt, and we will mainly control the use of the second level domain (SLD) by our registration policies and through a process of qualification, restricting the use within NTT Subsidiaries, and of evaluation, reviewing the purposes of the domain name (policies and process are explained in #23 Registry Services).  Therefore, as an assumption, we expect no multiple domain name applications for the same name space.
* Example of the SLD:NTTSubsidiaryname.ntt, r&dprojectname.ntt
- As we have the liberty of selecting a Registrar for .ntt 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 .ntt Registry services (explained in the answer for #23 Registry Services).
- 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 registration.  However, should we decide to charge for the registrations, we will notify the Registrar in advance complying with the Registry Agreement.
- Our measures to protect the privacy and confidential information of the .ntt users are explained in the answers for #30 Security (a) and (b).
- As per the cost benefits of .ntt, we anticipate the most impact on branding.  NTT will take full and direct advantages of .ntt advancing brand value⁄image and gaining brand recognition, while NTT plans to offer the SLD space to the NTT Subsidiaries at no charge, and that we believe will contribute to the .ntt domain name users to potentially integrate some of the existing independent TLDs or use them more objectively.
- Introduction and expansion of .ntt will promote customer (both corporate and consumer) trust and choice, in terms of internet search (engines) and access.  Branded gTLDs, by nature, will allow registrant to create a short domain name (i.e.  .ntt) that consumer can easily remember, and also will provide internet users the exclusive and authenticated (trusted) easy access to desired information, by keyword domain names under our own brand.  .nttʹs specific purposes and benefits are described in #18.7 (OUR PURPOSES AND OBJECTIVES OF .ntt).
- As described in #18.9 (OUR EFFORTS ON .ntt EXPANSION), we believe our proposed public relations activities and communications outreach are efficient and effective measures to achieve our projected benefits.
- As mentioned in #18.3 (GENERAL BACKGROUND), NTT has approximately 860 NTT Group companies (756 NTT Subsidiaries and 102 affiliated companies), and based on that potential number, we estimate that the .ntt SLD registrations will increase up to a maximum of about 1000.
18.5.  .ntt INITIATIVES
We have developed the ʺ.nttʺ concept, in applying ICANN for the New gTLD.
Our ʺ.ntt INITIATIVESʺ aims at achieving three goals:
(1) Acquire .ntt brand:
Apply for the New gTLD; acquire and protect the NTT brand.
(2) Provide .ntt TLD:
Provide an enhanced (safer and more secure) domain name environment.
(3) Leverage .ntt TLD:
Leverage .ntt to advance brand value⁄image and gain brand recognition.
The above three goals are in line with the current NTT Medium-Term Management Strategy, and each goal will be explained in this proposal (#18.7 (OUR PURPOSES AND OBJECTIVES OF .ntt) ), in terms of .ntt users, objectives, intended purposes and advantages.
(1) Acquire .ntt brand:To Protect the NTT Brand
NTT is one of the leading business enterprises in Japan, and we believe that the new gTLD will be  a significant opportunity for the NTT Group, but at the same time the opportunity may become a competitive threat to us, if we do not react upon it.  Hence, we have decided to apply ICANN for ʺ.nttʺ as a precautious defense measure to protect the NTT brand as early as possible.
(2) Provide .ntt TLD:To provide a Safer and More Secure Domain Name Environment
We feel proud in the products and services that the NTT Group provides, because they are perceived as most safe and trusted in Japan.  As we would like to maintain that image and the brand value of the NTT Group, we have contemplated the potential use of the new gTLD to take advantage of its features and characteristics, and set one of the goals for the ʺ.ntt INITIAIVESʺ to provide a safer and more secure domain environment (i.e.  higher authentication to prevent phishing attacks).  We believe that by deploying the authenticated domain name space, the NTT group will achieve an objective to protect our registered trademark and credibility in the competitive global environment.
(3) Leverage .ntt TLD:To Build Advanced Image and Gain Brand Recognition.
The NTT Group reserves many associated brands (corporate⁄business and products⁄services), and in addition to our worldʹs highest level broadband network infrastructure, we are expanding our fiber-optic video services and other various businesses and services, primarily in the domestic market.  Furthermore, we have enhanced our global capabilities by adding Australia, South America, the Middle East and Africa to our existing operations in Asia, Europe and the United States, taking advantages of which enabled us to establish a framework to provide one-stop total ICT services on a global basis, and expanding our new services and business models that we could exercise the NTT Group synergy.  We believe that leveraging .ntt in our marketing strategies will contribute in gaining more brand recognition and building a new corporate image of NTT.
Our ʺ.ntt INITIAIVESʺ are deliberated from the following key questions, and each answer is explained in detail in the subsequent chapters, #18.6 (OUR CHALLENGES) and #18.7 (OUR PURPOSES AND OBJECTIVES OF .ntt) :
* Why do we need it?
* What responsibilities will we have?
* Who will benefit from it?
* How will it work (What are the objectives) ?
* What will it offer (What value will it provide) ?
18.6.  OUR CHALLENGES
* NTT is one of the foremost enormous organizations in Japan, with a long, proud history.  In a corporate branding survey conducted by a media company, we found that the general perceived image of NTT by most Japanese consumers is represented by a few selected words such as ʺtrust,ʺ ʺstabilityʺ and ʺtradition.ʺ  The result tells us that for the people of Japan and the internet market, the solid ʺNTTʺ brand has been prevailing in the Japanese society as a part of its culture for a very long time.
* We are urged and determined to protect this prevailing corporate brand of ours, with a long history and many achievements, as a responsibility for the consumers and the society.
* As mentioned in the examples above the representative corporate image of NTT is derived from our reputable past achievements of ʺsafe and secureʺ products and services, and it is important that we sustain and continue to preserve that image, in terms of our social mission.  Especially, in the rather emerging and developing internet environment, a representative company like us that provides the state-of-the-art network technologies and services is required to demonstrate safety and stability in business practices.
* For NTT, as the holding company and from the stand point of the overall businesses, it is critical to protect and expand the representative icon (brand) such as ʺ.nttʺ for the NTT Group as a whole.  Moreover, we expect that sharing the knowledge and know-how accumulated in applying and implementing the new gTLD, ahead of the Group companies, will be requested by the potential applicants within the Group.
* As the entire NTT Group companies are a part of the business structure to provide ʺglobal one-stop ICTʺ services, the domain names (string) and URLs tend to be long, and the domain operations and rules become complex and cumbersome.  We expect for the future that there will be a need for the domain environment that binds many brands and the proprietary information owned by the NTT Group.
* As a core mission of the NTT Group Medium-Term Management Strategy, we are currently shifting our business structure and financial strength from the still-remaining legacy-related services to the network solution oriented services and profit structure.  Due to our historical background, the NTT Groupʹs perceived corporate image is portrayed with positive key words like ʺJapanʹs iconic and representative corporationʺ and ʺsecure and safe,ʺ meanwhile, traditional key words like ʺdomesticʺ and ʺtelegraph and telephoneʺ remain as the other persistent image.  Hence, we would want to exploit the existing positive image (i.e.  secure and reassuring, safe and trustworthy), and to establish the new corporate brand (image) that symbolized by the state-of-the-art technologies and services, namely our up-to-date broadband and ubiquitous services.
* Please see our Web site for more information about the NTT Medium-Term Management Strategy:http:⁄⁄www.ntt.co.jp⁄ir⁄mgt_e⁄managementstrategy.html
* NTT, by comparison with other corporations, is publically counted on to implement and attain new challenges, and indeed that is our strength and what differentiates NTT from the others.  We expect that thereʹs a potential need for unprecedented marketing strategies and the basis for their activities, responding to the expectations of new efforts, promotions and marketing events.  For instance, we will need to implement more timely campaigns and forehanded delivery of services from the customerʹs perspective.
* In terms of business acquisitions overseas, brand integration and having a communications basis for our M&A activities are quite significant.  We recognize that thereʹs a need to increase our internet presence in the overseas market by advancing the existing environment to utilize domain names, and by establishing an accessible communications platform which enable us to promptly respond and react.
18.7.  OUR PURPOSES AND OBJECTIVES OF .ntt
We have defined below our purposes and objectives for each of our ʺ.ntt INITIATIVESʺ mentioned in the previous section (#18.5 (.ntt INITIATIVES) ) :
(1) Acquire .ntt brand:To Protect the NTT Brand
DOMAIN NAME USERS:NTT (holding company)
MISSION & PURPOSES:
As NTT is one of the leading business enterprises and iconic brands in Japan, our initiative to introduce new gTLD will be a significant opportunity for the NTT Group, which aggressively expanding global businesses, but failing to acquire ʺ.nttʺ may pose a hazard to our persistent branding.  Therefore, we are urged to apply ICANN for ʺ.nttʺ and to acquire the registry.
OBJECTIVES & ADVANTAGES:
Our objectives in this initiative are to apply ICANN and to acquire ʺ.nttʺ (accredited to operate .ntt), as a precautious defense measure, to prevent others from taking advantage of ʺ.ntt,ʺ and to protect the NTT brand (trademarks and reputation).
(2) Provide .ntt TLD:To provide a Safer and More Secure Domain Name Environment
DOMAIN NAME USERS:NTT (NTT Subsidiaries:domestic and overseas)
MISSION & PURPOSES:
We are proud that the products and services that the NTT Group provides are one of the most secure and trusted brands domestically.  It is our mission to sustain and to continue preserving that image and brand value.
OBJECTIVES & ADVANTAGES:
By taking advantage of its features and characteristics of the new gTLD, we aim to expand more secure and safe authenticated domain name space (i.e.  to prevent phishing attacks), under our management control, enabling us to demonstrate a safer and more secure NTT and .ntt in practice.  This means that we will be able to establish the requirements and policies for the second level domain, and be able to choose to restrict the use of ʺ.nttʺ to the NTT Group.
(3) Leverage .ntt TLD:To Build Advanced Image and Gain Brand Recognition.
DOMAIN NAME USERS:NTT (NTT Subsidiaries:domestic and overseas)
MISSION & PURPOSES:
The generally perceived corporate image of NTT Group is portrayed with positive key words like ʺJapanʹs iconic and representative corporation,ʺ meanwhile, traditional key words like ʺdomesticʺ and ʺtelegraph and telephone (i.e.  legacy) ʺ remain as the other persistent image.  Thus, we would like to establish a new corporate brand (image) that will be symbolized by the key words such as ʺglobalʺ and ʺbroadband⁄ubiquitous.ʺ
Besides, the NTTʹs global business is expanding through acquisitions of business corporations that have many overseas business domains⁄offices, the NTT branding (marketing activities) to gain recognition is a critical need.
Moreover, as per our marketing efforts, we need to expand our new marketing strategy in promoting new services and business models that we could exercise the NTT Group synergy:Thereʹs a need to gain recognition, by implementing more timely campaigns and forehanded delivery of services in response to the market needs, taking advantage of the domain names that are easy to access and to remember.
OBJECTIVES & ADVANTAGES:
One of the objectives in this initiative 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 our internet marketing activities.
Similarly, in the global business expansion, we shall take advantage of the features and the characteristics of the gTLD, targeting an objective to penetrate NTT brand into the broader market.  We shall integrate and upgrade the Web site URLs and e-mail addresses expeditiously to promote ʺ.nttʺ in order to lift our recognition and awareness in the global market.
Examples of the upgrade:http:⁄⁄www.ntt.com⁄index-e.html will be www.global.ntt
In leveraging .ntt for newer marketing strategies, one of our objectives is to be able to deploy new brand (URL) more easily, contributing to the branding efficiency and management at the same time.  This can be achieved through associating and merging many of the NTT Group owned brands.
Additionally, our objectives include using the second level domain effectively, so that the domain users will benefit more from the internet marketing, such as SEM (Search Engine Marketing) and SEO (Search Engine Optimization).
This is because the brand gTLDs provide exclusive access to keyword domain names under a specific brand, and therefore we will have the ability to create short, memorable domain names (URLs) which are easy and faster to access and remember.  We will take this advantage to create customer values⁄benefits, and expect that the search results (or page rankings) will rank higher, and that the customer access and user-friendliness will also improve dramatically.
An example of URL:www.ntt.co.jp⁄nttnews⁄index.html will become www.news.ntt
18.8.  OUR REGISTRY SERVICES
Following are the primary registry services (including critical functions) that NTT plans to provide for .ntt.  Please see the answer for #23 (Registry Services) for details.
(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
In our initial stage of this plan, NTT will implement the above eight main services, on the premise of providing registrations for .ntt SLDs.  Other advanced features such as authentication process⁄functions for the second level domain users, will be required for third level domain name registrations and second level domain operations, and that will be deliberated and supported individually and accordingly.
18.9.  OUR EFFORTS ON .ntt EXPANSION
NTT plans to implement the following efforts and outreach activities in promoting .ntt:
(1) Acquire .ntt brand:To Protect the NTT Brand
* Apply ICANN for the new gTLD to acquire ʺ.nttʺ
* Register the domain name, ʺ.nttʺ
(2) Provide .ntt TLD:To provide a Safer and More Secure Domain Name Environment
* Develop a process and administration rules to evaluate and qualify second level domain (SLD) objectives and users
* Use the above process to administer the SLD registration applications
* Authenticate and administer the .ntt SLD users (identify, activate, deactivate)
* Develop domain name operational rules (guidelines) for the designated users
* Provide⁄share SLDs for the NTT Subsidiaries (domestic and overseas)
* Provide support for the .ntt users (how to use and to administer)
* Promote and educate about .ntt (as information distribution channel) to the NTT Group
* Utilize .ntt as the ʺsafer and more secureʺ PR tool (i.e.  IR and corporate⁄proprietary information distribution)
(3) Leverage .ntt TLD:To Build Advanced Image and Gain Brand Recognition.
* Develop a process and administration rules to evaluate and qualify second level domain (SLD) objectives and users
* Use the above process to administer the SLD registration applications
* Authenticate and administer the .ntt SLD users (identify, activate, deactivate)
* Develop domain name operational rules (guidelines) for the designated users
* Provide⁄share SLDs for the NTT Subsidiaries (domestic and overseas)
* Provide proprietary information about NTT R&D and its activities, including ubiquitous broadband related information through .ntt
* Provide support for the .ntt users (how to take advantage of .ntt)
* Promote and educate about .ntt (as information distribution channel) to the internet community in which the NTT Group is involved
* Utilize .ntt as the ʺnew branding⁄marketing toolʺ to provide services oriented information
Other Outreach Activities:
* Develop a .ntt dedicated Web site
* Coordinate advertisement and promotions with .ntt over the internet

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.

24.1. Performance Specifications
24.1.1. Service Availability
Service Availability is defined in time, and in minutes, that the core Registry services should respond to its users. As a definition, ʺservice unavailableʺ means that one of the listed services in the Matrix becomes unavailable to all users. That is, when no user can initiate a session with or receive a response from the Registry.
Our definition of Service Availability is measured as follows:
Service Availability % = {[TM - (UOM + POM) ] ⁄ TM}*100 where:
TM = Total Minutes in the Service Level Measurement Period (#days*24 hours*60 minutes)
POM = Planned Outage Minutes (sum of (i) Planned Outages and (ii) Extended Planned Outages during the Service Level Measurement Period)
UOM = Unplanned Outage Minutes.
Service Availability = 98% per month
Service Availability as it applies to the SRS refers to the ability of the SRS to respond to ICANN-Accredited Registrars that access the SRS through the EPP protocol. SRS unavailability, excluding Planned Outages and Extended Planned Outages, will be logged with the Registry Operator as Unplanned Outage Minutes. Unavailability will not include any events affecting individual ICANN-Accredited Registrars locally.
The committed Service Availability for SRS is 98% per calendar month.
24.1.2. Planned Outage
High volume data centers like the Registry require downtime for regular maintenance. Allowing for regular maintenance (ʺPlanned Outageʺ) ensures a high level of service for the Registry.
Planned Outage Duration = 3 hours (180 minutes) per month
The Planned Outage Duration defines the maximum allowable time, in hours and minutes that the Registry Operator is allowed to take the Registry Services out of service for regular maintenance. Planned Outages are planned in advance and the Registrar Community is provided warning ahead of time. The Planned Outage Duration for the SRS is 3 hours (180 minutes) per month.
Planned Outage Timeframe = 00:00-03:00 UTC Sunday
The Planned Outage Timeframe defines the hours and days in which the Planned Outage can occur. The Planned Outage Timeframe shall be 00:00-03:00 UTC on the third Sunday. When the day following the third Sunday is a holiday, i.e., the Sunday is included in the consecutive holidays, it shall be 00:00-03:00 UTC of the last day of the consecutive holidays.
Planned Outage Notification = 30 days
The Registry Operator must notify all of its Registrars of any Planned Outage. The Planned Outage Notification Performance Specification defines the number of days prior to a Planned Outage that the Registry Operator must notify its Registrars. The Planned Outage Notification for the SRS is 30 days.
24.1.3. Extended Planned Outage
In some cases such as software upgrades and platform replacements, an extended maintenance timeframe is required. Extended Planned Outages will be less frequent than regular Planned Outages but their duration will be longer.
Extended Planned Outage Duration = 12 hours (720 minutes) per month
The Extended Planned Outage Duration defines the maximum allowable time in hours and minutes that the Registry Operator is allowed to take the Registry Services out of service for extended maintenance. Extended Planned Outages are planned in advance and the Registrar Community is provided warning ahead of time. Extended Planned Outage periods are in addition to any Planned Outages during any Service Level Measurement Period.
The Extended Planned Outage Duration for the SRS is 12 hours (720 minutes) per month.
Extended Planned Outage Timeframe = 00:00-12:00 UTC Sunday
The Extended Planned Outage Timeframe defines the hours and days in which the Extended Planned Outage can occur. The Extended Planned Outage Timeframe shall be 00:00-12:00 UTC on the third Sunday. When the day following the third Sunday is a holiday, i.e., the Sunday is included in consecutive holidays, the time frame shall be 00:00-12:00 UTC of the last day of the consecutive holidays.
Extended Planned Outage Notification = 30 days
The Registry Operator must notify all of its Registrars of any Extended Planned Outage. The Extended Planned Outage Notification Performance Specification defines the number of days prior to an Extended Planned Outage that the Registry Operator must notify its Registrars. The Extended Planned Outage Notification for the SRS is 30 days.
24.1.4. Processing Time
Processing Time is an important measurement of transaction-based services like the Registry. The first three Performance Specifications, Service Availability, Planned Outages and Extended Planned Outages, measure the amount of time that the service is available to its users. Processing Time measures the quality of that service.
Processing Time refers to the time that the Registry Operator receives a request and sends a response to that request.
Processing Time Performance Specifications have a monthly Service Level Measurement Period and will be reported on a monthly basis. The Registry Operator will log the processing time for all of the related transactions, measured from the time it receives the request to the time that it returns a response.
Processing Time - EPP session command = 200 milliseconds for 90%
Processing Time - EPP session command is applicable to the SRS as accessed through the EPP protocol. It measures the processing time for create EPP session.
The performance specification is 200 milliseconds for 90% of the transactions. That is, 90% of the transactions will take 200 milliseconds or less from the time the Registry Operator receives the request to the time it provides a response.
Processing Time - EPP query command = 100 milliseconds for 90%
Processing Time - EPP query command is applicable to the SRS as accessed through the EPP protocol. It measures the processing time for an availability query of a specific domain name.
The Performance Specification is 100 milliseconds for 90% of the transactions processed. That is, 90% of the transactions will take 100 milliseconds or less from the time the Registry Operator receives the request to the time it provides a response.
Processing Time - EPP transform command = 200 milliseconds for 90%
Processing Time - EPP transform command is applicable to the SRS as accessed through the EPP protocol. It measures the processing time to add, modify, and delete transactions associated with domain names, nameservers, contacts, and registrar profile information.
The performance specification is 200 milliseconds for 90% of the transactions. That is, 90% of the transactions will take 200 milliseconds or less from the time the Registry Operator receives the request up to the time it provides a response.
24.1.5. Update Frequency
There are two important elements of the Registry that are updated frequently and are used by the general public; DNS and Whois. Registrars generate these updates through the SRS. The SRS then updates the DNS and the Whois.
Update Frequency - DNS = 60 minutes for 95%
The committed performance specification with regards to Update frequency for the DNS is 60 minutes for 95% of the transactions during a Monthly Timeframe. That is, 95% of the updates to the DNS during a Monthly Timeframe will be completed within 60 minutes.
Update Frequency - Whois = 60 minutes for 95%
The committed performance specification with regards to Update frequency for the Whois is 60 minutes for 95% of the transactions during a Monthly Timeframe. That is, 95% of the updates to the Whois during a Monthly Timeframe will be completed within 60 minutes.
24.1.6. RTT
We define the RTT for EPP by assuming that the round-trip time is 120 milliseconds for trans-Pacific communications, 100 milliseconds for trans-American communications, 120 milliseconds for trans-Atlantic communications, 120 milliseconds between EU and South Africa, and 460 milliseconds for the communications with South Africa, one of the most distant locations for us.
RTT - EPP session-command = 4,000 milliseconds for 90%
Since the Processing Time is defined as 200 milliseconds for 90%, we believe the time frame of 660 milliseconds, including communication time, is sufficient for returning the response. Assuming packet loss, delay, and other events beyond our control, we define this as 4,000 milliseconds for 90%.
RTT - EPP query-command = 2,000 milliseconds for 90%
Since the Processing Time is defined as 100 milliseconds for 90%, we believe the time frame of 560 milliseconds, including communication time, is sufficient for returning the response. Assuming packet loss, delay, and other events beyond our control, we define this as 2,000 milliseconds for 90%.
RTT - EPP transform-command = 4,000 milliseconds for 90%
Since the Processing Time is defined as 200 milliseconds for 90%, we believe the time frame of 660 milliseconds, including communication time, is sufficient for returning the response. Assuming packet loss, delay, and other events beyond our control, we define this as 4,000 milliseconds for 90%.
24.1.7. Performance Specification Matrix
Table_24-1_Performance Specification Matrix.pdf

24.2. SRS system description
Only the EPP will be available for the interface between registry and registrar in .ntt. The Web and other non-EPP interfaces will not be provided for domain-name registration.
ʺFigure_24-1_Outline of System Configuration.pdfʺ outlines the system configuration. For the coordination between systems, the answer for #24.2.3 (Interconnectivity with Other Registry Systems) describes the overview and the answer for #31 (Technical overview of proposed registry) describes the detail focusing on the data flow.

Figure_24-1_Outline of System Configuration.pdf
24.2.1. Network Diagram
All the servers constituting the SRS will be duplicated to avoid the system outage due to single fault.
ʺFigure_24-2_Overview of Network Configuration.pdfʺ shows the network configuration for SRS:

Figure_24-2_Overview of Network Configuration.pdf
24.2.2. Servers
All the server database applications constituting the SRS will be duplicated to avoid the system outage due to a single fault. In addition, to improve the processing performance, we will apply the load sharing scheme by operating the duplicated servers in active⁄active mode.

24.2.3. Interconnectivity with Other Registry Systems
Coordination within Registry systems
The following functions will have the direct contact point with SRS within the Registry System (please refer to ʺFigure_24-1_Outline of System Configuration.pdfʺ) :
* DNS (including DNSSEC)
* Whois, Zone File Access, Bulk Registration Data Access
* Data Escrow
As stated in #24.1.5 (Update Frequency), DNS and Whois will be synchronized through batch processing at intervals of 60 minutes.
For Zone File Access and Bulk Registration Data Access, the data will be retrieved once a day and made ready for downloading:The answer for #26 (Whois) provides the details.
For Data Escrow, the data will be retrieved once a day and transferred to Escrow Agent:The answer for #38 (Escrow) provides the details.
Coordination with Secondary site
In addition to the .ntt SRS in Primary Site, which will provide the service during normal operation, we will implement another SRS which will be operated in a hot-standby mode in the Secondary Site, to prepare for the impaired services in the Primary Site due to a large-scale disaster or other events. Any changes applied to the SRS database in the Primary Site will be reflected on the SRS in the Secondary Site through synchronization within one minute. The batch processing will be used for the synchronization from the Primary Site to the Secondary Site.
24.3. Technical resources
24.3.1. System Building and Operation Performance of .ntt Registry Operator
The .ntt Registry Operator has experiences in building and operating the registry systems, and has several staff members with abundant experiences and expertise in running a stable SRS operation.

24.3.2. Registrar System Building and Operation Performance of .ntt Registry Operator
Certified as ICANN-Accredited Registrar, the .ntt Registry Operator has experiences of building and operating the registrar system that communicates with SRSs via EPP, and has several staff members with abundant experiences and expertise in operating the EPP interface system.

24.4. Resource Planning
24.4.1. Initial Implementation
The resources required for building and setting up the networks and servers are described in the answer for (a-1) of #31.5.1 (Initial Implementation).
The resources required for the development of the software (EPP interface) are described in the answer for (b-1) of #31.5.1 (Initial Implementation). The resources required for building and setting up the SRS database are described in the answer for (c-1) of #31.5.1 (Initial Implementation).
24.4.2. Ongoing Maintenance
The resources required for the maintenance of the software (EPP interface) are described in the answer for (d-1) of #31.5.2 (Ongoing Maintenance). The resources required for the maintenance of the SRS database are described in the answer for (e-1) of #31.5.2 (Ongoing Maintenance).

25.1. EPP
.ntt will be firmly committed to supporting EPP 1.0 through the use of our SRS. Additionally, in order to stay current with evolving standards, .ntt will implement support for updates to RFCs 5730, 5731, 5732, 5733, 5734, and other related updates that will be adopted as the ʺProposed Standard [RFC 2026, section 4.1.1].ʺ This support will become available in production within 180 days of ICANNʹs approval of the ʺProposed Standardʺ specifications. Additionally, in order for us to become compatible with the most current protocol, we will adopt flexible policies to support the use of the obsolete extensions by registrars, and will implement applicable EPP extensions which meet the current standards and make them available in a test environment.
Thick Model:
We will adopt the ʺthickʺ data model to provide the .ntt Registry. We will operate the Registry with complete thick data and provide the EPP interface compatible with domains, hosts, contacts and other required commands. The referenced schemas are epp-1.0 eppcom-1.0, domain-1.0, host-1.0, contact-1.0, idn-1.0, rgp-1.0, secDNS-1.1 or later versions.
Localized Message Support:
The .ntt SRS will allow specifying the language for ʺOPTIONALʺ messages in several EPP responses, and the languages available will be notified by 〈greeting〉 with a language code specified in RFC4646. If the language is not specified in the 〈login〉 command, then the message in ʺenʺ (English) will be used as default. .ntt will support the message output in ʺjaʺ (Japanese) and support the encoding as UTF-8.
IDN:
.ntt will support IDN in compliance with IDNA2008. IDN is discussed in more detail in the answer for #44 (IDNs). .ntt will support and accept the XML encoding such as UTF-8 and UTF-16, and UTF-8 will be used as default.
Redemption Grace Period (RGP) :
.ntt will support the RGP which conforms to RFC3915. The EPP will accept ʺrestore requestʺ and ʺrestore reportʺ submitted in the format specified in RGP 1.0.
EPP Applications Security:
The .ntt SRS will conform to RFC5734, and implement the protection via SSL⁄TLS protocol to offer the TCP communications between servers and clients. In addition, the .ntt SRS will follow the technical updates released by IETF.
Information Notice via Polling:
Notice using poll commands will be available to registrars as a method of notification. The poll command notifies registrars of the transition state during the transfer, insufficient funds in the account, and other appropriate information.
25.1.1. Domain Object
For DOMAIN object, .ntt will allow to set all the OPTIONAL items described in RFC5731. Following are the server policies for setting values:
〈check〉 command
One or more 〈name〉 elements can be contained in a request of 〈check〉 command. In return, the response will indicate, for each 〈name〉 element, whether or not the registration is available or not. In the response, the value of 〈avail〉 attribute will be set to ʺ1ʺ when the registration is available and the attribute will be set to ʺ0ʺ when the registration is not available. The reasons for the registration unavailability will be sent in the 〈reason〉 element, and at the same time, if a specific language had been selected for the ʺlangʺ attribute as a result of the negotiation with the client, then the information will be shown in such language.
〈create〉 command
.ntt will support DNSSEC. The DNSSEC will conform to RFC5910, and the schema used for the application will be secDNS-1.1, but secDNS-1.0 will not be supported:More details will be provided in the answer for #43 (DNSSEC).
.ntt will support the IDN registration, and the detailed description is provided in the answer for #44 (IDNs).
Since .ntt will handle the complete thick data model, the registration of 〈registrant〉 and 〈contact〉 element will be mandatory. The 〈contact〉 element must contain one or more values for each of ʺadmin,ʺ ʺbilling,ʺ and ʺtech.ʺ
The 〈period〉 element will be OPTIONAL. If no value is set in the request, a one year registration period will be set as a default, and a value of one to ten years can be permitted as the registration period. The period must be set in units of years, and if the period is set in units of months or more than ten years, then the request will generate a server policy error response.
〈info〉 command
The 〈info〉 command will control the content of response according to 〈authInfo〉 element. If the 〈authInfo〉 element is not specified, then the response for domain information will consist only of 〈name〉, 〈roid〉 and 〈clID〉. If the request includes an appropriate 〈authInfo〉 element, then all the items available as domain information will be returned in the response. This response will include the grace period information conforming to RFC3915. If the request includes an illegal 〈authInfo〉 element, then the error response will be returned without any domain information.
〈renew〉 command
The 〈period〉 element will be OPTIONAL. If no value is set in the request, a one year of registration period will be set as a default, and a value of one to ten years will be permitted as the registration period. The period must be set in units of years, and if the period is set in units of months or more than ten years, then the request will generate a server policy error response.
25.1.2. Host Object
For the host object, .ntt will conform to RFC5732, and all the items will be allowed to use. Following are the server policies for setting values:
〈check〉 command
One or more 〈name〉 elements can be contained in a request of 〈check〉 command. In return, the response will indicate, for each 〈name〉 element, whether or not the registration is available or not.
In the response, the value of 〈avail〉 attribute will be set to ʺ1ʺ when the registration is available and the attribute will be set to ʺ0ʺ when the registration is not available. The reasons for the registration unavailability will be sent in the 〈reason〉 element, and at the same time, if a specific language had been selected for the ʺlangʺ attribute as a result of the negotiation with the client, then the information will be shown in such language.
25.1.3. Contact Object
For the contact object, .ntt will conform to RFC5733, and all the items will be allowed to be used. Following are the server policies for setting values:
〈check〉 command
One or more 〈id〉 elements can be contained in a request of 〈check〉 command. In return, the response will indicate, for each 〈id〉 element, whether or not the registration is available or not. In the response, the value of 〈avail〉 attribute will be set to ʺ1ʺ when the registration is available and the attribute will be set to ʺ0ʺ when the registration is not available. The reasons for the registration unavailability will be sent in the 〈reason〉 element.
〈create〉 command
All the items described in Section 2 of RFC5733, can be registered. In principle, the information in the English language must be registered, and for OPTIONAL, the registration in the Japanese language will be accepted, if ʺlocʺ is specified in postalInfoEnumType of 〈potalInfo〉. Languages other than English and Japanese will not be accepted.
〈info〉 command
The 〈info〉 command controls the content of response according to 〈authInfo〉 element. If the 〈authInfo〉 element is not specified, then the contact information excluding the items not subject to public posting (〈disclose flag=ʺ0ʺ〉) will be returned. If the request includes appropriate 〈authInfo〉 element, then all the items available as contact information will be returned in the response, regardless of the specification of disclose flags. When Request includes an inappropriate 〈authInfo〉 element, the error response is returned with no contact information.
25.2. EPP Extension
We do not plan for proprietary EPP extensions for .ntt. If we decide to create a proprietary EPP extension in the future, then we will follow the guideline described in RFC3735, and document the Extension according to the ʺInternet-Draftʺ format. Prior to implementation, we will then provide ICANN with the documents related to the supported EPP objects and the Extension, and we will update the documents accordingly.

25.3. Technical Resources
25.3.1. Implementations and Operations Experiences
The Registry Operator for .ntt is an ICANN accredited Registrar. The Registry⁄Registrar has the experiences in implementing and operating the SRS and EPP Registrar systems that require network communications, and has the knowledge in implementing and operating the RFC-compliant SRS.
Also, the Registry Operator has the sufficient know-how to operate as the Registrar in building the EPP Client system, specifically for example, know-how of the XML Schema management associated with each TLD, the TCP communication management, the session management and the implementation of polling functions through resident processes. The Registry Operator will be ready to promptly respond to any changes that take place in the specifications such as DNSSEC and IDN. Additionally, as a registrar serving various TLDs, the Registry Operator has built the architecture flexible enough to cope with proprietary EPP extensions of each SRS, and therefore has the abundant practical experiences and understanding on EPP extensions as well as the standard EPP specifications.

25.4. Resource Planning
25.4.1. Initial Implementation
The resources required for the EPP in terms of its implementations are described in the answer for (b-1) of #31.5.1 (Initial Implementation).
25.4.2. Ongoing Maintenance
The resources required for the EPP in terms of its ongoing maintenance are described in the answer for (d-1) of #31.5.2 (Ongoing Maintenance).

.ntt will provide the following registration data publication services:
* Whois (Port 43Whois and Web-based Whois)
* Zone file access
* Bulk data access to ICANN
As per the above services and their data items, in the event that ICANN introduces⁄specifies alternative formats or protocols, we will implement such alternative specifications as soon as possible, to the utmost extent in a reasonable manner.

26.1. Whois specifications
26.1.1. Port 43 Whois Specifications
Based on RFC3912, we will provide the Whois services available via Port 43. The services will be provided over the Port 43 whois.nic.ntt, and will be available to the entire internet users free of charge. The information to be provided will include domain names, Registrars and nameservers, and the query result will only be provided if thereʹs a complete match between the query string and a record (name) that exists in the database. We will not offer search functions such as partial and wildcard search, and the information (search result) that will be displayed is described in more detail in the answer for #26.1.3 (Provided Data Items).
26.1.2. Web-based Whois Specifications
We will provide the Web-based Whois service. The URL of the Web-based Whois service will be whois.nic.ntt, and the service will be implemented using the http protocol for the entire internet users free of charge. The information and provisions that Web-based Whois service will offer will conform to the ones that of Port 43 Whois.
26.1.3. Provided Data Items
The information (data items) that will be provided by the Port 43 Whois and the Web-based Whois services are as follows:
Domain Name Data
Query Type:Requested with a specific domain name:
ʺexample.nttʺ
Response example:
Domain Name:EXAMPLE.NTT
Domain ID:D1234567-NTT
WHOIS Server:whois.example.ntt
Referral URL:http:⁄⁄www.example.ntt
Updated Date:2009-05-29T20:13:00Z
Creation Date:2000-10-08T00:45:00Z
Registry Expiry Date:2010-10-08T00:44:59Z
Sponsoring Registrar:EXAMPLE REGISTRAR LLC
Sponsoring Registrar IANA ID:5555555
Domain Status:clientDeleteProhibited
Domain Status:clientRenewProhibited
Registrant ID:5372808-ERL
Registrant Name:EXAMPLE REGISTRANT
Registrant Organization:EXAMPLE ORGANIZATION
Registrant Street 1:123 EXAMPLE STREET
Registrant Street 2:
Registrant Street 3:
Registrant City:ANYTOWN
Registrant State⁄Province:AP
Registrant Postal Code:A1A1A1
Registrant Country:EX
Registrant Phone:+1.5555551212
Registrant Phone Ext:1234
Registrant Fax:+1.5555551213
Registrant Fax Ext:4321
Registrant Email:email@example.ntt
Admin ID:5372809-ERL
Admin Name:EXAMPLE REGISTRANT ADMINISTRATIVE
Admin Organization:EXAMPLE ADMIN ORGANIZATION
Admin Street 1:123 EXAMPLE STREET
Admin Street 2:
Admin Street 3:
Admin City:ANYTOWN
Admin State⁄Province:AP
Admin Postal Code:A1A1A1
Admin Country:EX
Admin Phone:+1.5555551212
Admin Phone Ext:1234
Admin Fax:+1.5555551213
Admin Fax Ext:
Admin Email:email@example.ntt
Tech ID:5372811-ERL
Tech Name:EXAMPLE REGISTRAR TECHNICAL
Tech Organization:EXAMPLE REGISTRAR LLC
Tech Street 1:123 EXAMPLE STREET
Tech Street 2:
Tech Street 3:
Tech City:ANYTOWN
Tech State⁄Province:AP
Tech Postal Code:A1A1A1
Tech Country:EX
Tech Phone:+1.1235551234
Tech Phone Ext:1234
Tech Fax:+1.5555551213
Tech Fax Ext:93
Tech Email:email@example.ntt
Name Server:NS01.EXAMPLEREGISTRAR.NTT
Name Server:NS02.EXAMPLEREGISTRAR.NTT
DNSSEC:Signed
〉〉〉 Last update of WHOIS database:2009-05-29T20:15:00Z 〈〈〈
Registrar Data
Query Type:Requested with the keyword, ʺregistrar,ʺ followed by a specific registrar name:
registrar ʺExample Registrar Inc.ʺ
Response example:
Registrar Name:Example Registrar, Inc.
Street 1:Example-heights #302
Street 2:1234 Admiralty Way
Street 3:
City:Marina del Rey
Postal Code:90292
State⁄Province:CA
Country:US
Phone Number:+1.3105551212
Fax Number:+1.3105551213
Email:registrar@example.ntt
WHOIS Server:whois.example-registrar.ntt
Referral URL:http:⁄⁄www.example-registrar.ntt
Admin Contact:Joe Registrar
Phone Number:+1.3105551213
Fax Number:+1.3105551213
Email:joeregistrar@example-registrar.ntt
Admin Contact:Jane Registrar
Phone Number:+1.3105551214
Fax Number:+1.3105551213
Email:janeregistrar@example-registrar.ntt
Technical Contact:John Geek
Phone Number:+1.3105551215
Fax Number:+1.3105551216
Email:johngeek@example-registrar.ntt
〉〉〉 Last update of WHOIS database:2009-05-29T20:15:00Z 〈〈〈
Nameserver Data
Query Type:Requested with a specific nameserver, or the keyword, ʺnameserver,ʺ followed by an IP address of that specific nameserver.
ns1.example.ntt
or
nameserver (IP Address)
Response example:
Server Name:NS1.EXAMPLE.NTT
IP Address:192.0.2.123
IP Address:2001:0DB8::1
Registrar:Example Registrar, Inc.
WHOIS Server:whois.example-registrar.ntt
Referral URL:http:⁄⁄www.example-registrar.ntt
〉〉〉 Last update of WHOIS database:2009-05-29T20:15:00Z 〈〈〈
26.1.4. Search Functions
No search function will be provided.
26.1.5. SLA
In our Service Level Agreement (SLA), the Whois service will be defined as shown below:
Whois Service Availability = 98% (monthly)
The service availability for Whois refers to the condition where internet users can access and use the Whois service. The committed service availability by .ntt for Whois is 98% per calendar month.
Whois Planned Outage = will not be implemented
.ntt will not implement Planned Outages for Whois.
Whois Extended Planned Outage = will not be implemented
.ntt will not implement Extended Planned Outages for Whois.
Whois Processing Time = 100 milliseconds for 95%
The performance specification will be 100 milliseconds for 95% of the queries processed. This means that 95% of the queries will take 100 milliseconds or less to respond, from the time the service receives the query to the time the service provides a response.
Whois Update Frequency = 60 minutes for 95%
The committed performance specification with regards to the frequency of updates for Whois is 60 minutes for 95% of the transactions during a monthly timeframe. This means that 95% of the updates to the Whois database during a monthly timeframe will be completed within 60 minutes.
Whois RTT = 2,000 milliseconds for 95%
We define the RTT for Whois by assuming that the round-trip takes 120 milliseconds for trans-Pacific communications, 100 milliseconds for trans-American communications, 120 milliseconds for trans-Atlantic communications, 120 milliseconds between EU and South Africa, and 460 milliseconds for the communications with South Africa, one of the most distant locations from Japan.
Since the processing time is defined as 100 milliseconds for 95%, we believe the time frame of 560 milliseconds including communication time will be sufficient for returning a response. However, considering the packet loss, delay, and other possible events beyond our control, we define the SLA as 2,000 milliseconds for 95%.

26.2. Specifications for Zone File Access Provision
26.2.1. Zone File Access
The .ntt Registry Operator will provide the Zone File FTP service for ICANN-specified and managed URL (ntt.zda.icann.org) to enable the user to access .nttʹs zone data archives.
The .ntt Registry Operator will grant to the user a non-exclusive, non-transferable, and limited right to access .ntt Registry Operator ʹs zone file FTP server, and to transfer a copy of the top-level domain zone files and any associated cryptographic checksum files, no more than once per 24 hour period using FTP.
The zone files called ʺntt.zone.gzʺ will be in the top-level directory of zone file access server, with the files to verify downloads ( ntt.zone.gz.md5 and ntt.zone.gz.sig).
The zone files will be provided to the users who have concluded the agreement through the Centralized Zone Data Access Provider (the ʺCZDA Providerʺ). The agreement has a term of three months or more, and this term can be renewed. The users can access the zone file at no cost. The .ntt Registry Operator will co-operate and provide reasonable assistance to ICANN and the CZDA Provider to facilitate and maintain the efficient access to zone file data by the permitted users.

26.2.2. File Format Standard
The .ntt Registry will provide zone files using a sub format of the standard Master File format as originally defined in Section 5 of RFC 1035, including all the records present in the actual zone used in the public DNS. The zone files will be generated in accordance with new gTLD agreement specifications.
Zone File Example:
------------------------------------------------------------------------------------------------------------------------------------------------------
ntt.〈tab〉86400〈tab〉in〈tab〉soa〈tab〉tld1.dns.ntt.〈tab〉root.dns.ntt.〈tab〉1317321902〈tab〉3600〈tab〉900〈tab〉1814400〈tab〉900
example.ntt.〈tab〉86400〈tab〉in〈tab〉ns〈tab〉ns1.example.ntt.
example2.ntt.〈tab〉86400〈tab〉in〈tab〉ns〈tab〉ns1.example2.ntt.
example2.ntt.〈tab〉86400〈tab〉in〈tab〉ns〈tab〉ns2.example.jp.
ns1.example.ntt.〈tab〉86400〈tab〉in〈tab〉aaaa〈tab〉2001:0dc8:0000:0000:0000:0000:0000:0001
ns1.example2.ntt.〈tab〉86400〈tab〉in〈tab〉a〈tab〉192.0.2.1
ntt.〈tab〉86400〈tab〉in〈tab〉soa〈tab〉tld1.dns.ntt.〈tab〉root.dns.ntt.〈tab〉1317321902〈tab〉3600〈tab〉900〈tab〉1814400〈tab〉900
------------------------------------------------------------------------------------------------------------------------------------------------------
* 〈tab〉 means tab character
26.2.3. For ICANN Access
The .ntt will provide bulk access to the .ntt zone files to ICANN or its designee on a continuous basis (ICANN may change⁄specify the designee occasionally in a reasonable manner).

26.2.4. For Emergency Operator Access
The .ntt will provide bulk access to the .ntt zone files to the Emergency Operators designated by ICANN on a continuous basis (ICANN may change⁄specify the Emergency Operator occasionally in a reasonable manner).

26.3. Specifications to provide the bulk data access to ICANN
26.3.1. Periodic Access
The Registry Operator will provide ICANN with the most up-to-date registration data, on the date ICANN designates every week. The data to be provided will include the data committed as of 00:00:00 UTC on the day previous to the one designated for retrieval by ICANN. Although, SFTP will be used for downloading, if ICANN requests for other means for downloading in the future, then we will use a compatible means.
26.3.2. Exceptional Access
At the request of ICANN, .ntt will provide ICANN with the most up-to-date data for the domain names of the Registrar that will be losing their accreditation. The data file will only contain data related to the domain names of the Registrar losing accreditation. We will prepare the data within 2 business days after the request.

26.3.3. Data Specifications
The provided bulk data shall be ʺthickʺ data in full deposit for both the periodic access and the exceptional access, and include sufficient information as the material to restart the registry activities. The data will be made available in the same format as the one adopted in the Data Escrow service, i.e., up-to-date version of Internet-Draft [draft-arias-noguchi-registry-data-escrow] and [draft-arias-noguchi-dnrd-objects-mapping]. We will implement this Internet-Draft within 180 days of it becoming an RFC.
The Internet-Draft can be found in the flowing URL:
http:⁄⁄tools.ietf.org⁄html⁄draft-arias-noguchi-registry-data-escrow-03
http:⁄⁄tools.ietf.org⁄html⁄draft-arias-noguchi-dnrd-objects-mapping-00

26.4. Whois System Description
26.4.1. System Configuration Diagram

Figure_26-1_Whois System Configuration Diagram.pdf
26.4.2. Servers
In the Whois (Port 43 Whois and Web-based Whois) system configuration, the services will normally be provided by the Primary site, and in the event of a major disaster and the Primary site becomes unavailable, we will prepare servers on a hot-standby mode in the Secondary site.
The Whois database will synchronize with the SRS database in 60-minute intervals. To prepare for failure on the Whois database, we will configure the application servers to refer directly to the SRS Database in such event. The same configuration will be implemented to the Secondary Site, thus in the event of a site switchover, the service interface will be provided immediately.
The data access functions (Zone data files and Bulk data files) will be provided upon account certification by the SFTP Servers and FTP Servers.
26.4.3. Interconnectivity with Other Registry Systems
The Whois database will be an independent database synchronized with the SRS database at 60-munite intervals, and therefore it will be able to operate without being influenced by the SRS database load. The data registered or updated in the SRS database will be reflected on the Whois database within 60 minutes or so.
26.5. Technical Resources
26.5.1. Implementations and Operations Experiences as Registry
The Registry Operator for .ntt, as a Registry, has operational experiences in supporting the Whois service consist of more than 1.25 million domain names. Also, as a responsibility of ccTLD Registry using a unique language, it has been contributing to the IDN standardization. The Registry Operator will provide the Port 43 Whois interface capable of switching the languages between English and Japanese for the response, and will provide the Web-based Whois interface which enables entering and displaying of both IDN and Punycode.

26.5.2. Implementations and Operations Experiences as Registrar
The Registry Operator for .ntt, as an ICANN-accredited Registrar, has experiences in providing the Whois services, and it has the technical resources to stably provide the Whois service for .ntt.
26.6. Resource Planning
26.6.1. Initial implementation
The resources required for the implementation of network servers are described in the answer for (a-1) of #31.5.1 (Initial Implementation).
In terms of the Whois (Port 43 and Web-based) software development, the resources required are explained in the answer for (b-2) of #31.5.1 (Initial Implementation).
As per the resources required for the implementation of the Whois databases and the synchronizations, we have answered in (c-1) of #31.5.1 (Initial Implementation).
26.6.2. Ongoing Maintenance
The resources required for the Whois (Port 43 and Web-based) software, in terms of ongoing maintenance, are described in the answer for (d-2) of #31.5.2 (Ongoing Maintenance).
As per the resources required for the ongoing maintenance of the Whois databases and the synchronizations, we have answered in (e-1) of #31.5.2 (Ongoing Maintenance).

The current state of the domain name registration will be managed by using two statuses; status defined in RFC5731 (hereinafter called ʺEPP statusʺ) and status extended by RFC3915 (ʺRPG statusʺ).
27.1. List of Domain Statuses
The list of the domain name statuses of the registration is as follows. The statuses of Registry Lock and Registrar Lock will be described in the answer for #27.2 (Registry Lock and Registrar Lock).
No. 1:EPP Status = ok and RGP Status = addPeriod
This is a status immediately following the new registration. The Grace Period is 5 calendar days, and when 〈delete〉 command for removal is issued within the Grace Period, the deletion process starts without giving redemption by 〈restore〉. When the Grace Period (5 calendar days) is expired, the RGP status will be removed (change to Status No. 2).
The domain name in this status will be subject to the zone file extraction.
No. 2:EPP Status = ok and RGP Status = N⁄A
This is a status in which the nameserver is operational for DNS resolution.
The domain name in this status will be subject to the zone file extraction.
No. 3:EPP:ok RGP:autoRenewPeriod
This is a status right after the ExpirationDate, where the domain name registration status has been automatically retained. The Grace Period is 45 calendar days, and when 〈delete〉 command for removal is issued within the Grace Period, the deletion process starts after giving redemption by 〈restore〉.
When the Grace Period (45 calendar days) is expired, the RGP status will be removed (change to Status No. 2).
The domain name in this status will be subject to the zone file extraction.
No. 4:EPP Status = ok and RGP Status = renewPeriod
This is a status in which the domain name registration status has been retained by 〈renew〉 command. The Grace Period is 5 calendar days, and when 〈delete〉 command for removal is issued within the Grace Period, the deletion process starts after giving redemption by 〈restore〉.
When the Grace Period (5 calendar days) is expired, RGP status will be removed (change to Status No. 2).
The domain name in this status will be subject to the zone file extraction.
No. 5:EPP Status = clientHold and RGP Status = N⁄A
This is a status in which the domain name is no longer valid at the request of the Registrar.
The domain name in this status will NOT be subject to the zone file extraction.
No. 6:EPP Status = serverHold and RGP Status = N⁄A
This is a status in which the domain name is no longer valid due to the Registry requirements.
The domain name in this status will NOT be subject to the zone file extraction.
No. 7:EPP Status = pendingTransfer and RGP Status = N⁄A
This is a status in which the transfer request is accepted and is waiting for the acknowledgment by the current (losing) Registrar.
The domain name in this status will be subject to the zone file extraction.
No. 8:EPP Status = ok and RGP Status = transferPeriod
This is a status right after the transfer completion. The Grace Period is 5 calendar days, and when 〈delete〉 command for removal is issued within the Grace Period, the deletion process starts after giving redemption by 〈restore〉.
When the Grace Period (5 calendar days) is expired, the RGP status will be removed (change to Status No. 2).
The domain name in this status will be subject to the zone file extraction.
No. 9:EPP Status = pendingDelete and RGP Status = redemptionPeriod
This status indicates right after the domain name has been removed by 〈delete〉 command, and it can be restored by a request.
The Grace Period is 30 days, and the restore request will be accepted during this period.
The domain name in this status will NOT be subject to the zone file extraction.
No. 10:EPP Status = pendingDelete and RGP Status = pendingRestore
This is a status in which the domain has been removed after receipt of 〈delete〉 command. The Grace Period is 7 calendar days, and if the Report is received, the EPP status will become ʺokʺ and the RGP status will be removed (change to Status No. 2).
If the Report is not received, the status returns to ʺRGP = redemptionPeriodʺ (change to Status No. 9).
No. 11:EPP Status = pendingDelete and RGP Status = pendingDelete
This is a status in which the status ʺRGP = redemptionPeriodʺ has expired, and it is under the removal procedure. In this status, 〈restore〉 command cannot be accepted, and after a period of 5 calendar days, the domain name can be re-registered.
If two nameservers are not implemented then the status will become inactive instead of ʺok.ʺ
Also, because the .ntt system will respond without submitting 〈create〉, 〈renew〉 and 〈update〉 commands with either successful or not successful, it will not use the following commands:
* pendingCreate
* pendingRenew
* pendingUpdate
All the major transitional states excluding Registry Lock, Registrar Lock and Inactive, are shown in the diagram below (Figure_27-1_Domain Transition State Diagram.pdf) :

Figure_27-1_Domain Transition State Diagram.pdf
27.2. Registry Lock and Registrar Lock
27.2.1. Registry Lock
The following EPP status values will be used to indicate Registry Lock:
serverDeleteProhibited
The Registry will set the 〈 delete 〉 command to be locked.
serverRenewProhibited
The Registry will set the 〈 renew 〉 command to be locked.
serverTransferProhibited
The Registry will set the 〈 transfer 〉 command to be locked.
serverUpdateProhibited
The Registry will set the 〈 update 〉 command to be locked.
27.2.2. Registrar lock
The following EPP status values will be used to indicate Registrar Lock:
clientDeleteProhibited
The Registrar will set the 〈 delete 〉 command to be locked.
clientRenewProhibited
The Registrar will set the 〈 renew 〉 command to be locked.
clientTransferProhibited
The Registrar will set the 〈 transfer 〉 command to be locked.
clientUpdateProhibited
The Registrar will set the 〈 update 〉 command to be locked, except for the change in status.
27.3. Grace Period
The following Grace Period will be used for the RGP Status:
Add Grace Period
RGP Status = addPeriod will be set to 5 calendar days.
Auto Renew Grace Period
RGP Status = autoRenewPeriod will be set to 45 calendar days.
Renew Grace Period
RGP Status = renewPeriod will be set to 5 calendar days.
Transfer Grace Period
RGP Status = transferPeriod will be set to 5 calendar days.
Redemption Grace Period
RGP Status = redemptionPeriod will be set to 30 calendar days.
Pending Restore
RGP Status = pendingRestore will be set to 7 calendar days.
Pending Delete
RGP Status = pendingDelete will be set to 5 calendar days.
27.4. Technical Resources
27.4.1. System Implementations and Operations Experiences as Registry
The Registry Operator of .ntt has experiences in managing domain name registrations as a registry, and therefore possesses the technical expertise to manage the domain name Registration Life Cycle.
27.4.2. System Implementations and Operations Experiences as Accredited Registrar
The Registry Operator of .ntt, as an ICANN-accredited Registrar, has abundant experiences in implementing the Registry services systems, and therefore possesses the expertise to manage the domain name Registration Life Cycle.
27.5. Resource Planning
27.5.1. Initial Implementation
The resources required for implementing the Life Cycle of Registration is described in the answer for (b-1) of #31.5.1 (Initial Implementation).
27.5.2. Ongoing maintenance
The resources required for the ongoing maintenance of the Life Cycle of Registration is explained in the answer of (d-1) of #31.5.2 (Ongoing Maintenance).

28.1.  Abusive Prevention & Mitigation
As described in the answers for #18 (Mission⁄purpose), .ntt will restrict the registration and the use of the domain names to NTT and NTT Subsidiaries.  NTT will evaluate and qualify the second level domain name prior to registering any additional domain names to .ntt, and through this proprietary process, NTT projects no more than about 1,000 domain name registrations for .ntt.
28.2.  Single Point of Contact for Abusive Activities
As the .ntt Registry, NTT will establish and publish the following notification on our own .ntt website:
Example:
For any abusive or illegal activities occurring within the .ntt namespace, please report or contact NTT as follows:
Email:abuse-contact@registry.ntt (TBD)
Mailing address: (TBD)
NTT will do our utmost to respond to all inquiries within 72 hours.  However, if for any reason we are unable to respond within 72 hours, then an auto-reply message will be sent acknowledging that NTT has received the inquiry and that it is currently under investigation.
--------------------------------------------------------------------------------------------------------
The above notification will be provided on the NTT official Web site, in both English and Japanese.
As the .ntt Registry, we will collaborate cohesively with the Registrar to address and resolve any potential abusive registration.
28.3.  Anti-abuse Policy
NTT is committed to developing and implementing policies that minimize abusive registration activities that affect the legal rights of others.  The following is the current proposed draft of the ʺ.ntt Anti-Abuse Policy.ʺ
--------------------------------------------------------------------------------------------------------
.ntt Anti-abuse Policy (draft)
NTT is committed to minimizing abusive registration activities and other illegal activities within the .ntt namespace, by including the following legal terms and conditions into all .ntt domain name registration agreements:
The nature of such abuses creates security and stability issues for the registries, registrars and registrants, as well as for the users of the Internet in general.  NTT defines abusive use of a domain name to include, without limitation, the following illegal or fraudulent actions
- Botnet commands and control:Services run on a domain name that are used to control a collection of compromised computers or ʺzombies,ʺ or to direct denial-of-service attacks (i.e.  DDoS attacks) ;
- Distribution of child pornography;
- Fast flux hosting:Use of fast-flux techniques to disguise the location of Web sites or other Internet services, or to avoid detection and mitigation efforts, or to host illegal activities.  Fast-flux techniques use DNS to frequently change the location on the Internet to which the domain name of an Internet host or name server resolves.  Fast flux hosting may be used only with prior permission of .ntt;
- Pharming:The redirecting of unknowing users to fraudulent sites or services, typically through DNS hijacking or poisoning;
- Phishing:The use of counterfeit Web pages that are designed to trick recipients into divulging sensitive data such as usernames, passwords, or financial data;
- Spam:The use of electronic messaging systems to send unsolicited bulk messages.  The term applies to e-mail spam and similar abuses such as instant messaging spam, mobile messaging spam, and the spamming of Web sites and Internet forums.  An example, for purposes of illustration, would be the use of email in denial-of-service attacks;
- Willful distribution of malware:The dissemination of software designed to infiltrate or damage a computer system without the ownerʹs informed consent.  Examples include, without limitation, computer viruses, worms, keyloggers, and trojan horses; and
- Illegal Access to Other Computers or Networks:Illegally accessing computers, accounts, or networks belonging to another party, or attempting to penetrate security measures of another individualʹs system (often known as ʺhackingʺ).  Also, any activities that might be used to attempt on system penetration (e.g.  port scan, stealth scan, or other information gathering activity) are included.
NTT will reserve the right to deny, cancel or transfer any registration or transaction, or place any domain name (s) on registry lock, hold or similar status as it deems necessary, in its discretion; (1) to protect the integrity and stability of the registry; (2) to comply with any applicable laws, government rules or requirements, requests of law enforcement, or any dispute resolution process; (3) to avoid any liability, civil or criminal, on the part of NTT, as well as its affiliates, subsidiaries, officers, directors, and employees; (4) per the terms of the registration agreement; (5) to correct mistakes made by NTT or any Registrar in connection with a domain name registration; or (6) due to abusive uses, as defined above, undertaken with respect to .ntt domain names.  NTT also reserves the right to place upon registry lock, hold or similar status a domain name during resolution of a dispute.
All reports of abuse should be sent to abuse-contact@registry.ntt (TBD).
--------------------------------------------------------------------------------------------------------
28.4.  Removal of Orphan Glue Records
.ntt has carefully read the guidance provided by ICANNʹs Security and Stability Advisory Committee (SSAC) in SAC 048 (SSAC Comment on Orphan Glue Records in the Draft Applicant Guidebook), and will agree with the following statement:
Orphaned glue can be used for abusive purposes; however, the dominant use of orphaned glue supports the correct and ordinary operation of the DNS.
Please See:http:⁄⁄www.icann.org⁄en⁄committees⁄security⁄sac048.pdf
Therefore, when a registration of a parent domain name is deleted due to expiration, or any other reasons for that matter, the glue record of such parent domain name shall be also deleted.  This practice is consistent with the third registry policy listed in Section 4.3 of the SAC 048.  In addition, the glue records not allocated to .ntt shall not be used in any .ntt zone files.
In addition to the restricted nature of the .ntt TLD, as identified in the answer for #18 (Mission⁄purpose), and working closely with each of the domain name registrants, NTT believes that our implementation of the third registry policy listed in Section 4.3 of the SAC 048 will be the most prudent course of action to mitigate any potential abusive activity within the .ntt namespace.
28.5.  Enforcing Whois Accuracy
As described in the answer for #18 (Mission⁄purpose), the registration and the use of .ntt domain names will be limited to NTT and NTT Subsidiaries.  Therefore, no domain names will be allocated within the .ntt name space unless NTT identifies the requesting party as one of an NTT Subsidiary.
We also ensure that .ntt will promptly update any changes in the .ntt Whois information, and that we will revalidate the Whois information on a periodic basis.
28.6.  Policies and Procedures Regarding Malicious or Abusive Behavior, Capture Metrics, and Establish Service Level Requirements for Resolution, Including Service Levels for Responding to Law Enforcement Requests
As described in the answer for #28.3 (Anti-abuse Policy), NTT will establish the ʺAnti-Abuse Policyʺ including the definition of abusive uses.
As described in the answer for #18 (Mission⁄purpose), we intend to provide the second level domain of .ntt for NTT Subsidiaries, and NTT will be the sole registrant of .ntt.
NTT will take the appropriate measures if NTT receives the investigative documents relevant to domain names registered in .ntt, from any UDRP Providers, URS Providers, and other law enforcements.
28.7.  Adequate Controls to Ensure Proper Access to Domain Functions
As described in the answer for #18 (Mission⁄purpose), NTT will be the sole registrant of .ntt and we intend to provide the second level domain of .ntt for NTT Subsidiaries.
NTT will assign a person in charge for administrating the .ntt domain name registrations (i.e., registration, renewal, modification of registration information, deletion, etc.)
The administrator described above will comply with the NTTʹs company rules, and will be required to obtain an authorization from the supervisor (or a proper manager in charge), for any administrative actions to be taken against .ntt domain names.
The supervisor will manage IDs and Passwords, and if the administrator or supervisor is transferred to another business section then the Passwords will be replaced with new ones.
28.8.  Trademark Protection Mechanism
.ntt will offer a tapestry of original Rights Protection Mechanisms (RPMs), which was envisioned by ICANNʹs Trademark Implementation Recommendation Team (IRT).  The mechanisms include, but not limited to, Closed Registry ⁄ Pre-Verification, Trademark Claims Services, Sunrise Services, Uniform Domain Name Dispute-Resolution Policy (UDRP), Uniform Rapid Suspension System (URS), and Trademark Post Delegation Dispute Resolution Procedure (Trademark PDDRP), and they will minimize the possibility of any abusive registrations within the .ntt.  Each of these proposed RPMs are elaborated in more detail in the answer for #29 (Rights protection mechanisms).
28.9.  Technical Resources
The Registry Operator for .ntt has a proven record of managing over 1.25 million registrations, and has structured a collaborative framework with security industry organizations that have made many efforts and accomplishments to prevent and mitigate abusive activities, including countermeasures for phishing.
28.10.  Resource Planning
.ntt plans to implement necessary countermeasures to prevent and mitigate abusive activities for .ntt.  Nevertheless, the second level domain names of .ntt will be provided for NTT Subsidiaries, and NTT itself will be the sole registrant.  Moreover, as stated in the answer for #18 (Mission⁄purpose), our projection of the registration volume for the foreseeable future is about 1,000 at maximum, and therefore we suspect that the actual corresponding actions for those countermeasures required shall be limited.
The Registry Operator for .ntt will allocate appropriate staff members with substantial experiences in the TLD operations, and the Operator will enforce the countermeasures to prevent and mitigate abusive activities.  As per more detailed and financial information about the allocated staff member is provided in the answer for #47.1.3 (Technical Labor).

29.1. A Tapestry of Rights Protection Mechanisms
.ntt proposes a tapestry of original Rights Protection Mechanisms (RPMs), which was envisioned by ICANNʹs Trademark Implementation Recommendation Team (IRT), and the purpose of the RPMs is to mitigate the potential abusive registrations.
29.1.1. Pre-Verification
As defined in the answer for #18 (Mission⁄purpose), .ntt intends to provide the second level domain of .ntt for the NTT Subsidiaries, and NTT itself will be the sole registrant and the primary user of .ntt. NTT will pre-verify, before registration takes place, the domain name (string) and the applicant (the representing organization) who will become the primary user for the applied domain name (more details explained in the answer for #23 Registry Services).
We believe that this pre-verification process, as the protection mechanism, is equivalent to one of the most effective RPM safeguards to mitigate any potential abusive registrations, and applying this proprietary evaluation⁄authentication process NTT projects no more than 1,000 domain name registrations for .ntt.
29.1.2. Sunrise Services
.ntt is prepared to provide a Sunrise Service for .ntt, as set forth in the Applicant Guidebook.
29.1.3. Trademark Claims Services
.ntt is prepared to implement the Trademark Claims Services (TCS) for .ntt, as set forth in the Applicant Guidebook. Due to the restricted nature of the .ntt and the pre-verification of all domain name registrations (as described in the answer for #29.1.1 (Pre-Verification) ), .ntt does not foresee any difficulties in implementing a TCS. As identified in the answer #29.3 (Resource Planning) below, .ntt is committed to dedicating the necessary staff members and resources to ensure that all RPMs are implemented. Furthermore, .ntt is closely monitoring the work of ICANNʹs Trademark Clearinghouse Implementation Assistance Group, to ensure that NTT implements a best-in-class service for .ntt.

29.1.4. Uniform Domain Name Dispute-Resolution Policy (UDRP)
Due to the restrictive nature of .ntt (as described in the answer for #29.1.1 (Pre-Verification) ), .ntt believes that the probability of dispute proceedings regarding .ntt domain names will be very low. However, .ntt will ensure that all registrant and registrar agreements will legally bind all parties to the UDRP. While the UDRP does not impose any specific requirements on the Registry Operator, .ntt intends to develop a constructive working relationship with all ICANN UDRP providers.

29.1.5. Uniform Rapid Suspension System (URS)
Although .ntt does not foresee any potential URS implementation issues due to the proposed restrictive use of the .ntt, we will be committed to allocating the necessary staff and resources to implement a best in class solution. Specifically, .ntt will ensure the following:
* All .ntt registrant and registrar agreements will legally bind the parties to the terms of the URS;
* All communication received from URS Provider (s) will be logged and sent to the .ntt support staff;
* .ntt will update the EPP status of the domain name to a ʺlockedʺ status within 24 hours of receipt of the Notice of Compliant from the URS Provider;
* The ʺlockedʺ status will enable continued resolution of the domain name, but there will be no changes to the registration data, including the transfer and⁄or deletion of the domain name;
* .ntt will unlock the domain name if the URS Provider notifies it that an Examiner has issued a Determination in favor of the Registrant;
* .ntt will immediately suspend the domain name for the duration of the registration term and update the name servers to point to an URS information webpage maintained upon receipt from the URS Provider that an Examiner has issued a Determination in favor of the Complainant; and
* .ntt will take appropriate actions with regard to the domain name in the event that a Notice of Appeal is filed.
29.1.6. Trademark Post Delegation Dispute Resolution Procedure (Trademark PDDRP)
Although .ntt does not foresee any potential Trademark PDDRP proceedings due to the proposed restrictive use of the .ntt, we will provide this administrative proceeding as an additional RPM mechanism to trademark owners.
29.2. Technical Resources
29.2.1. Precise Administrative Structure for the Domain Name Registration Procedures
The Registry Operator for .ntt has a proven record of managing over 1.25 million registrations, and has structured a collaborative framework with security industry organizations that have resulted in significant efforts and accomplishments. Furthermore, the Operator has the precise administrative structure for the domain name registration procedures.

29.2.2. Development and Implementation of the Uniform Domain Name Dispute-Resolution Policy (UDRP)
The .ntt Registry Operator has a long track record of the experienced operations and implementations that have been developed upon its proprietary domain name dispute-resolution, which derived from the Uniform Domain Name Dispute-Resolution Policy (UDRP), which ICANN has established, and First WIPO Internet Domain Name Process.
Hence, we are confident that .ntt will not have any issues by implementing ICANN UDRP or URS that are required by the Applicant Guidebook.
29.3. Resource Planning
.ntt plans to implement necessary measures for the Rights Protection Mechanisms for .ntt. Nevertheless, the second level domain names of .ntt will be provided for NTT Subsidiaries, and NTT itself will be the sole registrant. Moreover, as stated in the answer for #18 (Mission⁄purpose), our projection of the registration volume for the foreseeable future is about 1,000 at maximum, and therefore we suspect that the actual corresponding actions for those measures required shall be limited.
The Registry Operator for .ntt will allocate appropriate staff members with substantial experiences in the TLD operations, and the Operator will enforce the measures for the Rights Protection Mechanisms. As per more detailed and financial information about the allocated staff member is defined in the answer for #47.1.3 (Technical Labor).

30.1. NTT Groupʹs Information Security Policy and the Information Security related Documents
The Information Security Management Standard is defined in NTT (Holding Company) based on NTT Groupʹs Information Security Policy, which is defined as the top information security document in the NTT Group. Similarly, in terms of information system security, the Iinformation System Security Guideline is defined in NTT (Holding Company), based on the NTT Group Information System Security Guideline. In this section, key measures and procedures to operate registry services will be described in reference to these documents.
30.1.1. NTT Information Security Philosophy and NTT Groupʹs Information Security Policy
NTT fulfills its corporate social responsibilities by recognizing the importance of information in business activities, complying with the relevant laws and regulations such as the Personal Information Protection Act, utilizing information owned by the company in a safe manner based on the social principle. In addition, NTT has established the NTT Groupʹs Information Security Policy as the basic policy of information security in the whole NTT Group.
NTT Groupʹs Information Security Policy is described in #30.6 (NTT Groupʹs Information Security Policy).
30.1.2. Risk Management
NTT shall implement appropriate risk management strategies to support the maintenance and enlargement of the companyʹs value and the companyʹs persistent growth.
The details of .ntt risk management are described in #30.7 (Risk Management).
30.1.3. Information Security Organization
NTT shall establish an internal organization to manage information security and define the respective roles and responsibilities.
The details of information security organization are described in #30.8 (Information Security Organization).
30.1.4. Asset Management
NTT shall classify information in order to manage confidential information properly and all information shall be handled according to the classification level.
The details of asset management are described in #30.9 (Asset Management).
30.1.5. Human Resource Security
In order to prevent security breaches such as human error or misuse, NTT shall implement human resource security such as background checks and security trainings.
The details of human resource security are described in #30.10 (Human Resource Security).
30.1.6. Physical Security
NTT shall implement entry controls for NTT offices and registry related data centers to ensure that only authorized personnel are granted access and to prevent unauthorized access, interference and damage to its business premises.
The details of physical security are described in #30.11 (Physical Security).
30.1.7. Communications and Operations Management
In order to minimize the risk of systems failures, NTT shall establish communications and operations management such as third party service delivery management, network and strage capacity management, protection against malicious and mobile code, backup and monitoring.
The details of communications and operations management are described in #30.12 (Communications and Operations Management).
30.1.8. Access Control
Information systems shall be accessible to only the minimum required personnel and the activities within information system shall be traceable in order to check the responsibility and to prevent unauthorized use of information systems.
NTT shall implement access control such as user access management, privilege management, network access control, mobile computing and teleworking, protection against DoS⁄DDoS attacks and intrusion detection system.
The details of the above are described in #30.13 (Access Control).
30.1.9. Information Systems Acquisition, Development and Maintenance
While developing information systems, NTT shall conduct risk assessment and implement security measures which commensurate with the amount of the damage of failures or security incidents.
The details of information system acquisition, development and maintenance security are described in #30.14 (Information Systems Acquisition, Development and Maintenance).
30.1.10. Information Security Incident Management
NTT shall cope with security incidents rapidly to minimize the impact of damage by defining response procedures when security incidents occur or discovering any attempts which may lead to the security incident occurrence.
The details of information security incident response procedures are described in #30.15 (Information Security Incident Management).
30.1.11. Business Continuity Management
NTT shall ensure to provide the communication method and protect important communication in the occurrence of disaster by cooperating with the group companies etc., establish a disaster prevention organization and clarify the disaster emergency response in order to play a role as a designated public institution adequately.
The NTT Group shall plan and conduct disaster prevention training regularly to be able to carry out disaster prevention work safely and quickly.
30.1.12. Internal Audits
NTT shall conduct internal audits regularly to review the implementation of information security.
The details of internal audit procedures are described in #30.16 (Internal Audits).
30.2. Security Capability of the .ntt Registry Services
As described in the answers for #18 (Mission⁄purpose), the .ntt will restrict the registration and the use of the domain names to within NTT and NTT Subsidiaries and NTT projects that the maximum registration number for .ntt is no more than around 1,000.
The .ntt is built based not only on the best practice of the NTT Group information security but also on the knowledge and skills required to operate registry services, provided by the .ntt Registry Operator . This enable NTT to apply adequate security measures to the .ntt registry services.
30.3. Security Capabilities to the Other Answers in this Application
Various security measures are implemented in .ntt registry services based on the NTT Groupʹs Information Security Policy, the information security related documents.
Security measures implemented in five main registry functions, Shared Registration System, DNS, DNSSEC, Registry Data Publication Services (Whois, Zone File Access, Bulk Registration Data Access), Data Escrow, are described in #30.17 (Security measures implemented in the five main features of the .ntt registry services).
Further detailed technical and operational approaches to implement security measures are described in the other answers of ʹTechnical and Operational Capabilityʹ part of this application.
Also, the resourcing and financial planning are described in the answers of ʹʹFinancial Capabilityʹ part of this application.
30.4. Compliance with the Commitments Made to Registrants
NTT understands that it is very important to provide adequate security to .ntt registry services.
The following are the most important commitments made to registrants regarding its security levels.
- Compliance with the Personal Information Protection Act and its regulations and guidelines in Japan
- Handling registration information by following the ʺPersonnel Personal Information Management Regulationʺ
- Operation of DNSSEC on the basis of .ntt DPS
These commitments can be ensured by deploying security measures in accordance with the principles of the NTT information security related documents.
30.5. Reference Security Standards
In the security point of view, NTT refers to and shall comply with the following RFC and shall comply.
- RFC2870
ʺRoot Name Server Operational Requirements RFC 2870,ʺ IETF 〈http:⁄⁄www.ietf.org⁄rfc⁄rfc2870.txt〉

In addition, NTT refers to the following standards and shall implement their basic concepts of them, which are considered necessary to operate registry services.
- ISO⁄IEC 27001:2005,ISO⁄IEC 27002:2005,ISO⁄IEC 27005:2011
ʺInternational Organization for Standardization,ʺ International Organization for Standardization
〈http:⁄⁄www.iso.org⁄iso⁄home.htm〉

Hiroki Watanabe	Director and Executive Vice President
Hiromichi Shinohara	Director and Senior Vice President
Hiroo Unoura	Representative Director and Senior Executive Vice President
Kaoru Kanazawa	Representative Director and Senior Executive Vice President
Norio Wada	Director and Chairman of Board of Directors
Noritaka Uji	Representative Director and Senior Executive Vice President
Satoshi Miura	Representative Director and President, Chief Executive Officer
Takashi Imai	Director, Senior Adviser
Tetsuya Shoji	Director and Senior Vice President
Toshio Kobayashi	Director and Senior Vice President
Yasuyoshi Katayama	Director and Executive Vice President
Yotaro Kobayashi	Director

Hiroki Watanabe	Director and Executive Vice President
Hiromichi Shinohara	Director and Senior Vice President
Hiroo Unoura	Representative Director and Senior Executive Vice President
Kaoru Kanazawa	Representative Director and Senior Executive Vice President
Norio Wada	Director and Chairman of Board of Directors
Noritaka Uji	Representative Director and Senior Executive Vice President
Satoshi Miura	Representative Director and President, Chief Executive Officer
Tetsuya Shoji	Director and Senior Vice President
Toshio Kobayashi	Director and Senior Vice President
Yasuyoshi Katayama	Director and Executive Vice President

New gTLD Application Submitted to ICANN by: NIPPON TELEGRAPH AND TELEPHONE CORPORATION

String: ntt

Originally Posted: 13 June 2012

Application ID: 1-920-75151

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.