ICANN New gTLD Application

18.4.  Our Target Relations
As .jprs is intended to contribute in expanding the internet community, it recognizes its goals as building relations with various types of communities and providing benefits based upon each relation.  For detailed description, please see #18.6 (Objectives and Purposes of Our Relations Symbol).
We define ʺInternet Communityʺ as the entire internet society, which consists of internet users, government agencies, associated businesses (gTLD⁄ccTLD Registries and gTLD Registrars), and .jprs focuses on the following three ʺtarget relations,ʺ on the basis of its objective concept (Our Three Goals) :
A) Relations with the business partners (Reinforcing business partnerships) :
Accredited partners, telecommunications partners, and other community partners
B) Relations with the research communities (Researching and accommodating diversified internet usersʹ needs) :
Internet researchers and institutions, technology providers, policy makers
C) Relations with the domain name users (Improving domain name user values) :
Domain name users in general

Taking advantage of the open internet environment, .jprs will allow utilization of second level domain and proprietary information sharing under the reliable (authenticated) conditions.  In other words, the internet communities and the users will be able to enjoy and take full advantage of the benefits under a secured environment by sharing .jprs.
We have come up with the concept of .jprs as the symbol to build such productive relations, and we propose to leverage top level domains for the purpose of developing mutually beneficial relations:
A) A Symbol to Build Relations with JPRS Partners:
We call this symbol the ʺAuthenticated Partner Relations,ʺ and we will leverage this domain for the JPRS partners, registering the names of our accredited partners and associated communities for the second level domains, and utilizing information for sharing and distribution to demonstrate its safety and reliability in practice.  The practice will be open to the internet community.
B) A Symbol to Build Relations with Research Communities:
We call this the ʺAuthenticated R&D Relations,ʺ and we will leverage this domain for the internet researchers and institutions to research on technologies and policies applied in the expanding and evolving domain name space.  The second level domains will be shared with the technology providers and the policy makers, and we will proactively cooperate with the industry organizations by providing our research results for them to take advantages of our experiences and accumulated know-how for the purpose of achieving a healthy and robust internet.
C) A Symbol to Build Relations with Registrants and Domain Name Users:
We call this symbol the ʺPublic Relationsʺ and we will leverage this domain to promote TLDs as a part of our activities to improve the value of the TLD and domain names, and contributing to the further development of the entire TLDs including .jp.  Specifically, we will promote by setting examples of applications and user-friendliness in practice, demonstrating simplified access from the internet community and increased recognition of the TLD and domain names.

18.5.  Our Challenges
*As the number of TLDs increases, we cannot deny the possibility of misunderstanding about how to utilize TLDs correctly, due to a shortage of information:We see more commercially oriented information, but less information about maintaining the stability (by technologies) and safety (by policies), hence causing low understanding.  Consequently, many businesses and organizations are waiting to see how new gTLD will evolve (how others will take advantages of the opportunity).  The information pertaining TLDs and domain names, in English, can be found relatively often, but the information originated from Japan and in Japanese is yet very limited.  Evidently, thereʹs a need for more distribution and sharing of the information in Japanese, providing the information from the basics to the technical in various levels and subjects.
*The JPRS accredited partners and other registries are concerned, as well, about the shortage of information pertaining TLDs, thus there is an increasing need for disseminating and sharing information specifically for the JPRS partners, regarding safe and secure domain usage, existing DNS⁄domain name usage, and research information about relevant technologies and policies.  We recognize the need for reinforcing the relations with the JPRS partners by distributing and sharing sufficient information.
*The internet community is expecting JPRS, as the leading Registry and public institution, to contribute to the Registry industry and the internet community as a whole.  We acknowledge that it is our mission to serve upon such social requests through educational activities such as disseminating public information, and contributing to the future of the Registry Industry and the entire internet community.
*We believe that there is not enough research and provisions for the internet community in the areas of consumer protection:e.g.  trademark and child protection.  We recognize the need for building relations with relevant policy makers and supporting them in creating new policies through research and other efforts.
*We have many open technology challenges, such as DANE, EAI, BCP for DNSSEC, and TLD key algorithm rollover, and there have been actual cases of DNSSEC failures and accidents, however, there are not many research institutions or councils in Japan to address them.  We are encouraged to build relationships with the relevant research institutions, in support for the efforts to innovate and advance applied technologies and operations⁄practices.

18.6.  Objectives and Purposes of Our Relations Symbol

A) Authenticated Partner Relations
JPRS PARTNERS:
Accredited Partners, Telecommunications Partners, Research Institutions, and Other Associated Communities.
PURPOSE:
JPRS has about 600 accredited partners and many associated industry communities, and if we are able to deploy .jprs as a mutual authenticated TLD, then it will structure a new form of communications and relations for the future expansion and development of TLDs.
OBJECTIVE:
Our objective is to provide a mutual and dedicated second level domain for the partners, so that they will be able to take advantages of the authenticated top level domain, and be able to share the benefits obtained from the relations with their the domain name users.

B) Authenticated R&D Relations
R&D PARTICIPANTS:
Internet Researchers⁄Institutions, Technology Providers and Policy Makers.
PURPOSE:
Currently, there are not many authenticated top level domains that are intended for collaborative research and studies with external industry participants, and there is a need for expanding external relations to study and research about the effects on the internet community under various themes and issues as the number of TLDs increases.
OBJECTIVE:
Our objective is to share the second level domain of .jprs by registering the string as the name of themes or participants for particular research and studies in the areas of technology (i.e.  DNS and domain name usage) and policy (i.e.  trademark and child protection), specifically exploring the reliability⁄authenticity, safety, stability, usability, and economic efficiency, which should be effective in expanding the external relations.  Ultimately, as a dignified leading Registry our goal is to contribute our feedbacks to society regarding the results produced through our proprietary research and studies, guiding towards a robust and healthy standard.

