23 Provide name and full description of all the Registry Services to be provided
|gTLD||Full Legal Name||E-mail suffix||Detail|
|.jprs||Japan Registry Services Co., Ltd.||jprs.co.jp||View|
For the purpose of this answer the following terms are defined as follows:
The registrant of .jprs:Japan Registry Services Co., Ltd. (JPRS) is the sole registrant of .jprs in this proposal.
An ICANN accredited Registrar for .jprs:JPRS will designate the registrar.
The entire internet society, including internet users, government agencies and other associated businesses (gTLD⁄ccTLD Registries and gTLD Registrars).
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.
Policy makers, technology providers, internet researchers and institutions.
Front and back-end registry operations which include registry services and necessary operations to support those services.
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
4. Registration Data Publication Service by means of the Whois protocol
5. Registry Data Escrow
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:
**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
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.
Approved Providers for Transfer Dispute Resolution Policy
Policy on Transfer of Registrations between Registrars (Revision Adopted November 7, 2008, Effective March 15, 2009)
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).
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.
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.
Similar gTLD applications: (0)
|gTLD||Full Legal Name||E-mail suffix||z||Detail|