ICANN New gTLD Application
New gTLD Application Submitted to ICANN by: SAKURA Internet Inc.
String: sakura
Originally Posted: 13 June 2012
Application ID: 1-1163-37277
Applicant Information
1. Full legal name
2. Address of the principal place of business
Sakaisuji Hommachi Bldg. 9F
1-8-14 Minami-hommachi
Chuo-ku Osaka 541-0054
JP
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.
Attachments are not displayed on this form.
9(a). If applying company is publicly traded, provide the exchange and symbol.
Tokyo_Stock_Exchange;37780
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
Kunihiro Tanaka | President |
Masaaki Tateno | Executive Vice President |
Masataka Kawada | Director |
Munehisa Murakami | Director |
Shinichi Kawaratani | Non-executive director⁄NISSHO ELECTRONICS CORPORATION President and CEO |
11(b). Name(s) and position(s) of all officers and partners
Kunihiro Tanaka | President |
Masaaki Tateno | Executive Vice President |
Masataka Kawada | Director |
Munehisa Murakami | Director |
Takashi Ohno | Executive Officer⁄General Affairs Department Manager |
Takayuki Takahashi | Executive Officer⁄Operations Department Deputy General Manager |
Toru Sawamura | Executive Officer⁄Operations Department Manager |
11(c). Name(s) and position(s) of all shareholders holding at least 15% of shares
Sojitz Corportation | Not Applicable |
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
Katsuyuki Ikeda | Not Applicable |
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.
Attachments are not displayed on this form.
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.
The Registry Operator of SAKURA Internet Inc. (SAKURA Internet), is currently providing the existing TLD Registry services, including the registration of the Japanese domain name for the second level. Similar to those TLDs, as per the specification for the most safe and secure IDN operation, SAKURA Internet will restrict the applicable strings (qualify only within ACSII and Japanese characters) and normalize double-byte numerals and characters to a one-byte letter for .sakura in order to address the Japanese-specific issues. Moreover, our .sakura operations 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.
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.1. DEFINITION
For the purpose of this answer, we have defined the following in the alphabetical order:
Critical Registry Functions:
Functions that are critical to the operation of a gTLD registry:
1) Domain Name System (DNS) Resolution
2) Domain Name System Security Extensions (DNSSEC)
3) Shared Registration System (SRS) by means of the Extensible Provisioning Protocol (EPP)
4) Registration Data Publication Service by means of the WHOIS protocol
5) Registry Data Escrow
Domain Name Users:
The users of ʺ.sakura:ʺ SAKURA Internet will be the users of the gTLD.
SAKURA:
Japanese Cherry Blossoms
SAKURA Internet:
SAKURA Internet Inc. (Tokyo Stock Exchange MOTHERS:3778)
.sakura Registrant:
The registrant of ʺ.sakura:ʺ SAKURA Internet Inc. is the sole registrant of the gTLD.
.sakura Registrar:
An ICANN accredited Registrar for .sakura:SAKURA Internet will designate the registrar.
.sakura Registry Operator:
The registry operator which will operate the front and back-end registry services and necessary operations to support those services:SAKURA Internet intends to outsource the registry operation to a particular third party.
SLD (s) :
The Second Level Domain (s)
18.2. OUR MISSION
SAKURA Internet Inc. (ʺSAKURA Internetʺ) was established on August 17, 1999, and in just 6 years of rapid growth, we became a public company on October 12, 2005, listed under Tokyo Stock Exchange MOTHERS (Market Of The High-growth and EmeRging Stocks) :Code 3778. Since the IPO, our business has maintained a steady performance and growth by carrying out our services with a company motif, ʺSAKURA,ʺ which has attracted widespread popularity, and we have become one of Japanʹs leading IT companies. While we have been considered as a blue-chip company, securing investorʹs confidence for a long period of time, SAKURA Internet has been selected as one of the 15 component stocks of ʺTokyo Stock Exchange Mothers Core Index.ʺ
SAKURA Internet is a datacenter services provider, and our core businesses are comprised of FIVE service operations: (1) the Colocation services; (2) the Shared Hosting services; (3) the Dedicated Hosting services; (4) the Virtual Private Server (VPS) services; and our most recent business development (5) IaaS (Infrastructure as a Service) Cloud Computing services.
We have launched our internet hosting services in December of 1996, prior to the incorporation, and we have been growing the number of users successfully since then.
As of March 2012, we are one of Japanʹs top-class independent data center services providers, and proud of the number of zones delegated by sakura.ne.jp in use that has grown up to approximately 500,000.
The proposed concept (goals) of the ʺ.sakura Initiativesʺ encompass several ideas: (A) protecting the momentum of our business growth and 16 years worth of our penetration with the ʺSAKURAʺ Internet brand, by applying ICANN for ʺ.sakura;ʺ (B) leveraging ʺ.sakuraʺ effectively to achieve advanced user-friendliness and to gain the loyalty of our customers for the purposes of consumer trust and choice; (C) taking advantages of a safer and more secure domain name environment by providing ʺ.sakuraʺ for the purposes of creating new projects and conducting various research and studies; and (D) implementing an environment where we plan =〉 develop =〉 commercialize new features to establish an optimized and most advanced ʺservice value chain,ʺ by adopting ʺ.sakuraʺ for the purpose of promoting robust competition.
ʺ.sakuraʺ is a significant opportunity for SAKURA Internet, which is currently in practice to operate and manage all the data center services on a one integrated platform. For instance, by consolidating the SAKURA Internet domain name environments, we will attain the opportunity to directly contribute to improve service levels, user experiences and brand awareness. Furthermore, since SAKURA Internet has been conventionally user oriented in practicing research and preventive management for the countermeasures against abusive uses and fraudulent activities, by implementing the new gTLD we will be able to enhance our capabilities to research and plan for a safer and more secure environment for the use of internet. Consequently, along with the price reduction achieved by our economies of scale, our capabilities will lead to a healthier and robust competitive services market.
We feel certain that this process of enhancement will contribute to our innovative future goal of ʺexporting the Japanese data center services in overseas,ʺ and to the further penetration of and fulfilling the needs for the use of domain names.
18.3. OUR PREMISE
(1) We intend to utilize .sakura effectively for improving the vital use, promoting, expanding and growing the new gTLD as well as our existing TLDs.
(2) SAKURA Internet will be the sole Registrant of the proposed .sakura, and we will primarily control the use of the SLDs by our own registration policies and through a process of qualification, restricting the use within ourselves. Therefore, as an assumption, we expect no multiple domain name applications for the same name space. Example of the SLDs:rentalservername.sakura, r&dprojectname.sakura
(3) As we have the liberty of selecting a Registrar for .sakura at our discretion from the existing ICANN Accredited Registrars, we plan to identify and appoint a Registrar of our choice, and outsource our entire Registry operations for the proposed .sakura Registry Services are further explained in the answer for #23 (Registry Services).
(4) SAKURA Internet will offer initial domain name registration for a period of 1 to 10 years, complying with the Registry Agreement. We do not intend to charge for the .sakura registrations. However, should we decide to charge fees for the registrations then we will notify the Registrar in advance, as per the Registry Agreement.
(5) Our measures to protect the privacy and confidential information of the .sakura users are explained in the answers for #30 (Security).
(6) As per the cost benefits of .sakura, we anticipate the most impact on our core business domain⁄market. We will take full and direct advantage in maintaining our branded business momentum. Meanwhile, by using .sakura proactively, we will encourage the domain name markets to expand the new gTLD and the existing TLDs. Consequently, we anticipate the impacts and influences in ʺcreating future valuesʺ by improving the vital use and expanding the scale of the domain name usage.
(7) In terms of the benefits offered to the customer market, .sakura will promote customer trust and choice (for both business and consumer) by simplified domain names and easier internet search and access, and by exclusive and authenticated access to the correct and desired information (by more direct keyword ʺgTLDstringʺ search). For specific descriptions of the purposes and benefits, please see #18.7 (OUR OBJECTIVES & PURPOSES).
(8) As described in #18.9 (OUR EFFORTS ON .sakura EXPANSION), we believe our proposed marketing and public relations activities, as well as our communications outreach, are efficient and effective measures to achieve our projected benefits.
(9) SAKURA Internet projects the number of .sakura SLD registrations, based on the existing services offered, to be around 10 during the initial year, 20 during the second year, and 100 in the third year. Even with a maximum estimation, the numbers may increase up to no more than 1000 during the planned three years.
18(b). How do you expect that your proposed gTLD will benefit registrants, Internet users, and others?
18.4. GENERAL BACKGROUND
SAKURA Internet Inc. has launched its internet hosting services in December of 1996, and as of March 2012, we are proud that we are a service provider with over 500,000 (sakura.ne.jp) zones, and with over 300,000 internet hosting services in use (active memberships). With our economies of scale and many accomplishments, SAKURA Internet has become one of Japanʹs top-class service providers.
The market trend in demand for the data center services in Japan is typically represented by keywords or phrases such as ʺrelieving the initial cost impact,ʺ ʺshifting from ownership to usership-oriented,ʺ ʺmoving from inner city to outer city,ʺ in line with such themes as ʺIT cost reduction,ʺ ʺoff-balance sheet IT assets,ʺ ʺBCP⁄DR solutions.ʺ On the other hand, the market trend in supply may be described by the impact of the Great East Japan Earthquake, to begin with, as well as the increasing business entries into the Japan market by foreign corporations and emerging start-up companies. Consequently, those phenomena have raised major challenges such as ʺelectric power supply issuesʺ and ʺintensified pricing competition (commoditization) .ʺ
SAKURA Internet has recognized those market signals or trends in early stages, and has been taking advantages of its existing services and competitive edges in a comprehensive manner. For instance, we have been engaged in enhancing competitiveness of our data centers (i.e. to implement full line of services, to increase efficiency and lower prices by the newly established PUE1.11 data center facilities, and to launch new services utilizing those advantageous idiosyncrasies). We have been further exploiting the business enterprise market (i.e. to provide services and solutions tailored for the government agencies and offices, through collaborations with business partners). Additionally, we have been engaged in establishing a single and total IT services platform (i.e. to provide a platform⁄infrastructure which allows us to manage and operate data center services in an integrated fashion).
In enhancing our efforts for the above business strategies and operational idiosyncrasies, SAKURA Internet has decided to apply and propose ICANN for ʺ.sakuraʺ because we believe that we and ʺ.sakuraʺ will be able to contribute to the innovations in the use of domain names and to the future expansion of the TLD market.
18.5. ʺ.sakuraʺ INITIATIVES
We have developed the ʺ.sakuraʺ INITIATIVES in applying ICANN for the new gTLD.
The ʺ.sakuraʺ INITIATIVES aim at achieving following FOUR goals:
A) Protect the brand by acquiring ʺ.sakuraʺ
B) Leverage the domain names by utilizing ʺ.sakuraʺ
C) Research the domain environment by studying ʺ.sakuraʺ
D) Envision the future by implementing ʺ.sakuraʺ
The above four goals are in line with our current SAKURA Internet management strategies and our business development, and outlined as follows:
A) Protect the brand by acquiring ʺ.sakura:ʺ
SAKURA Internet is one of the leading data center services providers in Japan, and our initiatives for the new gTLD is a significant opportunity for SAKURA Internet, because our goal essentially is to expand the existing scale of the domain name users in the internet market. However, since the same opportunity could become a threat to us, we have positioned our initial objective to acquire ʺ.sakuraʺ as a precautious defense measure to protect and maintain our well-penetrated ʺSAKURAʺ Internet businesses and its momentum. In acquiring ʺ.sakura,ʺ we propose the following three additional objectives (B, C & D).
B) Leverage the domain names by utilizing ʺ.sakura:ʺ
As SAKURA Internet expects to become the accredited Registry of .sakura, we intend to consolidate our domain names into ʺ.sakuraʺ for the purpose of our business activities. Furthermore, we consider the possibility of transitioning the domains of servers used for our existing services, into the ʺ.sakuraʺ domain. By leveraging ʺ.sakuraʺ and making full use of the new gTLD features, we will be able to offer higher usability and ease of access (short and memorable strings) for the customer market to actually experience.
C) Research the domain environment by studying ʺ.sakura:ʺ
The various data center services that SAKURA Internet provides are offered to a wide range of users, including general consumers, engineers, businesses and institutions. For the last 16 years, the services have been offered and trusted through the same brand, and we take pride in our services that are highly competitive, secure and economical. By implementing an authenticated domain name space, we will not only be able to protect the registered trademarks and credibility, but it will also allow us to count on the effects to achieve safer and more secure services. For instance, the knowledge and know-how acquired from the implementation will help our corresponding team for the abusive uses (ʺThe ABUSE Response Teamʺ) and our dedicated research team (ʺThe Research Centerʺ) for their basis of research and studies. Additionally, we believe that the results of our research and studies, by extension, will contribute to the various research related activities, one of which aims for a robust and safer internet, for example by reinforcing the information sharing and advocating new technologies and techniques with the security related industry organizations.
D) Envision the future by implementing ʺ.sakura:ʺ
The SAKURA Internet business strategies for the future include our vision to create data center and cloud computing services that are competitive ʺnot only in the Japanese market, but are also competitive enough to export in the overseas markets.ʺ Evidently, we have newly built a PUE1.11 data center, domestically, as a part of our efforts in striving to improve efficiency and to lower the operational costs, focused on the emerging cloud computing services market. We position ʺ.sakuraʺ as a crucial part of our vision, and along with other goals ʺto establish a single and total IT services platformʺ and ʺto structure a framework for the planning and development to produce innovative services,ʺ we plan to take full advantages of our research capabilities (mentioned in C) and optimize the use of the environment and features of ʺ.sakuraʺ to design and create new services.
Our ʺ.sakura INITIAIVESʺ are derived from the following key questions: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) ? Each answer is explained in detail in the subsequent chapters.
18.6. OUR CHALLENGES
1. SAKURA Internet is one of Japanʹs top-class independent data center services providers, and with a company motif, ʺSAKURA,ʺ our customers have been using sakura.ne.jp and sakura.ad.jp over the past 16 years. The opportunity to apply for the new gTLD this time around is critical for the well-developed, -established, -maintained and -penetrated ʺSAKURAʺ brand, for the purposes of our future business growth and momentum, but the same opportunity could become a threat to us at the same.
2. The Web analytic tool, ʺAlexa,ʺ and the search engine, ʺGoogle,ʺ both show the results that the keyword search by ʺsakuraʺ will rank ʺSAKURA Internetʺ in the top listings. The results prove that the logic of ʺsakuraʺ = ʺSAKURA Internetʺ to be true, and that the string is well recognized today from the usersʹ perspective, especially in the internet world for both domestic and overseas. . Based upon the results and the characteristics of the search engines, we are convinced that the solid ʺSAKURA Internetʺ brand has penetrated the Japanese society for a long period of time. That is to say, we are urged to protect our existing corporate brand as a responsibility towards consumers and society.
3. SAKURA Internet has over 300,000 customers⁄members, and is currently providing many means through which they communicate and access information. We are urged to increase the customer values and consolidate the domain names for the purposes of surviving the competition, differentiating our services in the future, gaining recognition, sustaining and improving the customer loyalty, even more.
4. For the purposes of managing the operations of such size described in 3, the needs of methods for cost reductions and management efficiency have increased as business grows, and new solutions are required for maintaining services and domain name management.
5. The quality of the SAKURA Internet services has been proven to be a safer and secure choice, by our user scale and groups such as consumers, businesses and government offices. Our motto is to evolve from a user perspective by making continuous efforts to maintain the robust and competitive environment, and our social mission is to always research to achieve safer, more secure and competitively priced services. As Japanʹs leading data center and domain name services provider, we are expected by the industry to sustain our motto and mission.
6. SAKURA Internet, as an independent industry leader, is certain that implementing ʺ.sakuraʺ ahead of other players is important for the industry. As we apply for the new gTLD, we feel that it is our mission to accumulate the knowledge and know-how pertaining to the features, intended purposes and safety of gTLD, and to share the information with the various communities that aspire for the healthy and robust internet.
7. SAKURA Internet has kept growing for the last 16 years, and as Japanʹs major data center services provider we have been offering services that are high in quality, easy to use and competitive (technology and price). In other words, we are expected to sustain and continue to be in the industry leading role.
8. SAKURA Internet has a future vision which is the basis of its business plan and strategies. It is a dream and planned scheme ʺto create data center and cloud computing services that are competitive enough to export in the overseas markets.ʺ
18.7. OUR OBJECTIVES & PURPOSES
A) Protect the brand by acquiring ʺ.sakura:ʺ
〈 Domain Name Users 〉
SAKURA Internet (Management)
〈 Mission⁄Purpose 〉
SAKURA Internet is one of the leading data center services providers in Japan, and has been very successful under the same ʺSAKURAʺ brand for over 16 years. Our mission to implement the new gTLD is a significant opportunity for SAKURA Internet, because our goal essentially is to expand the existing scale of the domain name users in the internet market. However, since the same opportunity could become a threat to us, we have decided to apply ICANN for ʺ.sakuraʺ for the purpose of protecting the brand.
〈 Objectives & Advantages 〉
We propose to acquire ʺ.sakuraʺ as a precautious defense measure to protect and maintain our well-penetrated ʺSAKURAʺ Internet business domain and its successful momentum.
B) Leverage the domain names by utiizing ʺ.sakura:ʺ
〈 Domain Name Users 〉
SAKURA Internet (Sales Department, Public Relations and Advertising Department, General Affairs Department and Accounting & Finance Department)
〈 Mission⁄Purpose 〉
SAKURA Internet intends to consolidate its domain names into ʺ.sakuraʺ for the purpose of its business activities. Furthermore, we consider the possibility of transitioning the domains of servers used for our existing services, into ʺ.sakura.ʺ Our mission to leverage ʺ.sakuraʺ by offering higher usability and ease of access (short and memorable strings) for the existing and potential customer markets, and to realize an environment, where the users become more conscious of and take more into account the potential purposes of the exiting TLDs, will consequently differentiate us from the competitions and improve our corporate brand awareness and customer loyalty.
〈 Objectives & Advantages 〉
We believe that by consolidating our domain names into one, we could enjoy significant benefits and advantages, in terms of internet marketing (SEO and SEM). To the approximately 300,000 members of the SAKURA Internet services, who have been the advocates of our preserved solid brand for over 16 years, and to the other potential customers, we will leverage ʺ.sakura,ʺ a sophisticated gTLD and consistent with the TLD trend, to offer shorter and simplified URLs, which are more memorable and easier to identify, easier to access, and allow to reach the destination faster, because keyword search by a domain name string will conceivably achieve a higher search engine ranking. In other words, we are convinced that ʺ.sakuraʺ will improve the user access and usability dramatically, and create customer values & benefits.
Examples of the shortened URL:www.sakura.ad.jp⁄press⁄ will be www.press.sakura⁄
As a result of achieving the objectives and advantages mentioned above, we feel certain that our corporate brand awareness and customer loyalty will improve.
C) Research the domain environment by studying ʺ.sakura:ʺ
〈 Domain Name Users 〉
SAKURA Internet (The ABUSE Response Team and New Business Development Department)
〈 Mission⁄Purpose 〉
The various services that SAKURA Internet provides are offered to a wide range of users, including general consumers, engineers, businesses and institutions, because they have been trusted as well as highly competitive, secure and economical. One of the reasons why we have been so successful is that we have complete control over our own domain environment. For example, we have recognized achievements in advocating to IETF and in contributing to the open source communities. Our mission⁄purpose is to take full advantages of the features of the new gTLD and to realize a safer and more secure domain environment (i.e. preventing phishing attacks) for the internet community.
〈 Objectives & Advantages 〉
In the past, SAKURA Internet has been actively involved in preventive management. We have ʺThe Research Centerʺ and ʺThe ABUSE Response Teamʺ for the research and studies pertaining countermeasures against abusive uses and fraudulent activities on the internet. One of our objectives is to implement an authenticated domain name space, ʺ.sakura,ʺ which will allow us to protect the registered trademarks and credibility, and to have better and tighter control by the knowledge and know-how acquired from the implementation, helping The Center and The Team to research and prevent the abusive uses. As a result, ʺ.sakuraʺ will enable us to create new operation forms and structures (countermeasures), to achieve the most suitable operations for the domain environment, and the data center services provided over a most reliable environment. We, as a leader in the industry, will develop our proprietary research and studies to provide a safer and more secure environment for the use of internet, and will continue to contribute proactively to the internet society.
D) Envision the future by implementing ʺ.sakura:ʺ
〈 Domain Name Users 〉
SAKURA Internet (The Research Center, Marketing Department, Development Department and New Business Development Department)
〈 Mission⁄Purpose 〉
In the SAKURA Internet business strategies (goals) for the future, our vision is to create data center and cloud computing services that are competitive ʺnot only in the Japanese market, but also in the overseas markets.ʺ Evidently, our PUE1.11 data center, as a part of our efforts in striving to improve efficiency and lower the prices, focuses on the emerging cloud computing services market. As we position ʺ.sakuraʺ as a crucial part of our vision, our mission⁄purpose is to take full advantages of ʺ.sakuraʺ to design, create and deliver new lines of services, exploiting our underlying research capabilities.
〈 Objectives & Advantages 〉
SAKURA Internet has the substantial advantage in providing all the entire value chain, required for all the data center services, in house. Our objective is to implement the process, in which to create new services (namely ʺresearch and planning =〉 development =〉 commercializationʺ), through the ʺ.sakuraʺ environment, in order to enhance ʺthe single and total IT services platformʺ and ʺthe structured framework for the planning and development to produce innovative services.ʺ Meanwhile, we are certain that our objectives will lead us in the future to achieve the ʺdata center and cloud computing services that could compete in the overseas markets.ʺ
18.8. OUR REGISTRY SERVICES
Following are the EIGHT primary registry services (including critical functions) that SAKURA Internet plans to provide for .sakura. Please see #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, SAKURA Internet will implement the above eight main services. Advanced features such as authentications and qualifications for the SLD users will be required for the third level domain name registrations and the SLD operations, and will be supported individually and accordingly.
18.9. OUR EFFORTS ON .sakura EXPANSION
SAKURA Internet plans for the following efforts and outreach activities in promoting the new gTLD and .sakura:
A) Protect the brand by acquiring ʺ.sakura:ʺ
- Apply ICANN for ʺ.sakuraʺ
- Register ʺ.sakuraʺ
B) Leverage the domain names by utilizing ʺ.sakura:ʺ
- Provide ʺ.sakuraʺ SLDs for our Sales Department, Public Relations and Advertising Department, General Affairs Department and Accounting & Finance Department
- Consolidate and transition the existing domain names and servers into ʺ.sakuraʺ
- Develop a ʺ.sakuraʺ dedicated Web site
- Produce and generate new Web contents and optimize navigation scheme for SEM and SEO
- Utilize ʺ.sakuraʺ as a PR tool for IR and corporate information distribution
- Utilize ʺ.sakuraʺ as a new internet marketing tool for sales and marketing communications
C) Research the domain environment by studying ʺ.sakura:ʺ
- Provide ʺ.sakuraʺ SLDs for our ABUSE Response Team and New Business Development Department
- Authenticate and administer the SLD users (identify, activate, deactivate)
- Develop a process and administration rules to evaluate and qualify SLD objectives and users
- Develop domain name operational rules & guidelines for the designated users
- Provide user support (how to use and to administer)
- Promote and educate about ʺ.sakuraʺ (i.e. as a case study) to business partners and various associated industries
- Utilize ʺ.sakuraʺ as the ʺsafer and more secureʺ PR tool
D) Envision the future by implementing ʺ.sakura:ʺ
- Provide ʺ.sakuraʺ SLDs for our Research Center, Marketing Department, Development Department, New Business Development Department
- Utilize ʺ.sakuraʺ for the service production and release cycle
- Authenticate and administer the ʺ.sakuraʺ SLD users
- Develop a process and administration rules to evaluate and qualify SLD objectives and users
- Develop domain name operational rules for the designated users
- Provide user support
- Promote and educate about ʺ.sakuraʺ (i.e. as a promotional tool) to the business partners
Other Outreach Activities
* Utilize ʺ.sakuraʺ as a communications tool for our stakeholders:authenticated ʺhighly securedʺ Investors Relations information channel
18(c). What operating rules will you adopt to eliminate or minimize social costs?
18.10. OUR PREMISE
(1) We intend to utilize .sakura effectively for improving the vital use as well as promoting, expanding and growing the new gTLD as well as our existing TLDs.
(2) SAKURA Internet will be the sole Registrant of the proposed .sakura, and we will primarily control the use of the SLDs by our own registration policies and through a process of qualification, restricting the use within ourselves. Therefore, as an assumption, we expect no multiple domain name applications for the same name space. Example of the SLDs:rentalservername.sakura, r&dprojectname.sakura
(3) As we have the liberty of selecting a Registrar for .sakura at our discretion from the existing ICANN Accredited Registrars, we plan to identify and appoint a Registrar of our choice, and outsource our entire Registry operations for the proposed .sakura. Registry Services are further explained in the answer for #23 (Registry Services).
(4) SAKURA Internet will offer initial domain name registration for a period of 1 to 10 years, complying with the Registry Agreement. We do not intend to charge for the .sakura registrations; however, should we decide to charge fees for the registrations, we will notify the Registrar in advance, as per the Registry Agreement.
(5) Our measures to protect the privacy and confidential information of the .sakura users are explained in the answers for #30 (Security).
(6) As per the cost benefits of .sakura, we anticipate the most impact on our core business domain⁄market. We will take full and direct advantage in maintaining our branded business momentum. Meanwhile, by using .sakura proactively, we will encourage the domain name markets to expand the new gTLD and the existing TLDs. Consequently, we anticipate the impacts and influences in ʺcreating future valuesʺ by improving the vital use and expanding the scale of the domain name usage.
(7) In terms of the benefits offered to the customer market, .sakura will promote customer trust and choice (for both business and consumer) by simplified domain names and easier internet search and access, and by exclusive and authenticated access to the correct and desired information (by more direct keyword ʺgTLDstringʺ search). For specific descriptions of the purposes and benefits, please see #18.7 (OUR OBJECTIVES & PURPOSES)
(8) As described in #18.9 (OUR EFFORTS ON .sakura EXPANSION), we believe our proposed marketing and public relations activities, as well as our communications outreach, are efficient and effective measures to achieve our projected benefits.
(9) SAKURA Internet projects the number of .sakura SLD registrations, based on the existing services offered, to be around 10 during the initial year, 20 during the second year, and 100 in the third year. Even with a maximum estimation, the numbers may increase up to no more than 1000 during the planned three years.
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).
Attachments are not displayed on this form.
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.
22.1. Reservation of Country and Territory Names
SAKURA Internet is committed to reserve the country and territory names contained in the internationally recognized lists that described in the Article 5 of Specification 5 attached to the ʺNew gTLD Applicant Guidebook,ʺ in terms of the second level domain and of all other levels within ʺ.sakura.ʺ
The following is the lists mentioned above:
1. the short form (in English) of all country and territory names contained in the ISO 3166- 1 list, as updated from time to time, including the European Union, which is exceptionally reserved in the ISO 3166-1 list, and its scope extended in August 1999 to any application representing the name European Union 〈http:⁄⁄www.iso.org⁄iso⁄support⁄country_codes⁄iso_3166_code_lists⁄iso-3166- 1_decoding_table.htm#EU〉;
2. the United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardization of Geographical Names, Part III Names of Countries of the World; and
3. the list of United Nations member states in 6 official United Nations languages prepared by the Working Group on Country Names of the United Nations Conference on the Standardization of Geographical Names.
22.2. Release of Names
As set forth in the answer for #18, SAKURA Internet intends to provide the second level domain of .sakura for its own, and SAKURA Internet will be the sole registrant for them. Therefore, SAKURA Internet does not currently envision any need to release geographic names listed above to the governments, public authorities, or IGOs.
Should we find that thereʹs a need to release those domain names in the future, then .sakura will develop required policies and⁄or recommendations to release those domain names, and submit new requests to the Registry Service Evaluation Process (RSEP).
22.3. Dispute Resolution
Based upon our proposed purposes of .sakura set forth in the answer for #18, SAKURA Internet does not envision any potential disputes against us by the government agencies or any other public authorities in connection with the registration and the geographic names used within the .sakura domain.
However, .sakura will make efforts to work with any government agencies, public authorities or IGOs that may have concerns regarding our second level domain names, in terms of national or geographic significance.
22.4. Creation and Updating the Policies
Should there be any future need for creating or updating the policies regarding our domain names under this subject (country and⁄or geographic related), .sakura will develop new policies and⁄or recommendations regarding the release of domain names.
Registry Services
23. Provide name and full description of all the Registry Services to be provided.
23.1. Definition
For the purpose of this answer, we have defined the following in the alphabetical order:
-Critical Registry Functions:
Functions that are critical to the operation of a gTLD registry:
1) Domain Name System (DNS) Resolution
2) Domain Name System Security Extensions (DNSSEC)
3) Shared Registration System (SRS) by means of the Extensible Provisioning Protocol (EPP)
4) Registration Data Publication Service by means of the WHOIS protocol
5) Registry Data Escrow
Domain Name Users:
The users of ʺ.sakura:ʺ SAKURA Internet will be the users of the gTLD.
SAKURA:
Japanese Cherry Blossoms
SAKURA Internet:
SAKURA Internet Inc. (Tokyo Stock Exchange MOTHERS:3778)
.sakura Registrant:
The registrant of ʺ.sakura:ʺ SAKURA Internet Inc. is the sole registrant of the gTLD.
.sakura Registrar:
An ICANN accredited Registrar for .sakura:SAKURA Internet will designate the registrar.
.sakura Registry Operator:
The registry operator which will operate the front and back-end registry services and necessary operations to support those services:SAKURA Internet intends to outsource the registry operation to a particular third party.
SLD (s) :
The Second Level Domain (s)
23.2. Introduction
SAKURA Internet is one of the leading data center services providers in Japan, and our proposed concept of ʺ.sakura Initiativesʺ is a significant opportunity for SAKURA Internet. The proposed concept (goals) of the ʺ.sakura Initiativesʺ encompass several ideas: (A) protecting the momentum of our business growth and 16 years worth of our penetration with the ʺSAKURAʺ internet brand, by applying ICANN for ʺ.sakura;ʺ (B) leveraging ʺ.sakuraʺ effectively to achieve advanced user-friendliness and to gain the loyalty of our customers for the purposes of consumer trust and choice; (C) taking advantages of a safer and more secure domain name environment by providing ʺ.sakuraʺ for the purposes of creating new projects and conducting various research and studies; and (D) implementing an environment where we plan =〉 develop =〉 commercialize new features to establish an optimized and most advanced ʺservice value chain,ʺ by adopting ʺ.sakuraʺ for the purpose of promoting robust competition.
In our initial stage of this plan, SAKURA Internet will implement the eight main services, on the premise of providing registrations for .sakura SLDs.
We believe that by providing a comprehensive range of proposed registry services, SAKURA Internet will be able to support and achieve our defined objectives for .sakura.
23.3. Our Premise:Business Considerations
*We intend to utilize .sakura effectively for improving the vital use, promoting, expanding and growing the new gTLD as well as our existing TLDs.
*SAKURA Internet will be the sole Registrant of the proposed .sakura, and we will primarily control the use of the SLDs by our own registration policies and through a process of qualification, restricting the use within ourselves. Therefore, as an assumption, we expect no multiple domain name applications for the same name space. Example of the SLDs:rentalservername.sakura, r&dprojectname.sakura
*As we have the liberty of selecting a Registrar for .sakura at our discretion from the existing ICANN Accredited Registrars, we plan to identify and appoint a Registrar of our choice, and outsource our entire Registry operations for the proposed .sakura. Registry Services are further explained in the answer for #23 (Registry Services).
*SAKURA Internet will offer initial domain name registration for a period of 1 to 10 years, complying with the Registry Agreement. We do not intend to charge for the .sakura registrations; however, should we decide to charge fees for the registrations, we will notify the Registrar in advance, as per the Registry Agreement.
*Our measures to protect the privacy and confidential information of the .sakura users are explained in the answers for #30 (Security).
*As per the cost benefits of .sakura, we anticipate the most impact on our core business domain⁄market. We will take full and direct advantage in maintaining our branded business momentum. Meanwhile, by using .sakura proactively, we will encourage the domain name markets to expand the new gTLD and the existing TLDs. Consequently, we anticipate the impacts and influences in ʺcreating future valuesʺ by improving the vital use and expanding the scale of the domain name usage.
*In terms of the benefits offered to the customer market, .sakura will promote customer trust and choice (for both business and consumer) by simplified domain names and easier internet search and access, and by exclusive and authenticated access to the correct and desired information (by more direct keyword ʺgTLDstringʺ search). For specific descriptions of the purposes and benefits, please see ʺ6. OUR OBJECTIVES & PURPOSESʺ
*As described in #18.9 (OUR EFFORTS ON .sakura EXPANSION), we believe our proposed marketing and public relations activities, as well as our communications outreach, are efficient and effective measures to achieve our projected benefits.
*SAKURA Internet projects the number of .sakura SLD registrations, based on the existing services offered, to be around 10 during the initial year, 20 during the second year, and 100 in the third year. Even with a maximum estimation, the numbers may increase up to no more than 1000 during the planned three years.
23.4. Intended Services⁄Functions:Technical Considerations
As SAKURA Internet being the sole registrant, at its own discretion, we will choose a Registrar for .sakura among the ICANN accredited registrars, who should be able to manage and operate an evaluation process to qualify the potential users and objectives, and should be capable of operating the .sakura Registry.
Given the business considerations and our specific objectives along with the continued ongoing evolution of the domain name market, SAKURA Internet proposes a following comprehensive range of registry services to support .sakura, which are almost universal across most if not all the gTLDs.
1. Domain Name Registration and Renewal
2. Transfer of Registration between Registrars
3. Name Server and Zone File Administration
4. Operation of WHOIS Database
5. Registrar Support Services
6. Data Escrow
7. DNSSEC
8. Internationalized Domain Names
23.4.1. Domain Name Registration and Renewal
One of the most basic services that a Registry Operator provides is the registration and renewal of a domain name. We intend the Domain Name Registration of .sakura to be a FSFC registration registered in one year annual increments for up to a maximum of ten (10) years. SAKURA Internet will also provide the ability to renew a domain in annual increments. Details of Registration Life Cycle of .sakura are described in the answer for #27 (Registration life cycle).
This Registry Service will be provided by accessing the Shared Registry System (SRS) through a securing SSL connection using the Extensible Provisioning Protocol (EPP) that ICANN has mandated for all new gTLD operators. There are various EPP commands involved in registering⁄maintaining a domain name which are identified in more detail in the answer for #25.1 (EPP).
23.4.2. Transfer of Registration between Registrars
Since the creation of ICANN, there has been a dichotomy within the domain name marketplace between Registrars and Registries. Domain name portability, the ability of a Registrant to transfer sponsorship of a domain name at the Registry Operator from one Registrar to another Registrar, has been one of ICANNʹs initial success stories.
To safeguard a Registrantʹs ability to transfer sponsorship of a domain name between Registrars, ICANN has adopted a consensus policy (ICANN Consensus Policy) that largely regulates the domain name transfer process between a Gaining and Losing Registrar. This policy specifically sets forth the limited circumstances in which a Losing Registrar can deny a transfer request, as well as dispute providers that have been approved to administer the Transfer Dispute Resolution Policy.
Reference
Approved Providers for Transfer Dispute Resolution Policy
http:⁄⁄www.icann.org⁄en⁄dndr⁄tdrp⁄approved-providers.htm
Policy on Transfer of Registrations between Registrars (Revision Adopted November 7, 2008, Effective March 15, 2009)
http:⁄⁄www.icann.org⁄en⁄transfers⁄policy-en.htm
SAKURA Internet will adopt the use of the ʺAuth Info codesʺ coupled with the implementation of ʺICANN Consensus Policyʺ recommendations that has mitigated the number of hijacking incidents. The ʺAuth Infoʺ safeguard is largely dependent upon a Registrant being able to control access and assignment of unique ʺAuth Info codes.ʺ
SAKURA Internet will also provide the Bulk Transfer service for .sakura, which is a mandated Registry Service set forth in ICANNʹs Consensus Policy on Transfer of Registrations between Registrars (following is an excerpt from the policy) :
Registry Operator shall make the necessary one-time changes in the Registry database for no charge, for transfers involving 50,000 name registrations or fewer. If the transfer involves registrations of more than 50,000 names, then the Registry Operator shall charge the gaining Registrar a one-time flat fee of US$ 50,000.
23.4.3. Nameserver and Zone File Administration
This is the primary self-service function that the Registry provides for the consumer to use directly. If this service fails, then the TLD will essentially go dark on the Internet. SAKURA Internet will offer the Name Server and the zone file administration services with the best practice adopted by the existing gTLD Registry Operators. The technical considerations for .sakura in connection with the name server and the zone file administration are explained in the answer for #35 (DNS service compliance).
Historically, ICANN accredited registries have been required to provide bulk zone file access to third parties that requested such data at no cost, on terms set forth in all incumbent ICANN registry agreements. SAKURA Internet will provide the Bulk Zone File Access service to users. More details on Bulk Zone File Access are described in the answer for #26 (Whois).
23.4.4. Operation of Whois Database
All Registry Operators are required to provide both Web-based and port 43 interfaces to the registryʹs Whois database servers.
SAKURA Internet will provide public access to the Whois database servers as required under the Registry Agreement.
SAKURA Internet will ensure that those servers will be a part of the Registry Architecture, detailed in the answers for #24 (SRS performance) and #26 (Whois), focused on redundancy. In connection with the Web-based and port 43 interfaces, SAKURA Internet will employ reasonable safeguards to prevent the mining of Whois data through high volume queries. Please refer to the answer for #28 (Abuse prevention & mitigation) and #29 (Rights protection mechanisms) with regard to maintaining redundancy of Whois.
As described in #23.3 (Our Premise:Business Considerations), SAKURA Internet will apply its own evaluation criteria to review and evaluate the potential users and objectives, and SAKURA Internet will register only the qualified second level domain names⁄strings. Additionally, we will be able to provide the most current and accurate .sakura contact information through the Whois search, because the .sakura users will mainly be the SAKURA Internet itself.
23.4.5. Registrar Support Services
The implementation of Registrar Support Services will be limited, due to the fact that SAKURA Internet, having the liberty of selecting an ICANN accredited Registrar for .sakura at its own discretion, plans to choose a specific Registrar that is capable of managing and operating the .sakura proprietary evaluation process to qualify the potential users and objectives. However, in the event that we provide the Registrar Support Services for multiple ICANN accredited registrars sometime in the future, we will provide the following support services to the selected Registrars:
A) Registrar OT&E:
As a prerequisite for Registry Operatorʹs granting an ICANN Accredited Registrar access to the SRS, SAKURA Internet will facilitate (test and certify) the Operational Test and Evaluation (OT&E) certification process for the Registrars.
B) Registry Operatorʹs Website:
SAKURA Internet will provide access to Registry Operatorʹs Website for Registrars to download various support documentations. In order to secure the access to the Website, each Registrar will be assigned a user ID and password.
While EPP provides a polling function for some transactions, most Registrar reports are accessible through a secure web-based portal.
23.4.6. Data Escrow
This is a mandated Registry Service incorporated into the baseline Registry Agreement by ICANN to ensure the security and stability of Registry Operations for the benefit of Registrants and the broader Internet community. The technical criteria associated with the data escrow requirements are set forth in the Specification 2 of the ʺICANN draft new gTLD Registry Agreement.ʺ More details on Registry Service for .sakura are set forth in the answer for #38 (Escrow).
23.4.7. DNSSEC
This is a mandated Registry Service in accordance with Specification 6 of the ʺICANN draft new gTLD Registry Agreement.ʺ SAKURA Internet adopts DNSSEC into .sakura. The technical implementation of DNSSEC is explained in the answered for #43 (DNSSEC).
23.4.8. Internationalized Domain Names
SAKURA Internet will support IDN in .sakura in a fully standards-compliant fashion at the time of transition. SAKURA Internet has implemented IDN in Japanese, and in line with ICANN guidelines and IETF standards.
The Japanese language will be used for .sakura and the IDN tables, presented in the answer for #44 (IDNs), and will be provided as required for the second level domain. SAKURA Internet has been offering the IDN for .jp for more than 10 years, and there are approximately 120,000 IDNs currently registered in .jp Detailed considerations of IDN are described in the answer for #44 (IDNs).
23.5. Security ⁄ Stability
As we strive for achieving our objectives⁄goals for .sakura, SAKURA Internet will apply the most appropriate information security measures and provide safe registry services to the users.
SAKURA Internet acknowledges that protecting the registrant information and ensuring 100% availability of DNS services are critical. Hence, we will implement extensive security measures to protect information confidentiality, safety and high availability in practice for .sakura registry services.
Below, we have listed the major categories of our planned security measures for .sakura registry services:
* Network Control and Access Control
* Secure network communications and data encryption
* Digital data signature and DNSSEC Resolution
* Software, hardware and network architectures, as well as multi-site redundancy
For more detailed information about the .sakura security, please see the answer for #30 (Security).
In the following sections, we will describe the security and stability considerations for the provided services and functions.
23.5.1. Domain Name Registration and Renewal
As SAKURA Internet will be the sole registrant and the user of .sakura, concerns on unauthorized access to .sakura will be limited by security protocols in place.
As per the users of .sakura second level domain, we will apply our proprietary evaluation criteria to review and evaluate the potential users and objectives, and SAKURA Internet will register only the qualified second level domain names⁄strings. Therefore, we believe that we will be able to avoid unauthorized access and abusive uses.
We are confident that the operational system that we will outsource, in connection with domain names registrations and renewals will handle the various business use cases. SAKURA Internet will select an experienced Registry Operator for the entire registry operations, and it is one of our prerequisites to be selected as our Registry Operator to have an SLA which will address all the requirements and considerations pertaining potential security and stability issues.
SAKURA Internet will not rely on a third party validation agent. Therefore, the concerns relative to ensuring the security of electronic communications will be minimized and not subject to interception and or manipulation.
Although there should be no security⁄stability concerns beyond those referenced in the ʺStandard Domain Name Registration Service,ʺ SAKURA Internet acknowledges that it may have to exercise some enhanced security protocols when transferring EPP Auth Codes to successful Registrants to allow them to transfer the domain name to a registrar of their choice.
SAKURA Internet will work to determine the best technical implementation to address the business needs of the .sakura registry. In addition, SAKURA Internet will ensure that the security and stability weaknesses identified in the SSAC reports are proactively addressed for the benefit of SAKURA Internet and .sakura users.
23.5.2. Transfers of Registration between Registrars
The Auth Info safeguard is largely dependent upon a Registrant being able to control access and assignment of the unique Auth Info codes.
SAKURA Internet acknowledges the importance of the specific security provisions regarding Auth Info Codes described in the ʺICANN Consensus Policy on Transfer of Registrations between Registrarsʺ (following is an excerpt) :
Registrars must provide the Registered Name Holder with the unique ʺAuthInfoʺ code within five (5) calendar days of the Registered Name Holderʹs initial request if the Registrar does not provide facilities for the Registered Name Holder to generate and manage their own unique ʺAuthInfoʺ code.
Registrars may not employ any mechanism for complying with a Registered Name Holderʹs request to obtain the applicable ʺAuthInfo Codeʺ that is more restrictive than the mechanisms used for changing any aspect of the Registered Name Holderʹs contact or name server information.
The Registrar of Record must not refuse to release an ʺAuthInfo Codeʺ to the Registered Name Holder solely because there is a dispute between the Registered Name Holder and the Registrar over payment.
Registrar-generated ʺAuthInfoʺ codes must be unique on a per-domain basis.
We understand that the reason for these safeguards is for the Registrars during the initial implementation of EPP to assign a common Auth Code for all domain name registrations, and therefore effectively defeating any security aspects.
23.5.3. Name Server and Zone File Administration
Our Backend Registry Operations will constantly upgrade our DNS resolution services, preventing continued sophisticated attacks. Any RFP will focus on both active and passive efforts that Backend Registry Operations employ to defend against such attacks.
We ensure 100% availability of the DNS Resolution service. This we allow us to diversify our entire solutions for our software, hardware, network architectures, and multiple server hosting sites. Therefore, even if we are under DoS and DDoS attacks, we wonʹt lose all our capabilities of DNS servers in service over 18 sites.
Also, maintaining the zone data integrity in the DNS servers is critically important. Thus, we have a process in place to check data before generating the zone data, and moreover, we protect the network communications by encryptions and digital signatures until the data arrives safely to the DNS servers.
23.5.4. Operation of WHOIS Database
The Whois databases will be divided into the primary site and the secondary sites, constantly synchronizing data so that both servers will always be ready for service. The primary site will normally provide the service, and the secondary site will always be in stand-by mode. The servers within each site will be redundant and therefore achieving high availability.
The Whois database will be designed as Read only, unless it receives most current updated information from the SRS database, and it will keep the integrity to protect from unauthorized access and tampering attempts from the external networks.
Additionally, we will secure data confidentiality by controlling and preventing internet users from acquiring high volume search results through automatic⁄systematic queries.
23.5.5. Registrar Support Services
SAKURA Internetʹs designated Registry Operatorʹs know-how and familiarity of the established Backend Registry Operation will minimize the potential for unknown security and stability issues.
The purpose of restricting Registrars access to the ʺsand boxʺ until they pass OT&E is to minimize the potential for unintended actions by a registrar that would negatively impact Registry operations.
23.5.6. Data Escrow
In order to minimize the impact to the .sakura Registry services, we will provide the Registry Data Escrow service in the case of business failures. It is a key component of ICANN providing a safety net to ensure registry continuity.
SAKURA Internet will select an appropriate Escrow Agent following the predefined set of standards. In the event that we put the data in escrow at regular intervals, we will encrypt the data and apply digital signatures to maintain confidentiality and security.
23.5.7. DNSSEC
In order for the Registry operator to validate the accuracy of the DNS response, SAKURA Internet will provide the DNSSEC service. Providing DNSSEC is a long term investment that will increase the level of security, stability and trust within the .sakura.
Also, SAKURA Internet has published the .sakura DNSSEC Practice Statement (.sakura DPS) in order to declare that operates DNSSEC of .sakura registry services properly:Please refer to the answer of #43 (DNSSEC) for more detailed information.
The following RFCs will be used in .sakura:
* RFC4033:DNS Security Introduction and Requirements
* RFC4034:Resource Records for the DNS Security Extensions
* RFC4035:Protocol Modifications for the DNS Security Extensions
* RFC4509:Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
* RFC4641:DNSSEC Operational Practices
* RFC5155:DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
* RFC5702:Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC
* RFC5910:Domain Name System (DNS) Security Extensions Mapping for the Extensible
Provisioning Protocol (EPP)
23.5.8. Internationalized Domain Names
The IDN tables are prepared and submitted presented in the answer for #44 (IDNs). We will implement these by correlating the IDNs to be registered with the language in reference to RFC3743, issued by IETF.
We plan to use Japanese language for the second level of .sakura, and the IDN tables mentioned above will be applied. When and if any languages other than Japanese are used, we will prepare and register an appropriate IDN table in reference to the existing IDN tables registered in IANA.
In order to achieve a most safe and secure IDN operation for the .sakura domain we will address the Japanese-specific issues by restricting the applicable strings⁄characters (only ASCII and Japanese characters can be registered) and by normalizing double-byte numerals and alphabet to one-byte letter.
In addition, our operation will be able to promptly respond to the changes in the IDN-related conditions and to the relevant RFC issuances, and incorporate the latest trends and updates in our services.
Demonstration of Technical & Operational Capability
24. Shared Registration System (SRS) Performance
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 .sakura. 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 .sakura 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 .sakura Registry Operator
The .sakura 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 .sakura Registry Operator
Certified as ICANN-Accredited Registrar, the .sakura 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. Extensible Provisioning Protocol (EPP)
25.1. EPP
.sakura will be firmly committed to supporting EPP 1.0 through the use of our SRS. Additionally, in order to stay current with evolving standards, .sakura 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 .sakura 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 .sakura 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. .sakura will support the message output in ʺjaʺ (Japanese) and support the encoding as UTF-8.
IDN:
.sakura will support IDN in compliance with IDNA2008. IDN is discussed in more detail in the answer for #44 (IDNs). .sakura 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) :
.sakura 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 .sakura 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 .sakura 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, .sakura 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
.sakura 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).
.sakura will support the IDN registration, and the detailed description is provided in the answer for #44 (IDNs).
Since .sakura 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, .sakura 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, .sakura 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 .sakura. 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 .sakura 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).
26. Whois
.sakura 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.sakura, 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.sakura, 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.sakuraʺ
Response example:
Domain Name:EXAMPLE.SAKURA
Domain ID:D1234567-SAKURA
WHOIS Server:whois.example.sakura
Referral URL:http:⁄⁄www.example.sakura
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.sakura
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.sakura
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.sakura
Name Server:NS01.EXAMPLEREGISTRAR.SAKURA
Name Server:NS02.EXAMPLEREGISTRAR.SAKURA
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.sakura
WHOIS Server:whois.example-registrar.sakura
Referral URL:http:⁄⁄www.example-registrar.sakura
Admin Contact:Joe Registrar
Phone Number:+1.3105551213
Fax Number:+1.3105551213
Email:joeregistrar@example-registrar.sakura
Admin Contact:Jane Registrar
Phone Number:+1.3105551214
Fax Number:+1.3105551213
Email:janeregistrar@example-registrar.sakura
Technical Contact:John Geek
Phone Number:+1.3105551215
Fax Number:+1.3105551216
Email:johngeek@example-registrar.sakura
〉〉〉 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.sakura
or
nameserver (IP Address)
Response example:
Server Name:NS1.EXAMPLE.SAKURA
IP Address:192.0.2.123
IP Address:2001:0DB8::1
Registrar:Example Registrar, Inc.
WHOIS Server:whois.example-registrar.sakura
Referral URL:http:⁄⁄www.example-registrar.sakura
〉〉〉 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 .sakura for Whois is 98% per calendar month.
Whois Planned Outage = will not be implemented
.sakura will not implement Planned Outages for Whois.
Whois Extended Planned Outage = will not be implemented
.sakura 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 .sakura Registry Operator will provide the Zone File FTP service for ICANN-specified and managed URL (sakura.zda.icann.org) to enable the user to access .sakuraʹs zone data archives.
The .sakura Registry Operator will grant to the user a non-exclusive, non-transferable, and limited right to access .sakura 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 ʺsakura.zone.gzʺ will be in the top-level directory of zone file access server, with the files to verify downloads ( sakura.zone.gz.md5 and sakura.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 .sakura 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 .sakura 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:
------------------------------------------------------------------------------------------------------------------------------------------------------
sakura.〈tab〉86400〈tab〉in〈tab〉soa〈tab〉tld1.dns.sakura.〈tab〉root.dns.sakura.〈tab〉1317321902〈tab〉3600〈tab〉900〈tab〉1814400〈tab〉900
example.sakura.〈tab〉86400〈tab〉in〈tab〉ns〈tab〉ns1.example.sakura.
example2.sakura.〈tab〉86400〈tab〉in〈tab〉ns〈tab〉ns1.example2.sakura.
example2.sakura.〈tab〉86400〈tab〉in〈tab〉ns〈tab〉ns2.example.jp.
ns1.example.sakura.〈tab〉86400〈tab〉in〈tab〉aaaa〈tab〉2001:0dc8:0000:0000:0000:0000:0000:0001
ns1.example2.sakura.〈tab〉86400〈tab〉in〈tab〉a〈tab〉192.0.2.1
sakura.〈tab〉86400〈tab〉in〈tab〉soa〈tab〉tld1.dns.sakura.〈tab〉root.dns.sakura.〈tab〉1317321902〈tab〉3600〈tab〉900〈tab〉1814400〈tab〉900
------------------------------------------------------------------------------------------------------------------------------------------------------
* 〈tab〉 means tab character
26.2.3. For ICANN Access
The .sakura will provide bulk access to the .sakura 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 .sakura will provide bulk access to the .sakura 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, .sakura 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 .sakura, 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 .sakura, 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 .sakura.
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).
27. Registration Life Cycle
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 .sakura 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 .sakura 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 .sakura, 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. Abuse Prevention and Mitigation
28.1. Abusive Prevention & Mitigation
As described in the answers for #18 (Mission⁄purpose), .sakura will restrict the registration and the use of the domain names to SAKURA Internet. SAKURA Internet will evaluate and qualify the second level domain name prior to registering any additional domain names to .sakura, and through this proprietary process, SAKURA Internet projects no more than about 1,000 domain name registrations for .sakura.
28.2. Single Point of Contact for Abusive Activities
As the .sakura Registry, SAKURA Internet will establish and publish the following notification on our own .sakura website:
Example:
For any abusive or illegal activities occurring within the .sakura namespace, please report or contact SAKURA Internet as follows:
Email:abuse-contact@registry.sakura (TBD)
Mailing address: (TBD)
SAKURA Internet 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 SAKURA Internet has received the inquiry and that it is currently under investigation.
--------------------------------------------------------------------------------------------------------
The above notification will be provided on the SAKURA Internet official Web site, in both English and Japanese.
As the .sakura Registry, we will collaborate cohesively with the Registrar to address and resolve any potential abusive registration.
28.3. Anti-abuse Policy
SAKURA Internet 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 ʺ.sakura Anti-Abuse Policy.ʺ
--------------------------------------------------------------------------------------------------------
.sakura Anti-abuse Policy (draft)
SAKURA Internet is committed to minimizing abusive registration activities and other illegal activities within the .sakura namespace, by including the following legal terms and conditions into all .sakura 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. SAKURA Internet 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 .sakura;
- 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.
SAKURA Internet 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 SAKURA Internet, as well as its affiliates, officers, directors, and employees; (4) per the terms of the registration agreement; (5) to correct mistakes made by SAKURA Internet or any Registrar in connection with a domain name registration; or (6) due to abusive uses, as defined above, undertaken with respect to .sakura domain names. SAKURA Internet 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.sakura (TBD).
--------------------------------------------------------------------------------------------------------
28.4. Removal of Orphan Glue Records
.sakura 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 .sakura shall not be used in any .sakura zone files.
In addition to the restricted nature of the .sakura TLD, as identified in the answer for #18 (Mission⁄purpose), and working closely with each of the domain name registrants, SAKURA Internet 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 .sakura namespace.
28.5. Enforcing Whois Accuracy
As described in the answer for #18 (Mission⁄purpose), the registration and the use of .sakura domain names will be limited to SAKURA Internet. Therefore, no domain names will be allocated within the .sakura name space unless SAKURA Internet identifies the requesting party as one of an SAKURA Internet.
We also ensure that .sakura will promptly update any changes in the .sakura 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), SAKURA Internet 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 .sakura for ourselves, and SAKURA Internet will be the sole registrant of .sakura.
SAKURA Internet will take the appropriate measures if SAKURA Internet receives the investigative documents relevant to domain names registered in .sakura, 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), SAKURA Internet will be the sole registrant of .sakura and we intend to provide the second level domain of .sakura for ourselves, and SAKURA Internet will be the sole registrant of .sakura.
SAKURA Internet will assign a person in charge for administrating the .sakura domain name registrations (i.e., registration, renewal, modification of registration information, deletion, etc.)
The administrator described above will comply with the SAKURA Internetʹ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 .sakura 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
.sakura 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 .sakura. 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 .sakura 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
.sakura plans to implement necessary countermeasures to prevent and mitigate abusive activities for .sakura. Nevertheless, the second level domain names of .sakura will be provided for SAKURA Internet its own, and SAKURA Internet 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 .sakura 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. Rights Protection Mechanisms
29.1. A Tapestry of Rights Protection Mechanisms
.sakura 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), .sakura intends to provide the second level domain of .sakura for the SAKURA Internet, and SAKURA Internet itself will be the sole registrant and the primary user of .sakura. SAKURA Internet 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 SAKURA Internet projects no more than 1,000 domain name registrations for .sakura.
29.1.2. Sunrise Services
.sakura is prepared to provide a Sunrise Service for .sakura, as set forth in the Applicant Guidebook.
29.1.3. Trademark Claims Services
.sakura is prepared to implement the Trademark Claims Services (TCS) for .sakura, as set forth in the Applicant Guidebook. Due to the restricted nature of the .sakura and the pre-verification of all domain name registrations (as described in the answer for #29.1.1 (Pre-Verification) ), .sakura does not foresee any difficulties in implementing a TCS. As identified in the answer #29.3 (Resource Planning) below, .sakura is committed to dedicating the necessary staff members and resources to ensure that all RPMs are implemented. Furthermore, .sakura is closely monitoring the work of ICANNʹs Trademark Clearinghouse Implementation Assistance Group, to ensure that SAKURA Internet implements a best-in-class service for .sakura.
29.1.4. Uniform Domain Name Dispute-Resolution Policy (UDRP)
Due to the restrictive nature of .sakura (as described in the answer for #29.1.1 (Pre-Verification) ), .sakura believes that the probability of dispute proceedings regarding .sakura domain names will be very low. However, .sakura 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, .sakura intends to develop a constructive working relationship with all ICANN UDRP providers.
29.1.5. Uniform Rapid Suspension System (URS)
Although .sakura does not foresee any potential URS implementation issues due to the proposed restrictive use of the .sakura, we will be committed to allocating the necessary staff and resources to implement a best in class solution. Specifically, .sakura will ensure the following:
* All .sakura 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 .sakura support staff;
* .sakura 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;
* .sakura will unlock the domain name if the URS Provider notifies it that an Examiner has issued a Determination in favor of the Registrant;
* .sakura 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
* .sakura 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 .sakura does not foresee any potential Trademark PDDRP proceedings due to the proposed restrictive use of the .sakura, 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 .sakura 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 .sakura 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 .sakura will not have any issues by implementing ICANN UDRP or URS that are required by the Applicant Guidebook.
29.3. Resource Planning
.sakura plans to implement necessary measures for the Rights Protection Mechanisms for .sakura. Nevertheless, the second level domain names of .sakura will be provided for SAKURA Internet, and SAKURA Internet 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 .sakura 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(a). Security Policy: Summary of the security policy for the proposed registry
30.1. SAKURA Internet ISMS Operation
SAKURA Internet has implemented and been operating its Information Security Management System (ISMS) in order to cope with the critical management issue to protect the information assets from the various threats. Our ISMS protects our information assets from different kinds of threat, and we operate the management system based on a PDCA cycle. In case of an apparent damage, we are prepared with a task force to respond rapidly to recover from damages, in order to maintain and continue our operations and businesses.
SAKURA Internet has obtained the certification for the information security management standards, JIS (Japan Industrial Standard) Q 27001:2006 (ISO⁄IEC27001:2005), in April of 2006. The ISO27001⁄ISMS is the international strndard with a third-party conformity assessment system pertaining to the proper establishment and operation of a documented Information Security Management System (ISMS).
In July 2006, SAKURA Internet has obtained the Privacy Mark Certification complying with the Japan Industrial Standard, Compliance Program for Personal Information Protection, JIS Q 15001:2006, as it recognized the importace of the personal information.
Privacy Mark is an evaluation program based on the JIS Q 15001 standard with a third-party conformity assessment system, and the program evaluates and certifies businesses of their comformity pertaining to the implementation of personal information protection. SAKURA Internet has established a personal information protection management system, pertaining to the personal information protection, and we have implemented and maintained it and will continue to improve it.
30.1.1. SAKURA Internet Information Security Fundamenatl Policy
In implementing ISMS, we will reveal the fundamental policy by presenting ʺISMS Manualʺ as the basis for the operation of our information security management system. As an internet services provider, SAKURA Internet has been striving to become a type of company that the society requires, by joinning its entire forces, and always with new ideas and an ability to take action.
We have created the information security fundamental policy for the purpose of treating the various information assets properly by complying with the relevant laws and regulations pertaining to the information security and with the security obligations set forth in the agreement, establishing the autonomous rules adequate for our coporate philosophy.
Based upon the ideas behind our information security fundamental policy, we will implement appropriate information security pertaining to comprehension, management and secutiry measures of the information assets, by making a concerted effort of the executive officers and employees (including contracted employees, temporary staffs, part-time employees and other personnel from the subcontractors).
The details of the SAKURA Internet Information Security Fundamanetal Policy and its action guidelines are described in the answer for #30.6 (SAKURA Internet Information Security Policy).
30.1.2. Risk Management
SAKURA Internet shall implement appropriate risk management strategies to manage effectively avoiding or minimizing unexpected contingent losses casued by various risks, with a minimal expense. The details of .sakura risk management are described in #30.7 (Risk Management).
30.1.3. Information Security Organization
SAKURA Internet 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. Information Asset Management
SAKURA Internet shall classify information in order to manage confidential information properly and all information shall be handled according to the classification level.
The details of information asset management are described in #30.9 (Information Asset Management).
30.1.5. Human Resources Security
In order to prevent security breaches such as inteneded or non-intended human error and misuse by the executive officers and employees, SAKURA Internet shall implement human resource security such as background checks and security trainings. The details of human resource security are described in #30.10 (Human Resources Security).
30.1.6. Physical Security
SAKURA Internet shall implement entry controls for SAKURA Internet offices 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 minimise the risk of systems failures, SAKURA Internet shall establish communications and operations management such as third party service delivery management, network and storage 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
The SAKURA Internet 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. SAKURA Internet 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 Development and Maintenance
While developing information systems, SAKURA Internet shall conduct a risk assessment and implement security measures which commensurate with the anticipated amount of the damage caused by a system failure or a security breach. The details of information systems development and maintenance are described in #30.14 (Information Systems Development and Maintenance).
30.1.10. Information Security Incident Management
SAKURA Internet 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
SAKURA Internet shall design and maintain the procedures necessary to ensure the continued business activities by recovering the critical information systems, in the occurrence of natural or earthquake disaster or in the case of communications facilities failures and malfunctions, take into the account the major risk of our services and operations being interrupted for a long period of time.
SAKURA Internet shall plan and conduct a business continuity test on a regular basis to ensure that the plan functions effectively. Furthermore, we will evaluate the plan after the periodic test in order to make sure that the plan is compatible with the most current business conditions.
30.1.12. Internal Audits
SAKURA Internet 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 .sakura
As described in the answers for #18 (Mission⁄purpose), the .sakura will restrict the registration and the use of the domain names to within SAKURA Internet, and SAKURA Internet projects that the maximum registration number for .sakura to be no more than 1,000. The .sakura will be built based not only on the best practice of the SAKURA Internet information security but also on the knowledge and skills required to operate registry services, provided by the .sakura Registry Operator. This enables SAKURA Internet to apply adequate security measures to the .sakura registry services.
30.3. Compatibility with Other Capabilities
Various security measures are implemented in the .sakura registry services based on the SAKURA Internet Information Security Fundamanetal Policy. The security measures implemented in five main registry functions, specifically Shared Registration System, DNS, DNSSEC, Registry Data Publication Services (Whois, Zone File Access, Bulk Registration Data Access), and Data Escrow, are described in #30.17 (Security Measures Implemented in Five Major Registry Services). Further detailed technical and operational approaches to implement security measures are described in the answers for the following:#24 (SRS performance), #25.1 (EPP), #26 (Whois), #27 (Registration life cycle), #28 (Abuse prevention & mitigation), #29 (Rights protection mechanisms), #31 (Technical overview of proposed registry), #32 (Architecture), #33 (Database capabilities), #34 (Geographic diversity), #35 (DNS service compliance), #36 (IPv6 reachability), #37 (Data backup policies and procedures), #38 (Escrow), #39.4.2 (Registry Continuity), #40 (Registry transition), #41 (Failover testing), #42 (Monitoring and fault escalation processes), #43 (DNSSEC), #44 (IDNs). Also, the resourcing and financial planning are described in the answers for the following:#45 (Financial statements), #46 (Projections template: costs and funding), #47 (Costs: setup and operating), #48 (Funding and revenue), #49 (Contingency planning), #50 (Continuity: continued operations instrument).
30.4. Commitments Made to Registrants for Security and Compliance
SAKURA Internet understands that it is very important to provide adequate security to the .sakura registry services. In July 2006, SAKURA Internet has obtained the Privacy Mark Certification complying with the Japan Industrial Standard, Compliance Program for Personal Information Protection, JIS Q 15001:2006, and we have established a personal information protection management system, pertaining to the personal information protection. We have implemented and maintained the system and continued to improve it. The following are the most important commitments made to registrants regarding its security levels:
- Compliance with the regulations and related laws for the personal information protection, as well as with the guidelines set forth by the responsible ministries and agencies, and by the related industry associations;
- Handling registration information in compliance with JIS Q 15001:2006
- Operation of DNSSEC on the basis of .sakura DPS
These commitments can be ensured by deploying security measures in accordance with the principles of the SAKURA Internet information security rules and regulations.
30.5. Referenced Security Standards
In the security point of view, SAKURA Internet refers to and shall comply with the following RFC.
- RFC2870
ʺRoot Name Server Operational Requirements RFC 2870,ʺ IETF 〈http:⁄⁄www.ietf.org⁄rfc⁄rfc2870.txt〉
In addition, SAKURA Internet has been certified for the following standards and shall operate in accordance with the certification standards:
・JIS Q 27001:2006 (ISO⁄IEC27001:2005)
・JIS Q 15001:2006 (Privacy Mark)
© Internet Corporation For Assigned Names and Numbers.