C) Public Relations
DOMAIN NAME USERS:
Existing and potential domain name users within the internet community.
PURPOSE:
The lack of fundamental information and educational activities concerning the domain name in general has caused confusions and uncertainties about the purposes and effects of the new gTLD.  JPRS, as the leading Registry, should be able to provide those educational activities and fundamental information through a live practice to distribute information that is beneficial to the domain name registrants and their users.
OBJECTIVE:
As a leading Registry, our objective is to contribute to the society by taking full advantage of the JPRS achievements, formalizing accumulated know-how, and providing the information about the new gTLD through the practice of .jprs:how to use it securely and safely, as well as how to use the existing DNS and domain names.  Additionally, we will be prepared to respond to questions and inquiries from the existing and potential domain name users as well as associated internet communities.

18.7.  Our Efforts on The Relations Symbol
Following are the primary registry services (including critical registry functions) that JPRS plans to provide for .jprs:Please see #23 (Registry Services).
(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, JPRS will implement the above eight main functions, on the premise of providing registrations for the .jprs second level domain.  Other advanced features such as authentication related process⁄functions for the second level domain users, will be required for third level domain name registrations and second level domain operations, and that will be deliberated and supported individually and accordingly.

JPRS plans for the following efforts and outreach activities in promoting the new gTLD and .jprs:

Authenticated Partner Relations:
-Authenticating and administering the .jprs second level domain users (identify, activate, deactivate)
-Share authenticated second level domain of .jprs with the JPRS partners
-Share proprietary information through .jprs with the JPRS partners
-Guide and advise on domain names in general
-Provide information concerning the new gTLD application⁄answering guidance

Authenticated R&D Relations:
-Authenticating and administering .jprs second level domain users (identify, activate, deactivate)
-Share authenticated second level domain of .jprs with the research institutions
-Promote .jprs to various communities as the relations symbol for the purpose of collaborative research (use at no charge)
-Organize scheduled community gatherings (seminars and workshops)
-Provide research related stream content (video) over the internet
-Promote .jprs proactively to the external participants:
1) to share proprietary research information with affiliated communities
2) to educate and support bearers of Japanʹs internet community

Public Relations:
-Share proprietary information through .jprs with the registrants through an information Web site (i.e.  fundamental information about domain names)
-Post information about ICANN and its activities
-Share our .jprs application answers (in Japanese) through .jprs
-Post information about IDN ccTLD
-Post information about the new gTLD (i.e.  case studies and explanation of ICANN Applicant Guidebook in Japanese)

23.1. Definition
For the purpose of this answer the following terms are defined as follows:
-.jprs Registrant:
The registrant of .jprs:Japan Registry Services Co., Ltd. (JPRS) is the sole registrant of .jprs in this proposal.
-.jprs Registrar:
An ICANN accredited Registrar for .jprs:JPRS will designate the registrar.
-Internet Community:
The entire internet society, including internet users, government agencies and other associated businesses (gTLD⁄ccTLD Registries and gTLD Registrars).
-JPRS Partners:
The JPRS Accredited Partners and other business partners, including telecommunications partners, collaborating research institutions and other community partners.
-.jprs Domain Name Users:
The users of .jprs within the Internet Community, including potential domain name users.
-Research Community:
Policy makers, technology providers, internet researchers and institutions.
-Registry Operations:
Front and back-end registry operations which include registry services and necessary operations to support those services.
-Critical Functions:
Functions that are critical to the operation of a gTLD registry:
1. Domain Name System (DNS) Resolution
2. Domain Name System Security Extensions (DNSSEC)
3. Shared Registration System (SRS) by means of the Extensible Provisioning
Protocol (EPP)
4. Registration Data Publication Service by means of the Whois protocol
5. Registry Data Escrow

23.2. Introduction
JPRS aims to become one of the first ICANN new gTLD accredited operators in Japan, and will utilize .jprs as ʺrelations symbol,ʺ specifically for enhancing partner relations and improving user values, and ultimately expanding and revitalizing the internet community as a whole.

We define ʺInternet Communityʺ as the entire internet society, which consists of internet users, government agencies, associated businesses (gTLD⁄ccTLD Registries and gTLD Registrars). .jprs will focus on the following three ʺtarget relations,ʺ on the basis of its objective concept described in the answer for #18 (Mission⁄purpose) :ʺOUR THREE GOALSʺ:

A) Reinforcing business partnerships through .jprs relations:
Accredited JPRS partners, telecommunications partners, collaborating research institutions and other community partners
B) Researching and accommodating diversified internet usersʹ needs through .jprs relations:
Various research communities, such as policy makers, technology providers, Internet researchers and institutions
C) Improving domain name user values through .jprs relations:
Domain name users in general

Taking advantage of the open internet environment, .jprs will allow utilization of the second level domains and proprietary information sharing under the reliable (authenticated) condition. In other words, by sharing .jprs the internet communities and users can enjoy and take full advantage of the benefits under a secured environment, by sharing .jprs.

In our initial stage of this plan, JPRS will implement eight main services on the premise of providing registrations for .jprs second level domain. Other advanced features such as authentication related process⁄functions for the second level domain users, which are mainly required for third level domain name registrations and second level domain operations, will be deliberated and supported individually and accordingly.

We believe that by providing a comprehensive range of proposed registry services, JPRS could support and achieve our defined objectives for .jprs.

23.3. Our Premise:Business Considerations
**As stated in the answer for #18.8 (Our Premise), JPRS will be the sole registrant of .jprs. We intend to provide the second level domain of .jprs for our JPRS partners, specific associated communities and other strategic partners. Following are some examples:
ʺaccreditedpartnername.jprs,ʺ
ʺinformationproviderservicename.jprs,ʺ
ʺtechnologycommunityname.jprsʺ

**As JPRS will be the sole registrant of .jprs, JPRS assumes we will have no multiple applications for our second level domain names. JPRS will apply its own ʺSecond Level Domain Evaluation Criteriaʺ to review and evaluate the potential users and objectives, and JPRS will register only the qualified second level domain names⁄strings:please see ʺFigure 23-1SLD (Second Level Domain）Evaluation Criteria.ʺ
In this regard, however, if by chance, we face another application for the same particular second level domain name (i.e. ʺpartnername.jprsʺ) we will resolve the matter on a first-come and first-serve basis.

Figure 23-1SLD (Second Level Domain）Evaluation Criteria

Description of Criteria
A) RELATIONS:Adequacy for .jprs (relations symbol)
B) OBJECTIVES:In conformity with the objectives and activities of relation symbol
C) STRING:Affinity, reservation, DNS Stability
D) LEGAL:Causal association and legal standing
E) INTEREST:Interests by government agencies and other communities and associations

**As a Registry providing services to Registrar for .jprs, JPRS offers initial domain name registration for a period of 1 to 10 years, in compliance with the Registry Agreement.

**We do not intend to charge for the .jprs registrations. However, should we decide to charge for it, we will notify the Registrar in advance, complying with the Registry Agreement.

**Our measures regarding the registration of .jprs second level domains, in terms of the registration lifecycle as well as the policies to protect the registrants and proprietors of trademarks, are described in the answers for #27 (Registration life cycle), #28 (Abuse prevention & mitigation) and #29 (Rights protection mechanisms).

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

**Our implementation of JPRS becoming the sole registrant, servicing⁄sharing .jprs with our internet community partners⁄users at no charge, should provide cost benefits, advantages and effectiveness. By achieving the goals of .jprs, described in the answer for #18 (Mission⁄purpose), and building objective relations, we believe that registrants and users will mutually enjoy the benefit. In terms our financial cost description, please refer to the answers for #46 (Projections template:costs and funding) and #47 (Costs:setup and operating).

**We project that the .jprs second level registered domain names to be as many as 1,000 during the initial one to three years. As partially described in the answer for #18 (Mission⁄purpose), we currently have about 600 accredited business partners and some hundreds of associated communities and strategic partners (including the potential partners as well). Based on those underlying numbers, we estimate that the second level registered domain names will grow from approximately 300 in the first year, then that number will double in the second year, and reach approximately 1,000 in the following year.

**JPRS intends to build an in-house operational system and implement its own backend registry operations as well as validation processes, not relying on outsourcing to third parties.

23.4. Intended Services ⁄Functions:Technical Considerations
Although JPRS will be the sole registrant of .jprs, we intend to share the second level domains of .jprs with our JPRS partners (business partners and various community partners).

With JPRS being the registrant, JPRS, at its own discretion, will choose a Registrar for .jprs among the ICANN accredited registrars, which should be able to manage and operate an evaluation process to qualify potential users and objectives, and should be capable of the operating .jprs Registry.

Given the business considerations, our specific objectives along with the continued ongoing evolution of the domain name market, JPRS proposes the following comprehensive range of registry services to support .jprs, 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 .jprs to be a FSFC registration registered in one year annual increments for up to a maximum of ten (10) years. JPRS will also provide the ability to renew a domain in annual increments. Details of Registration Life Cycle of .jprs 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
JPRS 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.ʺ
JPRS will also provide the Bulk Transfer service for .jprs, 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. JPRS 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 .jprs 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. JPRS 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.
JPRS will provide public access to the Whois database servers as required under the Registry Agreement.
JPRS 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, JPRS 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), JPRS will apply its own evaluation criteria to review and evaluate the potential users and objectives, and JPRS will register only the qualified second level domain names⁄strings. Additionally, we will be able to provide the most current and accurate .jprs contact information through the Whois search, because the .jprs users will mainly be the JPRS accredited partners and various community partners, with whom JPRS have particular relationships.

23.4.5. Registrar Support Services
The implementation of Registrar Support Services will be limited, due to the fact that JPRS, having the liberty of selecting an ICANN accredited Registrar for .jprs at its own discretion, plans to choose a specific Registrar that is capable of managing and operating the .jprs 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, JPRS will facilitate (test and certify) the Operational Test and Evaluation (OT&E) certification process for the Registrars.
B) Registry Operatorʹs Website:
JPRS 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 .jprs 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.ʺ JPRS adopts DNSSEC into .jprs. The technical implementation of DNSSEC is explained in the answered for #43 (DNSSEC).

23.4.8. Internationalized Domain Names
JPRS will support IDN in .jprs in a fully standards-compliant fashion at the time of transition. JPRS has implemented IDN in Japanese, and in line with ICANN guidelines and IETF standards.
The Japanese language will be used for .jprs and the IDN tables, presented in the answer for #44 (IDNs), and will be provided as required for the second level domain. JPRS 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 .jprs, JPRS will apply the most appropriate information security measures and provide safe registry services to the users.
JPRS acknowledges that protecting the registrant information and ensuring 100% availability of DNS service are critical. Hence, we will implement extensive security measures to protect information confidentiality, safety and high availability in practice for .jprs registry services, over the past 10years. And we will practice the same level of services for .jprs, as well.
Below, we have listed the major categories of our planned security measures for .jprs 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 .jprs 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 JPRS will be the sole registrant and the user of .jprs, concerns on unauthorized access to .jprs will be limited by security protocols in place.
As per the users of .jprs second level domain, we will apply our proprietary evaluation criteria to review and evaluate the potential users and objectives, and JPRS 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 our in-house operational system in connection with domain name registrations and renewals will handle the various business use cases. Hence, JPRS does not plan to rely on third party operators for the backend registry operations, and does not consider potential security and stability issues in case of outsourcing the registry services to the third parties.
JPRS 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,ʺ JPRS acknowledges that it may have to exercise some enhanced security protocols when transferring EPP Auth Codes to successful Registrants to allow them to transfer domain names to a registrar of their choice.
JPRS will work to determine the best technical implementation to address the business needs of the .jprs registry. In addition, JPRS will ensure that the security and stability weaknesses identified in the SSAC reports are proactively addressed for the benefit of JPRS and .jprs 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.
JPRS 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
JPRSʹs know-how and familiarity of the 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 .jprs 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.
JPRS 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, JPRS will provide the DNSSEC service. Providing DNSSEC is a long term investment that will increase the level of security, stability and trust within the .jprs.
Also, JPRS has published the .jprs DNSSEC Practice Statement (.jprs DPS) in order to declare that operates DNSSEC of .jprs registry services properly:Please refer to the answer of #43 (DNSSEC) for more detailed information.
The following RFCs will be used in .jprs:
* 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
JPRS has implemented IDN in Japanese, and in line with the ICANN guidelines and the IETF standards.
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 .jprs, 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 .jprs domain we will address the Japanese-specific issues by restricting the applicable strings⁄characters (only ASCII and Japanese characters can be registered) and by normalizing double-byte numerals and alphabet to one-byte letter.
In addition, our operation will be able to promptly respond to the changes in the IDN-related conditions and to the relevant RFC issuances, and incorporate the latest trends and updates in our services.

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

24.2. SRS system description
Only the EPP will be available for the interface between registry and registrar in .jprs. 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 .jprs 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 .jprs Registry Operator
JPRS has been building and operating, as a JP registry, the registry system including SRS for more than 10 years, and has several staff members with abundant experiences and expertise for stable SRS operation.

24.3.2. Registrar System Building and Operation Performance as Accredited Registrar
Certified as ICANN-Accredited Registrar in 2009, JPRS has been building and operating the registrar system to communicate via EPP with SRS for COM, NET, ORG, BIZ, INFO, MOBI, and ASIA, and has several staff members with abundant experiences and expertise in operating the EPP interface system.
24.4. Resource Planning
24.4.1. Initial Implementation
The resources required for building and setting up the networks and servers are described in the answer for (a-1) of #31.5.1 (Initial Implementation).
The resources required for the development of the software (EPP interface) are described in the answer for (b-1) of #31.5.1 (Initial Implementation). The resources required for building and setting up the SRS database are described in the answer for (c-1) of #31.5.1 (Initial Implementation).
24.4.2. Ongoing Maintenance
The resources required for the maintenance of the software (EPP interface) are described in the answer for (d-1) of #31.5.2 (Ongoing Maintenance). The resources required for the maintenance of the SRS database are described in the answer for (e-1) of #31.5.2 (Ongoing Maintenance).

25.1. EPP
.jprs will be firmly committed to supporting EPP 1.0 through the use of our SRS. Additionally, in order to stay current with evolving standards, .jprs will implement support for updates to RFCs 5730, 5731, 5732, 5733, 5734, and other related updates that will be adopted as the ʺProposed Standard [RFC2026, 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 .jprs 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 .jprs 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. .jprs will support the message output in ʺjaʺ (Japanese) and support the encoding as UTF-8.
IDN:
.jprs will support IDN in compliance with IDNA2008. IDN is discussed in more detail in the answer for #44 (IDNs). .jprs 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) :
.jprs 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 .jprs 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 .jprs 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, .jprs 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
.jprs 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).
.jprs will support the IDN registration, and the detailed description is provided in the answer for #44 (IDNs).
Since .jprs 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, .jprs 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, .jprs 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 .jprs. 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. System Implementations and Operations Performance as Accredited Registrar
Certified as ICANN-Accredited Registrar in 2009, JPRS has been building and operating the registrar system for EPP communications with SRS for COM, NET, ORG, BIZ, INFO, MOBI, and ASIA, and therefore has acquired the expertise concerning SRS building and operation based on RFC.
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).

.jprs 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.jprs, 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.jprs, 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.jprsʺ
Response example:
Domain Name:EXAMPLE.JPRS
Domain ID:D1234567-JPRS
WHOIS Server:whois.example.jprs
Referral URL:http:⁄⁄www.example.jprs
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.jprs
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.jprs
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.jprs
Name Server:NS01.EXAMPLEREGISTRAR.JPRS
Name Server:NS02.EXAMPLEREGISTRAR.JPRS
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.jprs
WHOIS Server:whois.example-registrar.jprs
Referral URL:http:⁄⁄www.example-registrar.jprs
Admin Contact:Joe Registrar
Phone Number:+1.3105551213
Fax Number:+1.3105551213
Email:joeregistrar@example-registrar.jprs
Admin Contact:Jane Registrar
Phone Number:+1.3105551214
Fax Number:+1.3105551213
Email:janeregistrar@example-registrar.jprs
Technical Contact:John Geek
Phone Number:+1.3105551215
Fax Number:+1.3105551216
Email:johngeek@example-registrar.jprs
〉〉〉 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.jprs
or
nameserver (IP Address)
Response example:
Server Name:NS1.EXAMPLE.JPRS
IP Address:192.0.2.123
IP Address:2001:0DB8::1
Registrar:Example Registrar, Inc.
WHOIS Server:whois.example-registrar.jprs
Referral URL:http:⁄⁄www.example-registrar.jprs
〉〉〉 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 .jprs for Whois is 98% per calendar month.
Whois Planned Outage = will not be implemented
.jprs will not implement Planned Outages for Whois.
Whois Extended Planned Outage = will not be implemented
.jprs 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 .jprs Registry Operator will provide the Zone File FTP service for ICANN-specified and managed URL (jprs.zda.icann.org) to enable the user to access .jprsʹ zone data archives.
The .jprs Registry Operator will grant to the user a non-exclusive, non-transferable, and limited right to access .jprs 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 ʺjprs.zone.gzʺ will be in the top-level directory of zone file access server, with the files to verify downloads ( jprs.zone.gz.md5 and jprs.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 .jprs 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 .jprs Registry will provide zone files using a sub format of the standard Master File format as originally defined in Section 5 of RFC1035, 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:
------------------------------------------------------------------------------------------------------------------------------------------------------
jprs.〈tab〉86400〈tab〉in〈tab〉soa〈tab〉tld1.dns.jprs.〈tab〉root.dns.jprs.〈tab〉1317321902〈tab〉3600〈tab〉900〈tab〉1814400〈tab〉900
example.jprs.〈tab〉86400〈tab〉in〈tab〉ns〈tab〉ns1.example.jprs.
example2.jprs.〈tab〉86400〈tab〉in〈tab〉ns〈tab〉ns1.example2.jprs.
example2.jprs.〈tab〉86400〈tab〉in〈tab〉ns〈tab〉ns2.example.jp.
ns1.example.jprs.〈tab〉86400〈tab〉in〈tab〉aaaa〈tab〉2001:0dc8:0000:0000:0000:0000:0000:0001
ns1.example2.jprs.〈tab〉86400〈tab〉in〈tab〉a〈tab〉192.0.2.1
jprs.〈tab〉86400〈tab〉in〈tab〉soa〈tab〉tld1.dns.jprs.〈tab〉root.dns.jprs.〈tab〉1317321902〈tab〉3600〈tab〉900〈tab〉1814400〈tab〉900
------------------------------------------------------------------------------------------------------------------------------------------------------
* 〈tab〉 means tab character
26.2.3. For ICANN Access
The .jprs will provide bulk access to the .jprs 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 .jprs will provide bulk access to the .jprs 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, .jprs 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. Whois Building and Operation Performance as JP Registry
As JP domain registry, JPRS operates .JP and Whois consisting of not less than 1.26 million domain names of .JP and various subdomains. We have been contributing to the standardization of IDN as a responsibility of ccTLD Registry using a unique language. We provide the Port 43 Whois interface capable of switching the language of response (English or Japanese), which allows entering and displaying both IDN and punycode for Web-based Whois search.
26.5.2. Whois Building and Operation Performance as Accredited Registrar
As ICANN-accredited registrar, JPRS provides Whois service for COM, NET, ORG, BIZ, INFO, MOBI, and ASIA. and it has the technical resources to stably provide the Whois service for .jprs.
26.6. Resource Planning
26.6.1. Initial implementation
The resources required for the implementation of network servers are described in the answer for (a-1) of #31.5.1 (Initial Implementation).
In terms of the Whois (Port 43 and Web-based) software development, the resources required are explained in the answer for (b-2) of #31.5.1 (Initial Implementation).
As per the resources required for the implementation of the Whois databases and the synchronizations, we have answered in (c-1) of #31.5.1 (Initial Implementation).
26.6.2. Ongoing Maintenance
The resources required for the Whois (Port 43 and Web-based) software, in terms of ongoing maintenance, are described in the answer for (d-2) of #31.5.2 (Ongoing Maintenance).
As per the resources required for the ongoing maintenance of the Whois databases and the synchronizations, we have answered in (e-1) of #31.5.2 (Ongoing Maintenance).

The current state of the domain name registration will be managed by using two statuses; status defined in RFC5731 (hereinafter called ʺEPP statusʺ) and status extended by RFC3915 (ʺRPG statusʺ).
27.1. List of Domain Statuses
The list of the domain name statuses of the registration is as follows. The statuses of Registry Lock and Registrar Lock will be described in the answer for #27.2 (Registry Lock and Registrar Lock).
No. 1:EPP Status = ok and RGP Status = addPeriod
This is a status immediately following the new registration. The Grace Period is 5 calendar days, and when 〈delete〉 command for removal is issued within the Grace Period, the deletion process starts without giving redemption by 〈restore〉. When the Grace Period (5 calendar days) is expired, the RGP status will be removed (change to Status No. 2).
The domain name in this status will be subject to the zone file extraction.
No. 2:EPP Status = ok and RGP Status = N⁄A
This is a status in which the nameserver is operational for DNS resolution.
The domain name in this status will be subject to the zone file extraction.
No. 3:EPP:ok RGP:autoRenewPeriod
This is a status right after the ExpirationDate, where the domain name registration status has been automatically retained. The Grace Period is 45 calendar days, and when 〈delete〉 command for removal is issued within the Grace Period, the deletion process starts after giving redemption by 〈restore〉.
When the Grace Period (45 calendar days) is expired, the RGP status will be removed (change to Status No. 2).
The domain name in this status will be subject to the zone file extraction.
No. 4:EPP Status = ok and RGP Status = renewPeriod
This is a status in which the domain name registration status has been retained by 〈renew〉 command. The Grace Period is 5 calendar days, and when 〈delete〉 command for removal is issued within the Grace Period, the deletion process starts after giving redemption by 〈restore〉.
When the Grace Period (5 calendar days) is expired, RGP status will be removed (change to Status No. 2).
The domain name in this status will be subject to the zone file extraction.
No. 5:EPP Status = clientHold and RGP Status = N⁄A
This is a status in which the domain name is no longer valid at the request of the Registrar.
The domain name in this status will NOT be subject to the zone file extraction.
No. 6:EPP Status = serverHold and RGP Status = N⁄A
This is a status in which the domain name is no longer valid due to the Registry requirements.
The domain name in this status will NOT be subject to the zone file extraction.
No. 7:EPP Status = pendingTransfer and RGP Status = N⁄A
This is a status in which the transfer request is accepted and is waiting for the acknowledgment by the current (losing) Registrar.
The domain name in this status will be subject to the zone file extraction.
No. 8:EPP Status = ok and RGP Status = transferPeriod
This is a status right after the transfer completion. The Grace Period is 5 calendar days, and when 〈delete〉 command for removal is issued within the Grace Period, the deletion process starts after giving redemption by 〈restore〉.
When the Grace Period (5 calendar days) is expired, the RGP status will be removed (change to Status No. 2).
The domain name in this status will be subject to the zone file extraction.
No. 9:EPP Status = pendingDelete and RGP Status = redemptionPeriod
This status indicates right after the domain name has been removed by 〈delete〉 command, and it can be restored by a request.
The Grace Period is 30 days, and the restore request will be accepted during this period.
The domain name in this status will NOT be subject to the zone file extraction.
No. 10:EPP Status = pendingDelete and RGP Status = pendingRestore
This is a status in which the domain has been removed after receipt of 〈delete〉 command. The Grace Period is 7 calendar days, and if the Report is received, the EPP status will become ʺokʺ and the RGP status will be removed (change to Status No. 2).
If the Report is not received, the status returns to ʺRGP = redemptionPeriodʺ (change to Status No. 9).
No. 11:EPP Status = pendingDelete and RGP Status = pendingDelete
This is a status in which the status ʺRGP = redemptionPeriodʺ has expired, and it is under the removal procedure. In this status, 〈restore〉 command cannot be accepted, and after a period of 5 calendar days, the domain name can be re-registered.
If two nameservers are not implemented then the status will become inactive instead of ʺok.ʺ
Also, because the .jprs 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 Performance as JP Registry
JPRS, as a Registry, currently manages the registrations for JP domain names, and therefore possesses the technical expertise to manage the domain name Registration Life Cycle.
27.4.2. System Implementations and Operations Performance as Accredited Registrar
As ICANN-accredited registrar, JPRS provides Whois service for COM, NET, ORG, BIZ, INFO, MOBI, and ASIA. and therefore possesses the expertise to manage the domain name Registration Life Cycle.
27.5. Resource Planning
27.5.1. Initial Implementation
The resources required for implementing the Life Cycle of Registration is described in the answer for (b-1) of #31.5.1 (Initial Implementation).
27.5.2. Ongoing maintenance
The resources required for the ongoing maintenance of the Life Cycle of Registration is explained in the answer of (d-1) of #31.5.2 (Ongoing Maintenance).

28.1.  Abusive Prevention & Mitigation
In 2010, .jp was recognized as one of the worldʹs safest country code top-level domains (ccTLDs) for the second consecutive year, see http:⁄⁄us.mcafee.com⁄en-us⁄local⁄docs⁄MTMW_Report.pdf
JPRS intends to duplicate these very same qualities within the .jprs namespace.

As described in the answers for #18 (Mission⁄purpose), .jprs will restrict the registration and the use of the domain names to JPRS and its partners.  JPRS will evaluate and qualify the second level domain names prior to registering any additional domain names to .jprs, and through this proprietary process, JPRS projects no more than about 1,000 domain name registrations for .jprs.
28.2.  Single Point of Contact for Abusive Activities
As the .jprs Registry, JPRS will establish and publish the following notification on our own .jprs website:
Example:
For any abusive or illegal activities occurring within the .jprs namespace, please report or contact JPRS as follows:
Email:abuse-contact@registry.jprs (TBD)
Mailing address: (TBD)
JPRS 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 JPRS has received the inquiry and that it is currently under investigation.
--------------------------------------------------------------------------------------------------------
The above notification will be provided on the JPRS official Web site, in both English and Japanese.
Consistent with the existing operational experience gather in connection with the .jp namespace, JPRS will collaborate cohesively with the Registrar to address and resolve any potential abusive registration.
28.3.  Anti-abuse Policy
JPRS 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 ʺ.jprs Anti-Abuse Policy.ʺ
--------------------------------------------------------------------------------------------------------
.jprs Anti-abuse Policy (draft)
JPRS is committed to minimizing abusive registration activities and other illegal activities within the .jprs namespace, by including the following legal terms and conditions into all .jprs 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.  JPRS 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 .jprs;
- 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.
JPRS 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 JPRS, as well as its affiliates, subsidiaries, officers, directors, and employees; (4) per the terms of the registration agreement; (5) to correct mistakes made by JPRS or any Registrar in connection with a domain name registration; or (6) due to abusive uses, as defined above, undertaken with respect to .jprs domain names.  JPRS 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.jprs (TBD).
--------------------------------------------------------------------------------------------------------
28.4.  Removal of Orphan Glue Records
.jprs 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 .jprs shall not be used in any .jprs zone files.
In addition to the restricted nature of the .jprs TLD, as identified in the answer for #18 (Mission⁄purpose), and working closely with each of the domain name registrants, JPRS 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 .jprs namespace.
28.5.  Enforcing Whois Accuracy
As described in the answer for #18 (Mission⁄purpose), the registration and the use of .jprs domain names will be limited to JPRS and its partners.  Therefore, no domain names will be allocated within the .jprs name space unless JPRS identifies the requesting party as one of our JPRS partners.
We also ensure that .jprs will promptly update any changes in the .jprs 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), JPRS 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 .jprs for our JPRS partners, specific associated communities and other strategic partners, and JPRS will be the sole registrant of .jprs.
JPRS will take the appropriate measures if JPRS receives the investigative documents relevant to domain names registered in .jprs, 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), JPRS will be the sole registrant of .jprs and we intend to provide the second level domain of .jprs for our JPRS partners, specific associated communities and other strategic partners.
JPRS will assign a person in charge for administrating the .jprs domain name registrations (i.e., registration, renewal, modification of registration information, deletion, etc.)
The administrator described above will comply with the JPRSʹ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 .jprs 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
.jprs 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 .jprs.  Each of these proposed RPMs are elaborated in more detail in the answer for #29 (Rights protection mechanisms).
28.9.  Technical and Operational Resources
28.9.1.  Contribution for Abuse Prevention& Mitigation
In 2010, .jp was recognized as one of the worldʹs safest country code top-level domains (ccTLDs) for the second consecutive year, see http:⁄⁄us.mcafee.com⁄en-us⁄local⁄docs⁄MTMW_Report.pdf.  JPRS believe this ranking is in large part attributed to the attention in detail that it has devoted toward preventing and mitigating abuse within the .jp namespace, as well as its cooperative activities with JPCERT⁄CC and other security-related organizations at home and abroad.
The Registry Operator for .jprs 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.9.2.  Anti-Phishing
Through discussion in a JP domain name advisory committee, JPRS received an advisory regarding ʺhow JPRS, as the JP Registry, should act against phishingʺ which is as follows;
(1) JPRS should attempt to provide information calling for attention to Internet users to cooperate with the relevant corporations if JPRS receives warning about any phishing activities;
(2) Based on nature of role of Registry, JPRS should not delete the domain name which is used as phishing in its sole discretion.  However, JPRS should ask relative registrar to let registrant stop phishing activity.

Based on advisory above, If JPRS receives warning about any phishing activities, JPRS ask JPCERT⁄CC to give us information about suspiciousness of phishing, and act to do as (2) above.

28.10.  Resource Planning
.jprs plans to implement necessary countermeasures to prevent and mitigate abusive activities for .jprs.  Nevertheless, the second level domain names of .jprs will be provided for our JPRS partners, specific associated communities and other strategic partners, and JPRS 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.

JPRS will allocate one dedicated employee with substantial experiences in the .jp operations, for the customer support staff.  The customer support staff will enforce the countermeasures to prevent and mitigate abusive activities.  Furthermore, the same staff member will support the inquiries from the .jprs users and from the Registrar.  More detailed financial information about the allocated staff member is provided in the answer for #47.1.2 (Customer Support Labor).

29.1. A Tapestry of Rights Protection Mechanisms
.jprs 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), .jprs intends to provide the second level domain of .jprs for our JPRS partners, specific associated communities and other strategic partners,, and JPRS itself will be the sole registrant of .jprs. JPRS 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 JPRS projects no more than 1,000 domain name registrations for .jprs.
29.1.2. Sunrise Services
.jprs is prepared to provide a Sunrise Service for .jprs, as set forth in the Applicant Guidebook.
29.1.3. Trademark Claims Services
.jprs is prepared to implement the Trademark Claims Services (TCS) for .jprs, as set forth in the Applicant Guidebook. Due to the restricted nature of the .jprs and the pre-verification of all domain name registrations (as described in the answer for #29.1.1 (Pre-Verification) ), .jprs does not foresee any difficulties in implementing a TCS. As identified in the answer #29.3 (Resource Planning) below, .jprs is committed to dedicating the necessary staff members and resources to ensure that all RPMs are implemented in a manner to match or exceed its exemplary track record in the operation of the .jp ccTLD Furthermore, .jprs is closely monitoring the work of ICANNʹs Trademark Clearinghouse Implementation Assistance Group, to ensure that JPRS implements a best-in-class service for .jprs.
29.1.4. Uniform Domain Name Dispute-Resolution Policy (UDRP)
Due to the restrictive nature of .jprs (as described in the answer for #29.1.1 (Pre-Verification) ), .jprs believes that the probability of dispute proceedings regarding .jprs domain names will be very low. However, .jprs 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, .jprs intends to develop a constructive working relationship with all ICANN UDRP providers.
29.1.5. Uniform Rapid Suspension System (URS)
Although .jprs does not foresee any potential URS implementation issues due to the proposed restrictive use of the .jprs, we will be committed to allocating the necessary staff and resources to implement a best in class solution. Specifically, .jprs will ensure the following:
* All .jprs 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 .jprs support staff;
* .jprs 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;
* .jprs will unlock the domain name if the URS Provider notifies it that an Examiner has issued a Determination in favor of the Registrant;
* .jprs 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
* .jprs will take appropriate actions with regard to the domain name in the event that a Notice of Appeal is filed.

JPRS has the experience in developing and implementing the JP Domain Name Dispute Resolution Policy (JP-DRP). Therefore, JPRS should not have any issues implementing the URS.

29.1.6. Trademark Post Delegation Dispute Resolution Procedure (Trademark PDDRP)
Although .jprs does not foresee any potential Trademark PDDRP proceedings due to the proposed restrictive use of the .jprs, 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
In 2010, .jp was recognized as one of the worldʹs safest country code top-level domains (ccTLDs) for the second consecutive year, see http:⁄⁄us.mcafee.com⁄en-us⁄local⁄docs⁄MTMW_Report.pdf
JPRS has structured a collaborative framework with security industry organizations that have resulted in significant efforts and accomplishments. Furthermore, JPRS has the precise administrative structure for the domain name registration procedures.
Because of the careful management of the domain name registration process within the .jp ccTLD there were a total of twelve (12) domain name disputes filed in 2011, among 1.26 million total registered domain names. In fact over the past eleven years, there have been a total of only 87 domain name disputes filed under the JP Domain Name Dispute Resolution Policy (JP-DRP) which is administered by Japan Network Information Center (JPNIC)
29.2.2. Development and Implementation of the Uniform Domain Name Dispute-Resolution Policy (UDRP)
In 1999, JPNIC (Japan Network Information Center), the .jp Registry Operator at the time, created a Domain Name Dispute Resolution Policy Task Force, which evaluated ICANNʹs enacted ʺUniform Domain Name Dispute Resolution Policy,ʺ as well as WIPOʹs first report on the ʺInternet Domain Name Processʺ in modeling the current ʺJP Domain Name Dispute Resolution Policy (JP-DRP).

JPRS was established in the year 2000, by JPNIC, and after taking over the responsibilities of the .jp Registry Operator, JPRS has accumulated experience in operating and implementing the JP-DRP, over the next 10 years. Therefore, JPRS foresees no issues in implementing ICANNʹs Uniform Domain Name Dispute-Resolution Policy (UDRP) or Uniform Rapid Suspension System (URS) as required by the Applicant Guidebook.

29.3. Resource Planning
.jprs plans to implement necessary measures for the Rights Protection Mechanisms for .jprs. Nevertheless, the second level domain names of .jprs will be provided for our JPRS partners, specific associated communities and other strategic partners, and JPRS 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.

JPRS will allocate one dedicated employee, with substantial experiences in the .jp operations, for customer support. The customer support staff member will enforce the measures for the Rights Protection Mechanisms for .jprs. Furthermore, the same staff member will support the inquiries from the .jprs users and from the Registrar. More detailed financial information about the allocated staff member is defined in the answer for #47.1.2 (Customer Support Labor).

30.1. JPRS Information Security Policy and the ISMS Documents
In this section, the summary of the key measures and procedures to operate registry services will be described from JPRS information security policy and the ISMS Documents.

30.1.1. Scope
The JPRS information security policy and the ISMS Documents shall cover everything related to the JPRS registry services such as human, physical and environmental information asset and processes.

30.1.2. JPRS Corporate Philosophy and the Information Security Policy
JPRS corporate philosophy is ʹAs a company dedicated to maintaining the network infrastructure, JPRS contributes to the development of the Internet and the building of a better future for everyone.ʹ JPRS considers all the internet users in the world as our clients and that it is our social responsibility to protect registry information appropriately and handle them securely. To ensure that all personnel are aware of their responsibilities and their duties, the information security policy is further established.
The details of JPRS Information Security Policy are described in #30.6 (Information Security Policy).

30.1.3. Risk Management
JPRS shall establish risk management policy, organization and procedures to conduct risk management in order to prevent information assets from security risks such as theft, loss and damage.
The details of risk management are described in #30.7 (Risk Management).

30.1.4. Information Security Organization
JPRS 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.5. Asset Management
JPRS shall identify an owner who is responsible for each information asset and manage them appropriately depending on the sensitivity of the information. All documents of registry services are basically labeled as the most confidential documents and the only personnel who require them for operation can view them.

30.1.6. Human Resource Security
In order to prevent security breaches such as human error or misuse, JPRS shall implement human resource security such as background checks and security training.
The details of human resource security are described in #30.9 (Human Resource Security).

30.1.7. Physical and Environmental Security
JPRS shall implement entry controls for its offices and data centers to ensure that only authorized personnel are allowed access and to prevent unauthorized access, interference and damage to its business premises.
The details of physical and environmental security are described in #30.10 (Physical and Environmental Security).

30.1.8. Communications and Operations Management
JPRS shall develop the communications and operational management procedures to minimize the risk of system failures and to prevent incomplete communication, and review them at least once a year. This shall be achieved by understanding the technical and business demands required for registry services and managing the configuration of software, hardware and networks.
The details of communications and operations management such as operational procedures and change management, segregation of duties, facilities and networks, third party service delivery management, network and storage capacity management, protection against malicious and mobile code, backup, media handling, exchange of information and monitoring are described in #30.11 (Communications and Operations Management).

30.1.9. Access Control
Access control to information asset and information systems shall be implemented to ensure authorized user access and to prevent unauthorized access.
The details of access control such as user access management, privilege management, network access control, operating system access control, mobile computing and teleworking, protection against DoS⁄DDoS attacks, and intrusion detection system are described in #30.12 (Access Control).

30.1.10. Information Systems Acquisition, Development and Maintenance
JPRS shall ensure that security measures are properly implemented for new information systems.
The details of information systems acquisition, development and maintenance are described in #30.13 (Information Systems Acquisition, Development and Maintenance).

30.1.11. Information Security Incident Management
JPRS shall establish a policy and mechanisms to prevent recurrences of security incidents by monitoring security incidents which occurred and minimize the damage from them.
The details of information security incident response procedures are described in #30.14 (Information Security Incident Management).

30.1.12. Business Continuity Management
JPRS shall establish business continuity planning by considering the interference to registry services and the results.
The details of business continuity management are described in #30.15 (Business Continuity Management).

30.1.13. Internal Audits
JPRS 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 .jprs Registry Services
As described in #18 (Mission⁄purpose), JPRS intends to share the second level domain of .jprs with our JPRS partners (business partners and various community partners) and JPRS will be the sole registrant and the primary user of .jprs. Hence, JPRS projects that the .jprs second level registered domain names to be as many as 1,000.
JPRS does recognize that it is highly important to protect registrantsʹ information and ensure 100% availability of DNS service. Therefore, JPRS has implemented various security measures to protect confidentiality, integrity and availability of information while operating .jp registry services for more than ten years.
e.g.
- Access controls, network configurations
- Encryption of the communication and the data,
- Digital signature, including deployment of the DNSSEC solutions
- Diversity of software, hardware, network and site configuration
JPRS has developed the knowledge and skills which are required to operate registry services and .jprs registry services are constructed based on them. In addition, this knowledge and skills are reflected in the information security policy and the ISMS documents which apply to .jprs registry services and those documents will be reviewed and improved regularly if necessary.
Thus, it is ensured that JPRS can apply adequate security measures to .jprs registry services.

30.3. Security Capabilities to The Other Answers in This Application
Various security measures are implemented in .jprs registry services based on the JPRS information Security Policy and the ISMS Documents.
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 the five main features of the .jprs registry services). Further detailed technical and operational approaches to implement security measures are described in the other answers of ʹTechnical and Operational Capabilityʹ part of this application.
Also, the resourcing and financial planning are described in the answers of ʹʹFinancial Capabilityʹ part of this application.

30.4. Compliance with the Commitments Made to Registrants
JPRS understands that it is very important to provide adequate security to .jprs registry services.
The following are the most important commitments made to registrants regarding its security levels.
- Compliance with the Personal Information Protection Act in Japan
- Operation of DNS servers for 24⁄7
- Handling registration information by following the ʺRegistration Information Handling Manual of JPRS domain nameʺ
- Operation of DNSSEC on the basis of JPRS DPS
These commitments can be ensured by deploying security measures in accordance with the principles of the JPRS information security policy and the ISMS Documents.

30.5. Reference Security Standards
In the security point of view, JPRS refers to and shall comply with the following RFC and shall comply.
- RFC2870
ʺRoot Name Server Operational Requirements RFC2870,ʺ IETF 〈http:⁄⁄www.ietf.org⁄rfc⁄rfc2870.txt〉

In addition, JPRS refers to the following standards and shall implement their basic concepts of them, which are considered necessary to operate registry services.
- ISO⁄IEC 27001:2005,ISO⁄IEC 27002:2005,ISO⁄IEC 27005:2011
ʺInternational Organization for Standardization,ʺ International Organization for Standardization
Information technology -- Security techniques -- Information security management systems - Requirements
Information technology -- Security techniques -- Code of practice for information security management
Information technology -- Security techniques -- Information security risk management
〈http:⁄⁄www.iso.org⁄iso⁄home.htm〉
- PMBOK
ʺPMBOK (r) Guide and Standards,ʺ Project Management Institute http:⁄⁄www.pmi.org⁄PMBOK-Guide-and-Standards.aspx

Hirofumi Hotta	Director, Corporate Planning
Koki Higashida	President
Masami Muromachi	Director
Susumu Sano	Vice President

Hirofumi Hotta	Director, Corporate Planning
Koki Higashida	President
Susumu Sano	Vice President

New gTLD Application Submitted to ICANN by: Japan Registry Services Co., Ltd.

String: jprs

Originally Posted: 13 June 2012

Application ID: 1-913-735

Applicant Information

1. Full legal name

2. Address of the principal place of business

3. Phone number

4. Fax number

5. If applicable, website or URL

Primary Contact

6(a). Name

6(b). Title

6(c). Address

6(d). Phone Number

6(e). Fax Number

6(f). Email Address

Secondary Contact

7(a). Name

7(b). Title

7(c). Address

7(d). Phone Number

7(e). Fax Number

7(f). Email Address

Proof of Legal Establishment

8(a). Legal form of the Applicant

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

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

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

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

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

Applicant Background

11(a). Name(s) and position(s) of all directors

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

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

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

Applied-for gTLD string

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

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

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

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

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

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

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

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

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

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

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

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

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

Mission/Purpose

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

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

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

Community-based Designation

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

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

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

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

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

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

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

Geographic Names

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

Protection of Geographic Names

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

Registry Services

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

Demonstration of Technical & Operational Capability

24. Shared Registration System (SRS) Performance

25. Extensible Provisioning Protocol (EPP)

26. Whois

27. Registration Life Cycle

28. Abuse Prevention and Mitigation

29. Rights Protection Mechanisms

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

© Internet Corporation For Assigned Names and Numbers.