ICANN New gTLD Application

275, Jangchungdan-ro, Jung-gu
Seoul  100-730
KR

http:⁄⁄www.doosan.com

Domain Administration of Doosan Corporation

Domain Administration of Doosan Corporation

+001 82 70 4317 8217

Applicant corporation name is Doosan Corporation.
The Doosan Corporation is based on to the Commercial law Chapter 4 of KR.

Attachments are not displayed on this form.

Byungsu, Kim Vice President
Hyunkee,Shin Managing director

Attachments are not displayed on this form.

The new gTLD proposed by DOOSAN CORPORATION has purpose in protecting online brand of DOOSAN Group including DOOSAN by defending abusive registration by third parties and further raising global awareness by domain usage utilizing company name.

Main users of the new gTLD proposed by DOOSAN CORPORATION will be DOOSAN CORPORATION, DOOSAN group and its affiliates, and each main users is expected to utilize characters containing product or service or name of a board member such as product-name.DOOSAN or director-name.DOOSAN.

The new gTLD proposed by DOOSAN CORPORATION will mainly be utilized as a marketing method. Domain that is a combination of brand and company name or board member name essentially blocks registration by a third party, as well as maximizing marketing effect of companyʹs reputation as the domain composed of characters containing product or service name is expected to be used worldwide. 

For the stable operation of the new gTLD propose by DOOSAN CORPORATION, the Registry System utilizes system of Korea Internet & Security Agency (hereinafter referred to as ʺKISAʺ), and personnel required for registry system operation are supported. KISAʹs system is composed in dual system and backup system that ensures continuity of operation.  As KISA is an affiliated organization of Korea Communications Commission by the law, this means that the nation ensures continuity of registration operation. KISA has recently been recognized for stable operation of Koreaʹs national domain .kr for the last 25 years, recently receiving Certificate of Merit from ICANN.

It is expected that by utilizing characters related to goods or service of DOOSAN CORPORATION, DOOSAN Group and DOOSAN affiliates, it will increase customersʹ convenience leading to enhancement of brand value and improvement of company image.

It is also predicted that abusive registrations and other activities that have a negative impact on Internet users will be minimized, making a significant contribution in protecting intellectual properties as the registration eligibility of the new gTLD is only given to DOOSAN CORPORATION, DOOSAN Group and DOOSAN affiliates.

The new gTLD proposed by DOOSAN CORPORATION established the following registration policy to meet these expectations and predictions.

New gTLD Domain Name Registration Policy

Article 1 (Purpose)
The purpose is to regulate matters relating to the management for the New gTLD domain names of DOOSAN CORPORATION Co., LTD(hereinafter referred to as ʺDOOSANʺ).

Article 2 (Registrant Qualifications)
New gTLD domain names Registrant is limited to employees of DOOSAN or head office, subsidiary offices and partners without any country restrictions.

Article 3 (Registration Period)
1 to 10 years

Article 4 (Registration Fee)
1. The applicant or the registrant of a domain name shall pay domain name registration fee determined by the Registrar.
2. The Registrar shall pay the maintenance fee for the registration or renewal of domain names to DOOSAN.

Article 5 (Registration Requirements)
1. The alphabet [A to Z] or [a to z], Hangul Syllables(11,172 characters of complete Hangul), numbers [0 to 9] and hyphen are available for use for domain names.
2. The domain name shall contain a minimum of 3 characters and a maximum of 63 characters. If the domain name contains Hangul Syllables, it shall contain a minimum of 1 characters and a maximum of 17 characters.
3. The domain name cannot begin nor end with a hyphen and third character and fourth character cannot have consecutive usage of hyphen.

Article 6 (Responsibility of the Registrant)
1. Registrants shall ensure that all information in the registration records of a domain name is up-to-date, complete and accurate.
2. Of the registrant information, at least one of registrant name or registrant email must be information related to DOOSAN CORPORATION, DOOSAN Group or DOOSAN Affiliates.
3. Upon registration of a domain name, it is the registrantʹs responsibility to take any necessary steps to avoid infringement of othersʹ rights, and violation of the law.

Article 7 (Domain Name Registration)
1. New gTLD domain names registration is available through accredited registrars from ICANN.
2. Domain name registration application is submitted by the Registrant through the registrar and the registrar must submit the following matters to DOOSAN.
- Domain name
- Name server information
- Domain registration period
- Other issues decided by registry and registrar
3. DOOSAN must register domain name to the database in order data specified in Article 2 arrives to DOOSAN. However, if it is expected that multiple applications will be submitted at the same time or a new domain will be introduced, a separate method may be used for registration for the domain name dispute prevention and publicʹs interest.
4. DOOSAN may not register New GTLD domain name that is composed of character strings contained in Article 10 for a stable operation of domain name and the interest of public.

Article 8 (Modification of Registration Record)
1. Registrants may modify the registration record of their domain names through Registrar.
2. Upon receiving a registrantʹs request to modify the registration record, DOOSAN shall update the registrantʹs information in the database.

Article 9 (Termination of Registration⁄Deletion of Domain Names)
1. When 30 days have passed from the date that the registration record has been confirmed as being incomplete and incorrect;
2. When 30 days have passed from the date that the registrant has requested the deletion of the domain name;
3. When the fees have not been paid for up to 45 days after the expiration date;
4. When 30 days have passed from the date that the registrant was confirmed as having failed to meet the requirements as described in Article 2 or 4.

Article 10 (Reserved names)
DOOSAN limits the New gTLD domain name registration composed of the following characters at the least. The list may be updated when ICANN or GAC requires addition of limited character strings or issued character string of Korea of the times.

1. The two-character string.
2. Reserved names specified by ICANN.
3. The abbreviations (in English) of all country and territory names contained on the ISO 3166-1 list.
4. The United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardization of Geographical Names, Part III Names of Countries of the World.
5. The list of United Nations member states in all 6 official United Nations languages.
6. Characters undermining public moral and public interest of Republic of Korea.

Article 11 (Reserved Names Release)
If the limited character strings fall under the following items, limit clearance can be suggested to ICANN or release reserved names on the basis of Standard Korean Language Dictionary provided by the National Institute of the Korean Language:

1. limited string character related to trademarks recognized worldwide.
2. limited string character related to products recognized worldwide.
3. limited string character related to brands recognized worldwide.
4. limited string character related to improvement of public interest of Republic of Korea.
5. other cases in which an individual or company has right to limited string characters.

Article 12 (Dispute Resolution)
1. Resolution policy follows Post-Delegation Dispute Resolution Procedure (PDDRP) and Registry Restrictions Dispute Resolution Procedure (RRDRP) adopted by ICANN, and the resolution procedure is processed in DOOSANʹs Dispute Resolution Center (secretariat).
2. Upon the committeeʹs request to lock the registration record of a domain name, DOOSAN or Registrar shall lock the registration record of the domain name.
3. DOOSAN or Registrar shall take appropriate actions in the following circumstances:
- a determination under PDDRP or RRDRP has been finalized;
- a court order has entered into effect.

It is not likely that there will be multiple applications of a particular domain name of the new gTLD DOOSAN CORPORATION proposes, but it will be processed on the first come, first serve basis. It will be processed in an order domain name application with information required in Registration Policy Article 7.2 arrives to the registry.

However, it must be reviewed thoroughly whether it falls under the following registration requirements before its registration can be permitted. To prevent improper registration or registration to prevent usage, registration of reserved names is limited.

Registration Requirements
1.	The alphabet [A to Z] or [a to z], Hangul Syllables(11,172 characters of complete Hangul), numbers [0 to 9] and hyphens are available for use for domain names.
2.	The domain name shall contain a minimum of 3 characters and a maximum of 63 characters. If the domain name contains Hangul Syllables, shall contain a minimum of 1 characters and a maximum of 17 characters.
3.	The domain name cannot begin nor end with a hyphen and third character and fourth character cannot have consecutive usage of hyphen.
4.	Registrants is limited to DOOSAN CORPORATION, DOOSAN Group, and DOOSAN affiliates.
5.	Of the registrant information, at least one of registrant name or registrant email must be information related to DOOSAN CORPORATION, DOOSAN Group or DOOSAN Affiliates.
6.	Registrants shall ensure that all Whois information is up-to-date, complete and accurate. 

Reserved names
1.	The two-character string.
2.	Reserved names specified by ICANN.
3.	The abbreviations (in English) of all country and territory names contained on the ISO 3166-1 list.
4.	The United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardization of Geographical Names, Part III Names of Countries of the World.
5.	The list of United Nations member states in all 6 official United Nations languages.
6.	Characters undermining public moral and public interest of Republic of Korea .

Explain any fee benefits for registrants
Registration fee of the new gTLD proposed by DOOSAN CORPORATION is 100 USD per one year, and there is no fee benefits for multiple year registration or multiple registrations.

DOOSAN CORPORATION predicts there will be immeasurable benefit for the companyʹs refutation and marketing rather than temporary price benefit for the following reasons. 

Several gTLD and ccTLD registered with improper purpose or cyber squatter have been collected through WIPO dispute resolution. It is expected that there will be more of such cases. The collected domain names were simply DOOSAN.**, and it required continuous monitoring, personnel commitment ,and costly investment.

Although DOOSAN CORPORATION limits registration eligibility of new gTLD to DOOSAN CORPORATION, DOOSAN Group and DOOSAN affiliates, it can be considered that very large benefit is provided just by the expectation that no more ceaseless efforts will be put into monitoring and collecting domain names registered with improper purpose or cyber squatter.

If the new gTLD is delegated and utilized, it will use character strings of goods or services  related to DOOSAN CORPORATION, DOOSAN Group, and DOOSAN affiliates, or board member name such as product-name.DOOSAN and director-name.DOOSAN, different from existing gTLD. Expecting worldwide usage, this combination or brand and company name or board member name will not only essentially blocks registration by a third party, but also maximize marketing effect that cannot be converted into values.


Registration period and registration fee increase
An ICANN accredited registrar that has executed the registry-registrar agreement for the New gTLD will be offered an option to obtain initial domain name registrations for periods of one to ten years at the discretion of the registrar.

As DOOSAN CORPORATION does not plan to reflect any factors influencing registration fee such as inflation for the following next years (three years at the least), no increase in registration fee is planned. However, if there is an registration fee increase, an ICANN accredited registrar that has executed the registry-registrar agreement for the New gTLD shall advance a written notice of any fee increase (including the result of the elimination of any refunds, rebates, discounts, product tying, Qualified Marketing Programs or other programs which had the effect of reducing the fee charged to registrars) in no less than one hundred eighty (180) calendar days. Also, it complies to and executes as the registry agreement Article 2.10 states.

2.10 Fees for Registry Services.
(a) With respect to initial domain name registrations, Registry Operator shall provide
each ICANN accredited registrar that has executed the registry-registrar agreement for the TLD advance written notice of any fee increase (including as the result of the elimination of any refunds, rebates, discounts, product tying or other programs which had the effect of reducing the fee charged to registrars, unless such refunds, rebates, discounts, product tying or other programs are of a limited duration that is clearly and conspicuously disclosed to the registrar when offered) in no less than thirty (30) calendar days. Registry Operator shall offer registrars the option to obtain initial domain name registrations for periods of one to ten years at the discretion of the registrar.
(b) With respect to the renewal of domain name registrations, Registry Operator shall provide each ICANN accredited registrar that has executed the registry-registrar agreement for the TLD advance written notice of any fee increase (including the result of the elimination of any refunds, rebates, discounts, product tying, Qualified Marketing Programs or other programs which had the effect of reducing the fee charged to registrars) of no less than one hundred eighty (180) calendar days. Notwithstanding the foregoing sentence, with respect to renewal of domain name registrations: (i)Registry Operator only needs to provide thirty (30) calendar days notice of any fee increase if the resulting fee is less than or equal to (A) the period beginning on the Effective Date and ending twelve (12) months following the Effective Date, the initial fee charged for registrations in the TLD, or (B) for
subsequent periods, a fee which the Registry Operator provided a notice pursuant to the first sentence of this Section 2.10(b) within the twelve (12) month period preceding the effective date of the proposed fee increase; and (ii) Registry Operator need not provide notice of any fee increase for the imposition of the Variable Registry-Level Fee set forth in Section 6.3. Registry Operator shall offer registrars the option to obtain domain name registration renewals at the current fee (i.e. the fee in place prior to any noticed increase) for periods of one to ten years at the discretion of the registrar.

(c) In addition, Registry Operator must have uniform fees for renewals of domain name registrations (“Renewal Fees”). For the purposes of determining Renewal Fees, the fees for each domain registration renewal must be identical to the fee of all other domain name registration renewals in place at the time of such renewal, and such fee must take into account universal application of any refunds, rebates, discounts, product tying or other programs in place at the time of renewal. The foregoing requirements of the Section 2.10(c) shall not apply for (i) purposes of determining Renewal Fees if the registrar has provided Registry Operator with documentation that demonstrates that the applicable registrant expressly agreed in its registration agreement with registrar to higher Renewal Fees at the time of the initial registration of the domain name following clear and conspicuous disclosure of such Renewal Fees to such a registrant, and (ii) discounted Renewal Fees pursuant to a Qualified Marketing Program (as defined below). The parties acknowledge that the purpose of this Section 2.10(c) is to prohibit abusive and⁄or discriminatory Renewal Fees practices imposed by Registry Operator without the written consent of the applicable registrant at the time of the initial registration of the domain and this Section 2.10 (c) will be interpreted broadly to prohibit such practices. For purposes of this Section 2.10(c), a “Qualified Marketing Program” is a marketing program pursuant to which Registry Operator offers discounted Renewal Fees, provided that each of the following criteria is satisfied: (i) the program and related discounts are offered for a period of time which will not exceed one hundred eighty (180) calendar days (with consecutive substantially similar programs aggregated for purposes of determining the number of calendar days of the program), (ii) all ICANN accredited registrars are provided the same opportunity to qualify for such discounted Renewal Fees; and (iii) the intent or effect of the program is not to exclude any particular class(es) of registrations (e.g., registrations held by large corporations) or to increase the renewal fee of any particular class(es) of registrations. Nothing in this Section 2.10(c) shall limit Registry Operator’s obligations pursuant to Section 2.10(b).
(d) Registry Operator shall provide public query-based DNS lookup service for the TLD (that is, operate the Registry TLD zone servers) at its sole expense.

Attachments are not displayed on this form.

Reserved names
As the registration eligibility of the new gTLD proposed by dot DOOSAN is limited to DOOSAN Corporation, DOOSAN group and its affiliates, it is predicted that the registered character strings will also be related to DOOSAN. 

Therefore designation of reserved names for prevention for abusive registrations and other activities that have a negative impact on Internet users will be minimum.

DOOSAN Corporation limits the New gTLD domain name registration composed of the following characters at the least. The list may be updated when ICANN or GAC requires addition of limited character strings or issued character string of Korea of the times.

1.	The two-character string.
2.	Reserved names specified by ICANN.
3.	The abbreviations (in English) of all country and territory names contained on the ISO 3166-1 list.
4.	The United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardization of Geographical Names, Part III Names of Countries of the World.
5.	The list of United Nations member states in all 6 official United Nations languages.
6.	Characters undermining public moral and public interest of Republic of Korea.

Character strings that are limited is listed detail in the attached document.


Reserve release
If the limited character strings fall under the following items, limit clearance can be suggested to ICANN or release reserved names on the basis of Standard Korean Language Dictionary provided by the National Institute of the Korean Language:

1.	limited string character related to trademarks recognized worldwide.
2.	limited string character related to products recognized worldwide.
3.	limited string character related to brands recognized worldwide.
4.	limited string character related to improvement of public interest of Republic of Korea.
5.	other cases in which an individual or company has right to limited string characters.

1. Overview
In order for registry service to take place stably, core factors are as the following.

- Stable reception of data related to domain registration from registrar
- Periodic distribution of TLD Zone data based on registered domain information
- Distribution and service of domain registration and relevant information (Whois)
- IDN service if necessary
- DNSSEC security service

To this, brief explanation will be given in order of SRS & EPP, DNS, Whois, IDN and DNSSEC.

2. SRS & EPP
DOOSAN CORPORATION entrusts registry system operation of gTLD dot DOOSAN(“.DOOSAN”) to Korean ccTLD operation agency Korea Internet & Security Agency (ʺKISAʺ). DOOSAN CORPORATION expects to reduce load on initial operation and minimize errors as KISA, an agency that is successfully operating 1.3 million domain names, is already equipped of dot KR(“.KR”) and dot 한국(“.한국”, IDN ccTLD)ʹs domain registry system.

Leveraging expertise gained from operating the Korean ccTLD, KISA’s services will speed up resolution times, increase reliability, enhance security, protect information, and provide stability to dot KR(“.KR”) and dot 한국(“.한국”, IDN ccTLD). These services include core functions such as conformance to registry-registrar models and protocols, zone file generation and distribution, billing and collection, data escrow and backups, publicly accessible WHOIS service, technical and customer support, and redundant physical locations.

KISA has an experienced technology management team leading an expert staff of technical support, customer service, and product management specialists who assist registrars and registrants every day of the year. This disciplined team has created well-defined processes which allow them to avoid emergencies and quickly address issues as they arise.
KISA has already established a comprehensive plan to operate dot DOOSAN(ʺ.DOOSANʺ) gTLD. This is technology and know-how gained by operating Korean ccTLD, and it includes DNS, continuous service of WHOIS, as well as EPP communication process.

The Main Center of KISA is operated and maintained by Telecommunication grade. Server and network equipments are all composed of dual system, while backup center is installed in KT (Korea Telecom)ʹs data center, geographically apart, allowing real time backup.
The Networks of Main Center are composed of dual structure. The outer Networks connected to the two Routers consist of one with 45Mbps and one with 1Gbps. The two networks connected to each Router pass through Firewall and Switch to connect to the inner system. The two outer networks work simultaneously as ʺActive-Activeʺ state, and one will take charge over the other when there is a problem with one.

The inner system of KISAʹs Main Center is composed of dual system, just like the outer system is.; EPP Gateway Server, Application Server, Domain Application Server, Database Server all are by two sets. Each set of systems is in ʺActive-Activeʺ state, meaning both sides will work in normal occasions, and one side will process all work if there is a problem.
Backup Center is installed in Data Center, which is geographically apart. Two sets of systems in Main Center are operated in ʺActive-Activeʺ state, and the System of Backup Center, which only has one set, can be backed up real time.

Main Center and Backup Center are connected by VPN (Virtual Private Network). Connected to VPN, all backup data is sent safely real time through encrypted channel. If there is a problem to SRS of both two sets of Main Center, tasks can be processed normally through Backup System.
The two sets of SRS system on Main Center and the one set system of Backup Center are maintained in Active state, enabling real time synchronization.

Firewall is set so that only the permitted IP Address of a registrar may access SRS system. Only those agencies verified by Registry-Registrar Agreement (RRA) may access SRS (EPP) system.
As of March 2012, usage of network and each systems is below 30% while KISAʹs dot KR (.KR) and dot 한국(.한국) owns and provides service to about 1.3 million domains.
Dot DOOSAN(“.DOOSAN”) gTLD will be operated in the same system, and it expects registration of about 1,200 domain names within the first three years of service. As it does not excess the system capacity of KISA, no additional installation of network or system is required for the operation.

3. File Distribution to TLD Zone
DNS Service is one of the core functions of the Registry. Just like the other services, DNS service of dot DOOSAN(“.DOOSAN”) gTLD uses KISAʹs system. KISA has global service system established with 8 name server sites in Korea and 6 name server sites located in each continent. DDoS Protection Machine that can detect and block DDoS attack is installed in DNS site. Of the overseas DNS sites, DDoS Protection Machine is installed in Germany and Singapore, and other sites are planned have the machine installed in 2014.

DNS is composed of three stages: zone file generation that makes the necessary information domain database; publication that writes generated data to Master DNS Server; distribution of zone file to the name servers that users have access to.

Zone File Distribution ⁄ Update
The system updates zone file every one hour. Database in zone file distribution server is replicated continuously to zone update database in each name server through secure channel. Update package is sent together with checksum and serial number that is compressed and encrypted, so that data integrity and confidentiality can be verified.

Whenever name server is updated, checksum and serial number are compared to the final state of zone file to verify that zone file in registry system matches that of name server. When checksum discovers error, it sends request to registry system to replicate full zone file to name server. Update process means that full zone file will never be redistributed. However, these features must be provided to restore zone data from unexpected event. If situations in which these features are required come, it can result in delay of zone file update distribution. Figure 35-3(Article 35) shows which flows allow each name server to update name server of zone update database.

KISAʹs currently operated DNS system is expected to service DOOSAN CORPORATIONʹs new gTLD as well. DOOSAN CORPORATION expects number of registered domain in the first three years to be below 1,800. As this is less than 0.2% ratio when compared to KISAʹs currently running 1.3 million domain names of dot KR & dot 한국(IDN), it is expected that there will not be heavy load to KISAʹs system.

System usage and details of 14 DNS sites operated by KISA are continuously monitored, and System specification, Network Bandwidth, IP Address (IPv4, IPv6) of 14 DNS site systems including Backup site are managed.

4. Whois
Whois Service refers to providing of information such as domain name registrant and expiration date by checking the registered domain nameʹs information. Service is provided by extracting and processing data from inner database of SRS and storing it in data repository of Whois server.

- Realization of Real time Whois Information Update function
- Construction of Centralized Whois Data Repository
- Construction and realization of Whois data and service delegation through Standard 43 port
- Realization of Publication function for Whois Information Delegation
- Realization of Whois access Web Service for Internet users
- Construction and realization of Hierarchical system for the stability of Whois service.
- Security function for Whois Information Distribution

For both Web and Port 43, Whois service provides result by instantly searching Whois System DB when service user does a query. Thus there is no separate synchronization mechanism of Whois Server. Data extracted from SRS DB for Whois search is also applied real time to Whois Distributor when there is any change.
As well, prevention of Whois information abuse is being prepared, and details of this is written in Article 26.

5. IDN (Internationalized Domain Names)
DOOSAN CORPORATION will try to minimize problems that may occur from IDN requirements, procedures and usage. For the operation of IDN, DOOSAN CORPORATION complies to RFC Standards by IETF. (RFC 5890, RFC 5891, RFC 5892, RFC 5893, RFC 5894)

Registrant submits registration application through the registrar for a desired IDN. Once registrar sends IDN registration application to the registry, registry determines if the IDN is composed of characters appropriate to DOOSAN CORPORATIONʹs registry policy. Then, according to RFC 5891, U-Label is converted to A-Label through Punycode Conversion and then the A-Label is stored in registry DB.

Registry generates and applies a Zone file in DNS server with a domain name converted to A-Label as states above. In accordance with IETFʹs IDNA standard, each application will convert IDNʹs U-Label to A-Label and query DNS. For this query, dot DOOSAN(ʺ.DOOSANʺ) DNS server will respond IP address of the A-Label.

DOOSAN CORPORATION plans to entrust operation to KISA, which currently operates approximately 350 thousand IDN, share IDN character policy, monitoring measures, problem minimization policy for IDN operation.
In accordance to DOOSAN CORPORATIONʹs registration policy, domain names that only consist of the following characters are allowed for registration.
Domain name must be composed as a combination of a complete Hangul Syllable [11,172 characters], alphabet [A-Z],[a-z], numbers [0-9] and hyphen [-].
Domain name of A-Label should be between 3 and 63 characters. If Hangul is included, it should be between 1 and 17.
Domain name must not start or end with a hyphen, and there cannot be two consecutive hyphens as the third and the fourth character.
Hangul Syllable is a table of characters permitted by RFC 5892, and it refers to 11,172 characters that modern Koreans use, which is the same as the range of IDN character permitted by KISA.

DOOSAN CORPORATION shares IDN registration policy and operation problems with KISA and KISA investigates domains that violate registration policy and name server configuration error. Through these kinds of research and analysis by KISA, potential problems of IDN operation can be shared between DOOSAN CORPORATION and KISA and applied to IDN policy.

Through a discussion with IETFʹs IDNAbis Working Group, Hangul characters other than Hangul Syllable were excluded from permitted characters as IDN to prevent Hangulʹs Spoofing attack. Therefore, by limiting characters permitted as IDN to Hangul Syllable only, DOOSAN CORPORATION prevents attacks that use similarity of Hangul.
By blocking IDN registration of usage of character other than Hangul, DOOSAN CORPORATION prevents problems that can be caused by other character IDN. Since Hangul is a phonogram, there is no other character of same shape. And since Hangul is not an ideogram like Chinese Characters are, there is no phenomenon of having characters of same meaning and different shape.

6. DNSSEC
KISA, which operates dot DOOSANʹs system, has continuous DNSSEC research and experience on DNSSEC application and operation on dot KR domain. By following KISAʹs DNSSEC management policy regarding dot DOOSANʹs DNSSEC application and operation, DOOSAN CORPORATION seeks to minimize errors and faults caused by inexperience in initial operation of DNSSEC.
In order to effectively perform DNSSEC application and operation, KISA has DNSSEC system administrator, DNSSEC system manager, and other personnel.

Public Key Pairs are required for adoption of DNSSEC, and it is divided and managed into ʺKey Signing Key, KSKʺ and ʺZone Signing Key, ZSKʺ depending on the subject of signature. ZSK is used when signing record data within the domain zone file. KSK is a key that only signs DNSKEY record of the domain zone data that contains the domainʹs public key.
KSK is designed to securely join domain zone and domain security system of internet, and to strengthen domain zoneʹs security it is preferable to have KSK greatest size possible. However, if ZSK is too big, computing resource usage increases for the encryption.
Therefore, KSK is set 2,048 bits and ZSK is set 1,024 bits. Instead, there will be frequent update in principle with a period of about three months.

As well, to determine any falsification of domain information history of zone, zone is signed with NSEC3 method which hash encrypts the domain name. Signatures will be signed in OPT-OUT method to minimize the load caused; meaning each domain name in the zone will selectively adopt DNSSEC. Encryption algorithm used is NSEC3-RSASHA1, and the directory is created and managed separately from DNSSEC key storage directory.
DNSSEC key storage directory is created and managed separately from directories each zone is located in. Currently, KISA already operates approximately 1.3 million domain names collaboration with registrars, and it will have no problem even if dot DOOSAN(ʺ.DOOSANʺ) applies for maintenance of 1,800 domain names.

Personal data security, facility security, network information security, disaster recovery management, etc are operated under ʺInternet Address Main Center Information Security policyʺ
When Delegation Signer Resource Record (DSRR) is altered by change in KSK of dot DOOSAN(ʺ.DOOSANʺ) zone, domain delegation modification application will be submitted to IANA so that modifications can be applied.
For continuous DNS operation and stable DNSSEC operation, there is continuous comprehension on current condition and report is written on a regular basis.

DOOSAN CORPORATION entrusts operation of registry system for gTLD dot DOOSAN(“.DOOSAN”) to Korean ccTLD operation Korea Internet & Security Agency (ʺKISAʺ). KISA, an agency successfully operating about 1.3 million domain names, is predicted to reduce the burden of initial operation of dot DOOSAN(ʺ.DOOSANʺ) gTLD and minimize errors as it is already equipped of dot KR(“.KR”) & dot 한국(“.한국”, IDN ccTLD) domain registry systems such as SRS, DNS and Whois.

Figure [24-1] SRS Conceptual Diagram

Leveraging expertise gained from operating the Korean ccTLD, KISA’s services will speed up resolution times, while increasing reliability, enhancing security, protecting information and providing stability to dot KR and dot 한국. These services include core functions such as conformance to registry-registrar models and protocols, zone file generation and distribution, billing and collection, data escrow and backups, publicly accessible WHOIS service, technical and customer support, and redundant physical locations.

KISA has an experienced technology management team leading an expert staff of technical support, customer service, and product management specialists who assist registrars and registrants every day of the year. This disciplined team has created well-defined processes which allow it to avoid emergencies and quickly address issues as they arise.
KISA has already established a comprehensive plan to operate dot DOOSAN(ʺ.DOOSANʺ) gTLD. This is technology and know-how gained by operating Korean ccTLD, and it includes DNS, continuous service of WHOIS, as well as EPP communication process.

The main center of KISA is operated and maintained by Telecommunication grade. Server of the main center and network equipments are all composed of dual system, while backup center is installed in KT(Korea Telecom)ʹs data center, geographically apart, allowing real-time backup.

Main function categories are as the following:
1) Web Server: High capacity Web Servers provide secure Web services and information dissemination. It contains a registry home page to enable registrars to sign in and inquire about their account status, obtain downloads and whitepapers, access frequently asked questions, obtain self help support, or submit a trouble ticket to the TLD Registry Help Desk.

2) Secure Web Provisioning Interface: High capacity web servers provide a secure interface for the delegated managers and registrants in the locality space to provision registration data. Delegated managers will be provided with authenticity information that they will need to input to access their account information. Registrants that utilize it as a registrar will be provided with similar authenticity information for their registrations. This is to ensure that only that registrant can modify the registration.

3) EPP Servers: EPP transactions received from registrars undergo front-end processing by the EPP server that manages the EPP session level dialog, performs session level security processing, and strips out transaction records. These EPP transaction records are sent to SRS application server cluster for security authentication and business logic processing.

4) Application Servers: Application Servers process business logic, user authentication, posting of inserts, deletes, and updates to the master database. As well, they process interfaces to authentication, billing, backup, and system⁄network administration.

5) Centralized dot DOOSAN(ʺ.DOOSANʺ) gTLD Database Servers: The Centralized dot DOOSAN(ʺ.DOOSANʺ) gTLD database maintains registry data in a multi-threaded, multi-session database for building data-driven publishing and subscribes event notifications and replication to downstream data marts such as the Whois, Zone, and Billing.

6) Whois Distribution Database: The Whois Distribution Database is dynamically updated from the Centralized dot DOOSAN(ʺ.DOOSANʺ) gTLD database and propagates the information to the Whois Database clusters.

7) Whois Database Clusters: The Whois Database is dynamically updated from the Whois Distribution Database and sits behind the Whois Server clusters. The Whois Database clusters are used to look up records that are not cached by the Whois Servers.

8) Whois Servers: The Load Balanced Whois Server Clusters receive a high volume of queries from Registrants and Internet users. The Whois service returns information about Registrars, domain names, nameservers, IP addresses, and the associated contacts Registry only holds main information about domain, and other information such as contact information is provided by registrarʹs Whois site according to the contract between registry and registrar.

9) Whois Distribution Database: The Distribution Database is dynamically updated from the Centralized dot DOOSAN(ʺ.DOOSANʺ) gTLD database and propagates the information to the Database clusters.

10) Whois Database Clusters: The Database is dynamically updated from the Distribution Database and sits behind the Server clusters. The Database clusters are used to look up records that are not cached by the Servers.

11) Zone Distribution Database: The Zone Distribution Database is dynamically updated from the registry Centralized dot DOOSAN(ʺ.DOOSANʺ) gTLD database and propagated to the nameserver sites located worldwide. It contains domain names, their associated nameserver names, and the IP addresses for those nameservers.

12) Billing and Collection: A commercial off-the-shelf system is customized for registry specific eCommerce billing functions that are integrated with transaction processing, the master database and a secure Web server. The system maintains each registrar’s account information by domain name and provides status reports on demand.

13) Authentication Services: Authentication Service uses commercial X.509 certificates and is used to authenticate the identity of entities interacting with the SRS.

14) Backup Server: Provides a backup and restore of each of the various cluster servers and database servers files and provides a shared library facility for central backup and recovery.

15) Systems⁄Network Management Console: Provides system administration and simple network management protocol (SNMP) monitoring of the network, LAN-based servers, cluster servers, network components, and key enterprise applications including the EPP, Web, Whois, Zone, Billing, Backup⁄Restore, and database application. Provides threshold and fault event notification and collects performance statistics.

16) Building LAN: Provides dual redundant switched Gigabit Ethernet LAN-based connectivity for all network devices in the data center. Firewall protects the building LAN from the in secure Internet via a Firewall that provides policy-based IP filtering and network-based intrusion detection services to protect the system from Internet hacking and denial of service attacks.

17) Load Balancers: Load balancing of TCP⁄IP traffic is based in a server cluster including common protocols such as least connections, weighted least connections, round robin, and weighted round robin.
Composition of KISAʹs Registry Main Center is shown in Figure 24-2.

Figure [24-2] Registry Main Center Network Diagram

The networks of Main Center are composed of dual structure. The outer networks connected to the two Routers consist of one with 45Mbps and one with 1Gbps. The two networks connected to each Router pass through Firewall and Switch to connect to the inner system. The two outer networks work simultaneously as ʺActive-Activeʺ state, and one will take charge over the other when there is a problem with one.

Composition of inner SRS system connected from Switch is shown in Figure 24-3.

Figure [24-3] SRS Main Center System Architecture

Composition of Backup Center is shown in Figure 24-4.

Figure [24-4] Main Center & Backup Center

Main Center and Backup Center are connected by VPN (Virtual Private Network). All backup data is sent safely real time through encrypted channel. If there is a problem to SRS of both two sets of Main Center, tasks can be processed normally through Backup System.
The two sets of SRS system on Main Center and the one set system of Backup Center are maintained in Active state, enabling real time synchronization.

As of March 2012, usage of network and each systems is below 30% while KISAʹs dot KR (.KR) and Dot 한국(.한국) owns and provides service to about 1.3 million domain names. Dot DOOSAN(“.DOOSAN”) gTLD will be operated in the same system, and it expects registration of about 1,800 domain names within the first three years of service. As it does not excess the system capacity of KISA, no additional installation of network or system is required for the operation.

SRS system management is divided into EPP, Application, and Database management

〈EPP Operation Management〉
- 1 person
- EPP Operation Policy, Supervisor of SRS Management
- over 7 years experiences

〈EPP Operation〉
- 2 persons
- EPP Program Development
- EPP Monitoring & Maintenance
- over 20 years experiences, over 10 years experiences

〈Database〉
- 2 persons
- DBA (Domain Registration DB)
- over 7 years experiences, over 3 years experiences

SRS system can be largely divided into EPP Gateway Server, Application Server, and Database Server. Each of the systems is as following:
1) EPP Gateway 1
Location : KISA Main Center, Seoul, Korea
System : Oracle X4150
CPUs : 2.16GHz × 1
Memory(MB) : 16GB
Total Storage(GB) : 584GB
Usage of CPU : 9.28%
Usage of Memory : 25%

2) EPP Gateway 2
Location : KISA Main Center, Seoul, Korea
System : Oracle X4150
CPUs : 2.16GHz × 1
Memory(MB) : 16GB
Total Storage(GB) : 584GB
Usage of CPU : 5.40%
Usage of Memory : 13%

3) EPP Gateway 3 (Backup)
Location : KISA Backup Center, Seongnam, Korea
System : Dell R810
CPUs : 2.66Ghz × 2
Memory(MB) : 64GB
Total Storage(GB) : -
Usage of CPU : -
Usage of Memory : -

4) Application Server 1
Location : KISA Main Center, Seoul, Korea
System : Oracle V480
CPUs : 1GHz × 1
Memory(MB) : 4GB
Total Storage(GB) : 73GB
Usage of CPU : 1.83%
Usage of Memory : 33%

5) Application Server 2
Location : KISA Main Center, Seoul, Korea
System : Oracle V480
CPUs : 1GHz × 1
Memory(MB) : 4GB
Total Storage(GB) : 73GB
Usage of CPU : 0.74%
Usage of Memory : 33%

6) Application Server 3 (Backup)
Location : KISA Backup Center, Seongnam, Korea
System : Dell R810
CPUs : 2.66Ghz × 2
Memory(MB) : 64GB
Total Storage(GB) : -
Usage of CPU : -
Usage of Memory : -

7) Database Server 1
Location : KISA Main Center, Seoul, Korea
System : Oracle M4000
CPUs : 2.15Ghz × 2
Memory(MB) : 16GB
Total Storage(GB) : 250GB
Usage of CPU : 4.05%
Usage of Memory : 70%

8) Database Server 2
Location : KISA Main Center, Seoul, Korea
System : Oracle M4000
CPUs : 2.15Ghz × 2
Memory(MB) : 16GB
Total Storage(GB) : 250GB
Usage of CPU : 4.05%
Usage of Memory : 64%

9) Database Server 3 (Backup)
Location : KISA Backup Center, Seongnam, Korea
System : Dell R810
CPUs : 2.66Ghz × 2
Memory(MB) : 64GB
Total Storage(GB) : -
Usage of CPU : -
Usage of Memory : -

Dot DOOSAN(“.DOOSAN”) gTLD entrusts the operation of registry system to Korean ccTLD operation agency Korea Internet & Security Agency(“KISA”).

KISA, which will operate dot DOOSAN(“.DOOSAN”) Registry, has already been using EPP for processing business with Registrar. Through encrypted SSL Channel, it communicates EPP message with 31 registrars for dot KR (.KR). Thus, dot DOOSAN(ʺ.DOOSANʺ) gTLD will be processing domain registration and other tasks utilizing EPP under the same environment.

The system that receives EPP message from the most front-end of Registry Site is EPP Gateway Server. EPP Gateway Server parses EPP message, validates it, and sends over the message to Application Server for process if there is no problem detected.

Mechanism for EPP Process is as the following.

1. EPP Gateway Server
EPP Gateway Server sends the Registrarʹs Request Message to Application Server and sends back the Response Message to the Registrar. As well, it receives domain registration administration request from Registrar System, performing Front-End Processing.

Figure [25-1] EPP Processing Conceptual Diagram

2. Functions

Implementation of EPP Protocol
- Support of XML Base Application Layer Protocol
- Definition of component for each business area and realization of object mapping using class template technology
- Configuration Management using XML Schema Technology

Security Function for Internet Communication
- Registrar Authentication performance utilizing X.509 Certificate
- Secures confidentiality through Public Key Algorithm and conventional encryption system
- Ensures data integrity using MAC (message authentication code) with Hash algorithm
- Provides non-repudiation using Digital Signing Mechanism
- Ensures Communication Channel Security by application of SSL (Secure Socket Layer) Protocol
- Registry sets firewall settings so that only the authorized IP addresses of registrar may access SRS system

Session Management
- Common Information Loading of Registrar
- Transaction Information Management of Registrar
- Synchronize Request – Response Message between Registrar and Application Server
- Error Management of Communication Level
- Error Management of Application Transaction Level

Cooperation with other component service of registry system
- Implementation of IPC Communication
- Implementation of TCP Socket Connection function suing SSL

Personnel for EPP operation is included under article 24ʹs SRS operation management plan, EPP operation personnel are as the following:

〈EPP Operation Management〉
- 1 person
- EPP Operation Policy, Supervisor of SRS Management
- Over 7 years experiences

〈 EPP Operation〉
- EPP Program Development & Maintenance
- Over 20 years experiences, Over 10 years experiences

Details for Proprietary EPP Extensions are as the following:

Proprietary EPP Extensions are as the following;

[Example Code] 〈domain:check〉 command

〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ standalone=ʺnoʺ?〉
〈epp xmlns=ʺurn:ietf:params:xml:ns:epp-1.0ʺ〉
〈command〉
〈check〉
〈domain:check xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ〉
〈domain:name〉example.com〈⁄domain:name〉
〈domain:name〉example.net〈⁄domain:name〉
〈domain:name〉example.org〈⁄domain:name〉
〈⁄domain:check〉
〈⁄check〉
〈clTRID〉ABC-12345〈⁄clTRID〉
〈⁄command〉
〈⁄epp〉

3. List of all commands
1) Domain Commands
〈domain:check〉
It is used to determine if an object can be provisioned within a repository.

〈domain:info〉
It is used to retrieve information associated, with a domain object.

〈domain:create〉
It provides a transform operation that allows a client to create a domain object.

〈domain:renew〉
It provides a transform operation that allows a client to extend the validity period of a domain object.

〈domain:update〉
It provides a transform operation that allows a client to modify the attributes of a domain object.
extension 〈rgp:restore op=”request”〉
extension 〈rgp:restore op=”report”〉
extension 〈sync:update〉
- It allow registrants, through their current registrar, to set a specific expiration date for all of their domain name registration periods.

〈domain:delete〉
It provides a transform operation that allows a client to delete a domain object.

〈domain:transfer op=”query”〉
It provides a query operation that allows a client to determine the real-time status of pending and completed transfer requests.

〈domain:transfer op=”request”〉
It provides a transform operation that allows a client to manage requests to transfer the sponsorship of a domain object.
〈domain:transfer op=”approve”〉
〈domain:transfer op=”reject”〉
〈domain:transfer op=”cancle”〉

2) Host Commands
〈host:check〉
It is used to determine if an object can be provisioned within a repository.

〈host:info〉
It is used to retrieve information associated with a host object.

〈host:create〉
It provides a transform operation that allows a client to create a host object.

〈host:delete〉
It provides a transform operation that allows a client to delete a host object.

〈host:update〉
It provides a transform operation that allows a client to modify the attributes of a host object.

3) Poll Commands
〈poll:op=”req〉
〈poll:op=”ack”〉
The EPP 〈poll〉 command is used to discover and retrieve service messages queued by a server for individual clients.

4) Session Commands
〈hello〉
Use of this element is essential in a connection-less environment where a server cannot return a 〈greeting〉 in response to a client-initiated connection.

〈login〉
It is used to establish a session with an EPP server in response to a greeting issued by the server.

〈logout〉
It is used to end a session with an EPP server.

4. Specifications of commands

1) 〈domain:check〉 - 〈check〉 command is used to determine if an object can be provisioned within a repository.

〈domain:check〉 Request Elements

Domain Name
〈domain:name〉
- elements that contain the fully qualified names of the domain objects to be queried.
one or more

client Transaction ID
〈clTRID〉
- element that MAY be used to uniquely identify the command to the client.

2) 〈domain:check〉 Response Elements
Domain:Check Response

Result code
〈result〉
- code
- value is a four-digit, decimal number that describes the success or failure of the command.

Result message
〈msg〉
- lang(option)
- element containing a human-readable description of the response code.

Domain Name
〈domain:name〉
- avail :
1 or true : can be rovisioned
0 or false : can not be provisioned
- The fully qualified name of the queried domain object.

Reason
〈domain:reason〉
- lang (Option)
Option
- This element that MAY be provided when an object cannot be provisioned.

Client Transaction ID
〈clTRID〉

Server Transaction ID
〈svTRID〉
- The transaction identifier is formed using the 〈clTRID〉 associated with the command if supplied by the client and a 〈svTRID〉 (server transaction identifier) that is assigned by and unique to the server.

3) 〈domain:info〉
〈info〉 command is used to retrieve information associated with a domain object.

〈domain:info〉 Request Elements

Domain Name
〈domain:name〉
hosts (option)
all : subordinate and delegated.
del : delegated.
sub : subordinate

Password
〈domain:pw〉
roid (option)*
option
- An OPTIONAL ʺroidʺ attribute MUST be used to identify the registrant or contact object if and only if the given authInfo is associated with a registrant or contact object, and not the domain object itself.

client Transaction ID
〈clTRID〉
- element that MAY be used to uniquely identify the command to the client.

4) 〈domain:info〉 Response Elements
〈result〉
- code
- value is a four-digit, decimal number that describes the success or failure of the command.

〈msg〉
- lang(option)
- element containing a human-readable description of the response code.

〈domain:name〉
- The fully qualified name of the queried domain object.

〈domain:roid〉
- the Repository Object IDentifier assigned to the domain object when the object was created.

〈domain:status〉
s*
Option
- elements that contain the current status descriptors associated with the domain.
zero or more

〈domain:hostObj〉
Option
- element that contains the fully qualified names of the delegated host objects or host attributes (name servers) associated with the domain object.
one or more

〈domain:host〉
Option
- elements that contain the fully qualified names of the subordinate host objects that exist under this superordinate domain object.
zero or more

〈domain:clID〉
- element that contains the identifier of the sponsoring client.

〈domain:crID〉
Option
- element that contains the identifier of the client that created the domain object.

〈domain:crDate〉
Option
- element that contains the date and time of domain object creation.

〈domain:exDate〉
Option
- element that contains the date and time identifying the end of the domain objectʹs registration period.

〈domain:upID〉
Option
- element that contains the identifier of the client that last updated the domain object.

〈domain:update〉
Option
- element that contains the date and time of the most recent domain-object modification.

〈domain:trDate〉
Option
- element that contains the date and time of the most recent successful domain-object transfer.

〈domain:pw〉
Option
- element that contains authorization information associated with the domain object.

〈secDNS:keyTag〉
Option
(dsData)
- The Key Tag field lists the key tag of the DNSKEY RR referred to by the DS record, in network byte order.

〈secDNS:alg〉
Option(dsData)
- The Algorithm field lists the algorithm number of the DNSKEY RR referred to by the DS record.

〈secDNS:disgestType〉
Option(dsData)
- The Digest Type field identifies the algorithm used to construct the digest.

〈secDNS:digest〉
Option(dsData)
- The digest is calculated by concatenating the canonical form of the fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA, and then applying the digest algorithm.

〈secDNS:maxSigLife〉
Option (dsData)

〈secDNS:flags〉
Option
(keyData)
- Bit 7 of the Flags field is the Zone Key flag.

〈secDNS:protocol〉
Option
(keyData)
- The Protocol Field MUST have value 3, and the DNSKEY RR MUST be treated as invalid during signature verification if it is found to be some value other than 3.

〈secDNS:alg〉
Option
(keyData)
- The Algorithm field identifies the public keyʹs cryptographic algorithm and determines the format of the Public Key field.

〈secDNS:pubkey〉
Option
(keyData)
- The Public Key Field holds the public key material.

〈rgp:rgpStatus〉
s*
- element that contains a single attribute ʺsʺ whose value describes the current grace period status of the domain.

〈clTRID〉
- The transaction identifier is formed using the 〈clTRID〉 associated with the command if supplied by the client and a 〈svTRID〉 (server transaction identifier) that is assigned by and unique to the server.

〈svTRID〉
- The transaction identifier is formed using the 〈clTRID〉 associated with the command if supplied by the client and a 〈svTRID〉 (server transaction identifier) that is assigned by and unique to the server.

5) 〈domain:transfer op=”query”〉
〈transfer〉 command provides a query operation that allows a client to determine the real-time status of pending and completed transfer requests.

〈domain:transfer op=”query”〉 Request Elements

〈domain:name〉

〈domain:pw〉
roid (option)*
option
- An OPTIONAL ʺroidʺ attribute MUST be used to identify the registrant or contact object if and only if the given authInfo is associated with a registrant or contact object, and not the domain object itself.

〈clTRID〉
- element that MAY be used to uniquely identify the command to the client.

6) 〈transfer op=”query”〉 Response

〈result〉
- code
- value is a four-digit, decimal number that describes the success or failure of the command.

〈msg〉
- lang(option)
- element containing a human-readable description of the response code.

〈domain:name〉
- The fully qualified name of the queried domain object.

〈domain:trStatus〉
- element that contains the state of the most recent transfer request.

〈domain:reID〉
- element that contains the identifier of the client that requested the object transfer..

〈domain:reDate〉
- element that contains the date and time that the transfer was requested.

〈domain:acID〉
- element that contains the identifier of the client that SHOULD act upon a PENDING transfer request..

〈domain:acDate〉
- element that contains the date and time of a
required or completed response.
For a PENDING request, the value identifies the date and time by which a response is required before an automated response action will be taken by the server. For all other status types, the value identifies the date and time when the request was completed.

〈domain:extDate〉
Option
- element that contains the end of the domain objectʹs validity period

7) 〈domain:create〉
〈create〉 command provides a transform operation that allows a client to create a domain object.

〈domain:create〉 Request Elements

〈domain:name〉

〈domain:period〉
- unit
y: Year m: Month
Option
- element that contains the initial registration period of the domain object.

〈domain:hostObj〉
Option
- element that contains the fully qualified names of the delegated host objects or host attributes (name servers) associated with the domain object.

〈domain:pw〉

〈secDNS:keyTag〉
Option (dsData)
- The Key Tag field lists the key tag of the DNSKEY RR referred to by the DS record, in network byte order.

〈secDNS:alg〉
Option(dsData)
- The Algorithm field lists the algorithm number of the DNSKEY RR referred to by the DS record.

〈secDNS:disgestType〉
Option(dsData)
- The Digest Type field identifies the algorithm used to construct the digest.

〈secDNS:maxSigLife〉
Option(dsData)

〈secDNS:flags〉
Option(keyData)
- Bit 7 of the Flags field is the Zone Key flag.

〈secDNS:protocol〉
Option(keyData)
- The Protocol Field MUST have value 3, and the DNSKEY RR MUST be treated as invalid during signature verification if it is found to be some value other than 3.

〈secDNS:alg〉
Option(keyData)
- The Algorithm field identifies the public keyʹs cryptographic algorithm and determines the format of the Public Key field.

〈secDNS:pubkey〉
Option(keyData)
- The Public Key Field holds the public key material.

〈clTRID〉
- element that MAY be used to uniquely identify the command to the client.

8) 〈domain:create〉 Response Elements

〈result〉
- code
- value is a four-digit, decimal number that describes the success or failure of the command.

〈msg〉
- lang(option)
- element containing a human-readable description of the response code.

〈domain:name〉
- The fully qualified name of the queried domain object.

〈domain:crDate〉
- element that contains the date and time of domain object creation.

〈domain:exDate〉
Option
- element that contains the date and time identifying the end of the domain objectʹs registration period.

9) 〈domain:delete〉 Request Elements

〈domain:name〉

〈clTRID〉
- element that MAY be used to uniquely identify the command to the client.

10) 〈domain:delete〉 Response Elements

〈result〉
- code
- value is a four-digit, decimal number that describes the success or failure of the command.

〈msg〉
- lang(option)
- element containing a human-readable description of the response code.

11) 〈domain:renew〉
〈renew〉 command provides a transform operation that allows a client to extend the validity period of a domain object.

〈domain:renew〉 Request Elements

〈domain:name〉

〈domain:curExpDate〉
- element that contains the date on which the current validity period ends

〈domain:period〉
- unit
y: Year m: Month
Option
- element that contains the initial registration period of the domain object.

〈clTRID〉
- element that MAY be used to uniquely identify the command to the client.

12) 〈domain:renew〉 Response Elements

〈result〉
- code
- value is a four-digit, decimal number that describes the success or failure of the command.

〈msg〉
- lang(option)
- element containing a human-readable description of the response code.

〈domain:name〉
- The fully qualified name of the queried domain object.

〈domain:exDate〉
Option
- element that contains the date and time identifying the end of the domain objectʹs registration period.

13) 〈domain:transfer op=”request”〉
〈transfer〉 command provides a transform operation that allows a client to manage requests to transfer the sponsorship of a domain object.

〈domain:transfer op=”request”〉 Request Elements

〈domain:name〉

〈domain:period〉
- unit
y: Year m: Month
Option
- element that contains the number of units to be added to the registration period of the domain object at completion of the transfer process.

〈domain:pw〉
- roid (option) *
- An OPTIONAL ʺroidʺ attribute MUST be used to identify the registrant or contact object if and only if the given authInfo is associated with a registrant or contact object, and not the domain object itself.

〈clTRID〉
- element that MAY be used to uniquely identify the command to the client.

14) 〈domain:transfer op=”request”〉 Response Elements

〈result〉
- code
- value is a four-digit, decimal number that describes the success or failure of the command.

〈msg〉
- lang(option)
- element containing a human-readable description of the response code.

〈domain:name〉
- The fully qualified name of the queried domain object.

〈domain:trStatus〉
- element that contains the state of the most recent transfer request.

〈domain:reID〉
- element that contains the identifier of the client that requested the object transfer..

〈domain:reDate〉
- element that contains the date and time that the transfer was requested.

〈domain:acID〉
- element that contains the identifier of the client that SHOULD act upon a PENDING transfer request..

〈domain:acDate〉
- For a PENDING request, the value identifies the date and time by which a response is required before an automated response action will be taken by the server. For all other status types, the value identifies the date and time when the request was completed.

〈domain:extDate〉
Option
- element that contains the end of the domain objectʹs validity period

15) 〈domain:transfer op=”approve”〉 Request Elements

〈domain:name〉

〈domain:pw〉
- roid (option) *

〈clTRID〉
- element that MAY be used to uniquely identify the command to the client.

16) 〈domain:transfer op=”approve” Response Elements

〈result〉
- code
- value is a four-digit, decimal number that describes the success or failure of the command.

〈msg〉
- lang(option)
- element containing a human-readable description of the response code.

〈domain:name〉
- The fully qualified name of the queried domain object.

〈domain:trStatus〉
- element that contains the state of the most recent transfer request.

〈domain:reID〉
- element that contains the identifier of the client
that requested the object transfer..

〈domain:reDate〉
- element that contains the date and time that the transfer was requested.

〈domain:acID〉
- element that contains the identifier of the client that SHOULD act upon a PENDING transfer request.. For all other status types, the value identifies the client that took the indicated action.

〈domain:acDate〉
- element that contains the date and time of a required or completed response.

〈domain:extDate〉
Option
- element that contains the end of the domain objectʹs validity period

17) 〈domain:transfer op=”reject”〉 Request Elements

〈domain:name〉

〈domain:pw〉
- roid (option) *

〈clTRID〉
- element that MAY be used to uniquely identify the command to the client.

18) 〈domain:transfer op=”reject” Response Elements

〈result〉
- code
- value is a four-digit, decimal number that describes the success or failure of the command.

〈msg〉
- lang(option)
- element containing a human-readable description of the response code.

〈domain:name〉
- The fully qualified name of the queried domain object.

〈domain:trStatus〉
- element that contains the state of the most recent transfer request.

〈domain:reID〉
- element that contains the identifier of the client that requested the object transfer..

〈domain:reDate〉
- element that contains the date and time that the transfer was requested.

〈domain:acDate〉
- element that contains the date and time of a
required or completed response.

〈domain:extDate〉
Option
- element that contains the end of the domain objectʹs validity period

19) 〈domain:transfer op=”cancle”〉 Request Elements

〈domain:name〉

〈domain:pw〉
- roid (option) *

〈clTRID〉
- element that MAY be used to uniquely identify the command to the client.

20) 〈domain:transfer op=”cancle”〉 Response Elements

〈result〉
code
- value is a four-digit, decimal number that describes the success or failure of the command.

〈msg〉
- lang(option)
- element containing a human-readable description of the response code.

〈domain:name〉
- The fully qualified name of the queried domain object.

〈domain:trStatus〉
- element that contains the state of the most recent transfer request.

〈domain:reID〉
- element that contains the identifier of the client that requested the object transfer..

〈domain:reDate〉
- element that contains the date and time that the transfer was requested.

〈domain:acDate〉
- element that contains the date and time of a required or completed response.

〈domain:extDate〉
Option
- element that contains the end of the domain objectʹs validity period

21) 〈domain:update〉
〈update〉 command provides a transform operation that allows a client to modify the attributes of a domain object.

〈domain:update〉 Request Elements

〈domain:name〉

〈domain:hostObj〉
Option
- element that contains the fully qualified names of the delegated host objects or host attributes (name servers) associated with the domain object.

〈domain:status〉
- s*
- lang (option)
Option (add, rem)
- elements that contain status values to be applied to or removed from the object.
zero or more

〈domain:pw〉
Option (chg)

〈secDNS:keyTag〉
Option (ds:Data)
- The Key Tag field lists the key tag of the DNSKEY RR referred to by the DS record, in network byte order.
one or more

〈secDNS:alg〉
Option (ds:Data)
- The Algorithm field lists the algorithm number of the DNSKEY RR referred to by the DS record.

〈secDNS:disgestType〉
Option(ds:Data)
- The Digest Type field identifies the algorithm used to construct the digest.

〈secDNS:digest〉
Option (ds:Data)
- The digest is calculated by concatenating the canonical form of the fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA, and then applying the digest algorithm.

〈secDNS:maxSigLife〉
Option (ds:Data)

〈secDNS:flag〉
Option (keyData)
- Bit 7 of the Flags field is the Zone Key flag.

〈secDNS:protocol〉
Option (keyData)
- The Protocol Field MUST have value 3, and the DNSKEY RR MUST be treated as invalid during signature verification if it is found to be some value other than 3.

〈secDNS:alg〉
Option (keyData)
- The Algorithm field identifies the public keyʹs cryptographic algorithm and determines the format of the Public Key field.

〈secDNS:pubkey〉
Option (keyData)
- The Public Key Field holds the public key material.

〈clTRID〉
- element that MAY be used to uniquely identify the command to the client.

22) 〈domain:update〉 Response Elements

〈result〉
- code
- value is a four-digit, decimal number that describes the success or failure of the command.

〈msg〉
- lang(option)
- element containing a human-readable description of the response code.

23) 〈domain:update〉 extension 〈rgp:restore op=“request”〉
- The registry grace period extension modifies base update processing to support redemption of domain names for which a 〈delete〉 command has been processed, but the name has not yet been purged.

〈rgp:restore op = “request”〉 Request Elements
- 〈domain:add〉, 〈domain:rem〉, 〈domain:chg〉 - needs empty one element at least

domain:name〉

〈domain:add〉 or 〈domain:rem〉 or 〈domain:chg〉
- This requirement(element) is updated to disallow the possibility of modifying a domain object as part of redemption grace period recovery processing.

〈rgp:restore〉
- op = “request”

〈clTRID〉
- element that MAY be used to uniquely identify the command to the client.

24) 〈rgp:restore op = “request”〉 Response Elements

〈result〉
- code
- value is a four-digit, decimal number that describes the success or failure of the command.

〈msg〉
- lang(option)
- element containing a human-readable description of the response code.

〈rgp:rgpStatus〉
- s*

25) 〈rgp:restore op = “report”〉 Request Elements

〈domain:name〉

〈rgp:restore〉
- op = “report”

〈rgp:preData〉
- contains a copy of the registration data that existed for the domain name prior to the domain name being deleted.

〈rgp:postData〉
- element that contains a copy of the registration data that exists for the domain name at the time the restore report is submitted.

〈rgp:delTime〉
- element that contains the date and time when the domain name delete request was sent to the server.

〈rgp:resTime〉
- element that contains the date and time when the original 〈rgp:restore〉 command was sent to the server.

〈rgp:resReason〉
- element that contains a brief explanation of the reason for restoring the domain name.

〈rgp:statement〉
- lang(option)
- element that contains a text statement that the client has not restored the domain name in order to assume the rights to use or sell the domain name for itself or for any third party.

〈rgp:statement〉
- lang(option)
- The information in this report is true to best of this registrarʹs knowledge

〈rgp:other〉
- element that contains any information needed to support the statements provided by the client.

〈clTRID〉
- element that MAY be used to uniquely identify the command to the client.

26) 〈rgp:restore op = “report”〉 Response Elements

〈result〉
- code
- value is a four-digit, decimal number that describes the success or failure of the command.

〈msg〉
- lang(option)
- element containing a human-readable description of the response code.

27) 〈domain:update〉 extension 〈sync:update〉
This extension modifies base update processing to allow specification of a desired expiration date within one calendar year of the current date.

〈sync:update〉 Request Elements
- 〈domain:add〉, 〈domain:rem〉, 〈domain:chg〉 - needs empty one element at least

〈domain:name〉

〈domain:add ⁄〉 or 〈domain:rem ⁄〉 or 〈domain:chg ⁄〉
- This requirement(element) is updated to disallow the possibility of modifying a domain object as part of ConsoliDate processing.

〈clTRID〉
- element that MAY be used to uniquely identify the command to the client.

28) 〈sync:update〉 Response Elements

〈result〉
- code
- value is a four-digit, decimal number that describes the success or failure of the command.

〈msg〉
- lang(option)
- element containing a human-readable description of the response code.

29) 2.15. 〈host:check〉
〈check〉 command is used to determine if an object can be provisioned within a repository.

〈host:check〉 Request Elements

〈host:name〉
- 〈host:name〉 elements that contain the fully qualified names of the host objects to be queried.
one or more

〈clTRID〉
- element that MAY be used to uniquely identify the command to the client.

30) 〈host:check〉 Response Elements

〈result〉
code
- value is a four-digit, decimal number that describes the success or failure of the command.

〈msg〉
- lang(option)
- element containing a human-readable description of the response code.

〈host:name〉
- avail :
1 or true : can be provisioned
0 or false : can not be provisioned
- The fully qualified name of the queried host object.

〈host:reason〉
lang (Option)
Option
- This element that MAY be provided when an object cannot be provisioned.

31) 〈host:info〉
〈info〉 command is used to retrieve information associated with a host object.

〈host:info〉 Request Elements

〈host:name〉

〈clTRID〉
- element that MAY be used to uniquely identify the command to the client.

32) 〈host:info〉 Response Elements

〈result〉
- code
- value is a four-digit, decimal number that describes the success or failure of the command.

〈msg〉
- lang(option)
- element containing a human-readable description of the response code.

〈host:name〉
- The fully qualified name of the queried host object.

〈host:roid〉
- the Repository Object IDentifier assigned to the host object when the object was created.

〈host:status〉
s *
Option (one or more)

〈host:addr〉
- ip (v4, v6)
- elements that contain the IP addresses associated with the host object.
zero or more

〈host:clID〉
- element that contains the identifier of the sponsoring client.

〈host:crID〉
- element that contains the identifier of the client that created the host object.

〈host:crDate〉
- element that contains the date and time of host object creation.

〈host:upID〉
- element that contains the identifier of the client that last updated the domain object.

〈host:upDate〉
- element that contains the date and time of the most recent host-object modification.

〈host:trDate〉
- element that contains the date and time of the most recent successful host-object transfer.

33) 〈host:create〉
〈create〉 command provides a transform operation that allows a client to create a host object.

〈host:create〉 Request Elements

〈host:name〉

〈host:addr〉
- ip (v4, v6)
- elements that contain the IP addresses to be associated with the host.
zero or more

〈clTRID〉
- element that MAY be used to uniquely identify the command to the client.

34) 〈host:create〉 Response Elements

〈result〉
- code
- value is a four-digit, decimal number that describes the success or failure of the command.

〈msg〉
- lang(option)
- element containing a human-readable description of the response code.

〈host:name〉
- The fully qualified name of the queried host object.

〈host:crDate〉
- element that contains the date and time of host-object creation.

35) 〈host:delete〉
〈delete〉 command provides a transform operation that allows a client to delete a host object.

〈host:delete〉 Request Elements

〈host:name〉

〈clTRID〉
- element that MAY be used to uniquely identify the command to the client.

36) 〈host:delete〉 Response Elements

〈result〉
- code
- value is a four-digit, decimal number that describes the success or failure of the command.

〈msg〉
- lang(option)
- element containing a human-readable description of the response code.

37) 〈host:update〉
〈update〉 command provides a transform operation that allows a client to modify the attributes of a host object.

〈host:update〉 Request Elements

〈host:name〉

〈host:addr〉
- ip (v4, v6)
Option (add, rem)
- elements that contain IP addresses to be associated with or removed from the host object.
one or more

〈host:status〉
- s*
- lang (option)
Option (add, rem)
- elements that contain status values to be applied to or removed from the object.
one or more

〈host:name〉
Option (chg)

〈clTRID〉
- element that MAY be used to uniquely identify the command to the client.

38) 〈host:update〉 Response Elements

〈result〉
- code
- value is a four-digit, decimal number that describes the success or failure of the command.

〈msg〉
- lang(option)
- element containing a human-readable description of the response code.

39) 〈poll op = “req”〉
〈poll〉 command is used to discover and retrieve service messages queued by a server for individual clients.

〈poll op = “req”〉 Request Elements

〈poll〉
- op (req, ack)

〈clTRID〉
- element that MAY be used to uniquely identify the command to the client.

40) 〈poll op=”req”〉 Response Elements

Transfer Poll Response Elements

〈result〉
- code
- value is a four-digit, decimal number that describes the success or failure of the command.

〈msg〉
- lang(option)
- element containing a human-readable description of the response code.

〈msgQ〉
- count : the number of exist in the queue
- id : uniquely identify the message
- element that describes messages queued for client retrieval.

〈qDate〉
Option
- element that contains the date and time that the message was enqueued.

〈obj:name〉
Option (not Object-specific)

〈obj:trStatus〉
Option(not Object-specific)

〈obj:reID〉
Option(not Object-specific)

〈obj:reDate〉
Option(not Object-specific)

〈obj:acID〉
Option(not Object-specific)
- element that contains the identifier of the client that SHOULD act upon a PENDING transfer request.

〈obj:acDate〉
Option (not Object-specific)
- element that contains the date and time of a required or completed response.

〈obj:extDate〉
Option (not Object-specific)
- element that contains the end of the objectʹs validity period

〈clTRID〉〈
- The transaction identifier is formed using the 〈clTRID〉 associated with the command if supplied by the client and a 〈svTRID〉 (server transaction identifier) that is assigned by and unique to the server.

41) Restore Poll Response Elements

〈result〉
- code
- value is a four-digit, decimal number that describes the success or failure of the command.

〈msg〉
- lang(option)
- element containing a human-readable description of the response code.

〈msgQ〉
- count : the number of exist in the queue
- id : uniquely identify the message
- element that describes messages queued for client retrieval.

〈qDate〉
Option
- element that contains the date and time that the message was enqueued.

〈rgp-poll:name〉
- The domain name that is a candidate for restoration.

〈rgp:rgpStatus〉
s*
- The RGP status of the domain as a string

〈rgp:reqDate〉
- The date the server implementation is requesting the client’s restore report.

〈rgp:reportDuDate〉
- The date the client’s restore report must be received by the server implementation.

42) 〈poll op = “ack”〉 Request Elements

〈poll〉
- op (req, ack)
- msgID

〈clTRID〉
- element that MAY be used to uniquely identify the command to the client.

43) 〈poll op = “ack”〉 Response Elements

〈result〉
- code
- value is a four-digit, decimal number that describes the success or failure of the command.

〈msg〉
- lang(option)
- element containing a human-readable description of the response code.

〈msgQ〉
- count : the number of exist in the queue
- id : uniquely identify the message
- element that describes messages queued for client retrieval.

〈qDate〉
Option
- element that contains the date and time that the message was enqueued.

〈obj:name〉
Option

〈obj:trStatus〉
Option

〈obj:reID〉
Option

〈obj:reDate〉
Option

〈domain:acID〉
Option
- element that contains the identifier of the client that SHOULD act upon a PENDING transfer request.

〈domain:acDate〉
Option
- element that contains the date and time of a required or completed response.

〈domain:extDate〉
Option
- element that contains the end of the domain objectʹs validity period

44) 〈hello〉
Use of this element is essential in a connection-less environment where a server cannot return a 〈greeting〉 in response to a client-initiated connection.

〈hello〉 Request Elements

An EPP 〈hello〉 MUST be an empty element with no child elements

45) 〈greeting〉 Response Elements
An EPP server responds to a successful connection and 〈hello〉 element by returning a 〈greeting〉 element to the client.

〈svID〉
- element that contains the name of the server.

〈svDate〉
- element that contains the serverʹs current date and time in Universal Coordinated Time (UTC).

〈version〉
- elements that identify the protocol versions supported by the server.
one or more

〈lang〉
one or more

〈objURI〉
- elements that contain namespace URIs representing the objects that the server is capable of managing.
one or more

〈extURI〉
Option
- elements that contain namespace URIs representing object extensions supported by the server.

〈acess〉
〈all⁄〉:acess is given to all
〈none⁄〉:No access is provided
〈null⁄〉:Data is not persistent
〈personal⁄〉
〈personalAndOther⁄〉
〈other⁄〉
Option
- element that describes the access provided by the server to the client on behalf of the originating data source.

〈purpose〉
〈admin⁄〉
〈contact⁄〉
〈prov⁄〉
〈other⁄〉
Option

〈recipient〉
〈other⁄〉
〈ours⁄〉
〈public⁄〉
〈same⁄〉
〈unrelated⁄〉
Option

〈retention〉
〈business⁄〉
〈indefinite⁄〉
〈legal⁄〉
〈none⁄〉
〈stated⁄〉
Option

〈expiry〉
〈absolute⁄〉
〈relative⁄〉
Option

46) 〈login〉
〈login〉 command is used to establish a session with an EPP server in response to a greeting issued by the server.
A server operator MAY limit the number of failed login attempts N, 1 〈= N 〈= infinity, after which a login failure results in the connection to the server (if a connection exists) being closed.

〈login〉 Request Elements

〈clID〉
- element that contains the client identifier assigned to the client by the server.

〈pw〉
- element that contains the serverʹs current date and time in Universal Coordinated Time (UTC).

〈newPW〉
Option

〈version〉
Option
- elements that identify the protocol versions supported by the server.
one or more

〈lang〉
Option
one or more

〈objURI〉
- elements that contain namespace URIs representing the objects that the server is capable of managing.
one or more

〈extURI〉
Option
- elements that contain namespace URIs representing object extensions supported by the server.

47) 〈login〉 Response Elements

〈result〉
- code
- value is a four-digit, decimal number that describes the success or failure of the command.

〈msg〉
- lang(option)
- element containing a human-readable description of the response code.

48) 〈logout〉
〈logout〉 command is used to end a session with an EPP server.

〈logout〉 Request Elements
The 〈logout〉 command MUST be represented as an empty element with no child elements.

〈clTRID〉
- element that MAY be used to uniquely identify the command to the client.

49) 〈logout〉 Response Elements

〈result〉
code
- value is a four-digit, decimal number that describes the success or failure of the command.

〈msg〉
- lang(option)
- element containing a human-readable description of the response code.

〈qDate〉
Option
- element that contains the date and time that the message was enqueued.

Appendix A. Result Code

1) Successful command completion responses

1000 ʺCommand completed successfullyʺ
- This is the usual response code for a successfully completed command that is not addressed by any other 1xxx-series response code.

1001 ʺCommand completed successfully; action pendingʺ
- This response code MUST be returned when responding to a command that requires offline activity before the requested action can be completed. See Section 2 for a description of other processing requirements.

1300 ʺCommand completed successfully; no messagesʺ
- This response code MUST be returned when responding to a 〈poll〉 request command and the server message queue is empty.

1301 ʺCommand completed successfully; ack to dequeueʺ
- This response code MUST be returned when responding to a 〈poll〉 request command and a message has been retrieved from the server message queue.

1500 ʺCommand completed successfully; ending sessionʺ
- This response code MUST be returned when responding to a successful 〈logout〉 command.

2) Command Error responses

2000 ʺUnknown commandʺ
- This response code MUST be returned when a server receives a command element that is not defined by EPP.

2001 ʺCommand syntax errorʺ
- This response code MUST be returned when a server receives an improperly formed command element.

2002 ʺCommand use errorʺ
- This response code MUST be returned when a server receives a properly formed command element but the command cannot be executed due to a sequencing or context error. For example, a 〈logout〉 command cannot be executed without having first completed a 〈login〉 command.

2003 ʺRequired parameter missingʺ
- This response code MUST be returned when a server receives a command for which a required parameter value has not been provided.

2004 ʺParameter value range errorʺ
- This response code MUST be returned when a server receives a command parameter whose value is outside the range of values specified by the protocol. The error value SHOULD be returned via a 〈value〉 element in the EPP response.

2005 ʺParameter value syntax errorʺ
- This response code MUST be returned when a server receives a command containing a parameter whose value is improperly formed. The error value SHOULD be returned via a 〈value〉 element in the EPP response.

2100 ʺUnimplemented protocol versionʺ
- This response code MUST be returned when a server receives a command element specifying a protocol version that is not implemented by the server.

2101 ʺUnimplemented commandʺ
- This response code MUST be returned when a server receives a valid EPP command element that is not implemented by the server. For example, a 〈transfer〉 command can be unimplemented for certain object types.

2102 ʺUnimplemented optionʺ
This response code MUST be returned when a server receives a valid EPP command element that contains a protocol option that is not implemented by the server.

2103 ʺUnimplemented extensionʺ
- This response code MUST be returned when a server receives a valid EPP command element that contains a protocol command extension that is not implemented by the server.

2104 ʺBilling failureʺ
- This response code MUST be returned when a server attempts to execute a billable operation and the command cannot be completed due to a client-billing failure.

2105 ʺObject is not eligible for renewalʺ
- This response code MUST be returned when a client attempts to 〈renew〉 an object that is not eligible for renewal in accordance with server policy.

2106 ʺObject is not eligible for transferʺ
- This response code MUST be returned when a client attempts to 〈transfer〉 an object that is not eligible for transfer in accordance with server policy.

2200 ʺAuthentication errorʺ
- This response code MUST be returned when a server notes an error when validating client credentials.

2201 ʺAuthorization errorʺ
- This response code MUST be returned when a server notes a client-authorization error when executing a command. This error is used to note that a client lacks privileges to execute the requested command.

2202 ʺInvalid authorization informationʺ
- This response code MUST be returned when a server receives invalid command authorization information when attempting to confirm authorization to execute a command. This error is used to note that a client has the privileges required to execute the requested command, but the authorization information provided by the client does not match the authorization information archived by the server.

2300 ʺObject pending transferʺ
- This response code MUST be returned when a server receives a command to transfer of an object that is pending transfer due to an earlier transfer request.

2301 ʺObject not pending transferʺ
- This response code MUST be returned when a server receives a command to confirm, reject, or cancel the transfer of an object when no command has been made to transfer the object.

2302 ʺObject existsʺ
- This response code MUST be returned when a server receives a command to create an object that already exists in the repository.

2303 ʺObject does not existʺ
- This response code MUST be returned when a server receives a command to query or transform an object that does not exist in the repository.

2304 ʺObject status prohibits operationʺ
- This response code MUST be returned when a server receives a command to transform an object that cannot be completed due to server policy or business practices. For example, a server can disallow 〈transfer〉 commands under terms and conditions that are matters of local policy, or the server might have received a 〈delete〉 command for an object whose status prohibits deletion.

2305 ʺObject association prohibits operationʺ
- This response code MUST be returned when a server receives a command to transform an object that cannot be completed due to dependencies on other objects that are associated with the target object. For example, a server can disallow 〈delete〉 commands while an object has active associations with other objects.

2306 ʺParameter value policy errorʺ
- This response code MUST be returned when a server receives a command containing a parameter value that is syntactically valid but semantically invalid due to local policy. For example, the server can support a subset of a range of valid protocol parameter values. The error value SHOULD be returned via a 〈value〉 element in the EPP response.

2307 ʺUnimplemented object serviceʺ
- This response code MUST be returned when a server receives a command to operate on an object service that is not supported by the server.

2308 ʺCommand failedʺ
- This response code MUST be returned when a server is unable to execute a command due to an internal server error that is not related to the protocol. The failure can be transient. The server MUST keep any ongoing session active.

2500 ʺCommand failed; server closing connectionʺ
- This response code MUST be returned when a server receives a command that cannot be completed due to an internal server error that is not related to the protocol. The failure is not transient and will cause other commands to fail as well. The server MUST end the active session and close the existing connection.

2501 ʺAuthentication error; server closing connectionʺ
- This response code MUST be returned when a server notes an error when validating client credentials and a server-defined limit on the number of allowable failures has been exceeded. The server MUST close the existing connection.

2502 ʺSession limit exceeded; server closing connectionʺ
- This response code MUST be returned when a server receives a 〈login〉 command and the command cannot be completed because the client has exceeded a system-defined limit on the number of sessions that the client can establish. It might be possible to establish a session by ending existing unused sessions and closing inactive connections.

Dot DOOSAN(“.DOOSAN”) gTLD entrusts the operation of registry system to Korean ccTLD operation agency Korea Internet & Security Agency(“KISA”).

Whois Service refers to providing of information such as domain name registrant and expiration date by checking the registered domain nameʹs information. Whois service of dot DOOSAN(“.DOOSAN”) gTLD will be operated in the same manner as KISAʹs dot KR(“.KR”) is currently.

Network composition of currently running KISA Whois Service is shown in Figure 26-1.

Figure [26-1] Whois Service Network Diagram

As shown in Figure 26-2, data is extracted from inner database of SRS and processed for Whois service. The data are then saved in data repository of Whois server for the service.

Major characteristics of Whois Services are as the following:

1. Functions
- Realization of Real time Whois Information Update function
- Construction of Centralized Whois Data Repository
- Construction and realization of Whois data and service delegation through Standard 43 port
- Realization of Publication function for Whois Information Delegation
- Realization of Whois access Web Service for Internet users
- Construction and realization of Hierarchical system for the stability of Whois service
- Security function for Whois Information Distribution

Figure [26-2] Whois System (Main Center)

Whois server provides service of following list of data entities to 〈Domain Names〉, 〈Name Server〉 and 〈Registrars〉.

〈Domain Names〉
- Domain Name
- Registrar
- Whois Server
- Referral URL
- Name Servers
- Status
- Updated Date
- Creation Date
- Expiration Date

〈Name Server〉
- Server Name
- IP Address
- Registrar
- Whois Server
- Referral URL

〈Registrars〉
- Registrar Name
- Registrar contact details
- Registrar URL (Home Page)
- Registrar Whois URL

The gTLDʹs standard Whois format allows automated parsing of Whois information. Since data that can be deciphered can be easily edited, a more stable and formatted encoding mechanism can provide reliable Whois data to sites other than registrars.
For example, if an agency tracing infringement of brands desire to have Whois data automatically analyzed and saved in the tracing system, Whois information will have to be compatible with automatic processing to provide service. In order to it, Whois data will have to be in a format that can be deciphered.

The Whois Database of dot DOOSAN(ʺ.DOOSANʺ) gTLD supports usage of multiple string and field searching. Boolean search, which is based on combination of all Whois fields, can be used.
In order to accommodate any form of data access regulations in present or in future, it will provide filtering functions based on the requestor or query type functions and profiles for decipherable data. This function satisfies any data privacy requests imposed on Whois data.
While having limits on Whois data receivers usage limitations, Bulk Access Program can provide Data Mart, in which users can download database.

Data Mart Bulk Access Program
- reduces Data Mining Load that can be imposed on core Whois service
- can restrict data usage of subscribers
- Whole data base is provided in formats that can easily be data mined, such as execution brand search, industrial statistics collection and directory service

Both Registrar and Delegee are allowed to the abilities to have substantial bulk access. Only the data within privacy restrictions by registry administrator, law, or agreement will be provided.
Once mutual agreement with client accessing registry is met, each of Full ⁄ Incremental Data set is composed as XML document proper to contents and format request. Once XML document is produced, the next preparation step is processed.

2. Architecture
Dot DOOSAN(ʺ.DOOSANʺ) gTLD provides updates near real time, as well as Whois service that combine different classes such as scalable base and redundancy. As the size of registry increases, additional Whois-based structure can be installed that can geographically distribute, strengthen specific locationʹs service level, and reduce the load on registry.
Diagram in Figure 26-3 explains about Architecture. Incoming queries from each Whois sites are distributed by the Whois server cluster load balancer connected respectively to Back End Cluster. By the addition of server to one of the two clusters, this provides redundancy and scalability.

Each of Whois server caches regular requests to memory, and queries back end database cluster on cache. Period can be set in which information can be cached before Whois data is erased. Once the data is erased, server will have to re-search DB in order to find it.

Figure [26-3] Whois Architecture Diagram

Figure 26-4 explains the update of Whois DB. When Central Registry DB is updated, system also updates Whois distributed servers at almost at the same time. This DB is then copied to Whois DB through security a private link or channel using SSL while Registry attaches digital signature to the update package to authenticate and ensure data integrity.

Figure [26-4] Whois Database Update Process Diagram

Whois Service of dot DOOSAN(“.DOOSAN”) gTLD provides the following advantages:
- Services can be expanded by the addition of server in each Whois cluster
- DB can be expanded by the addition of equipments in each Whois cluster
- Services can be expanded by placing Whois infrastructure in each DB cluster
- Redundancy succeeding to subordinate categories ensures higher availability
- Update process is always the newest, ensures availability that is almost real time
- Quickest reaction time for caching of regular queries

Whois service of dot DOOSAN(“.DOOSAN”) is provided by using either Web (port 80) or Standard 43 port. Web service can query Domain Names, Registrars, and Name Servers, while standard 43 port can only query Domain Names.
For both Web and Port 43, Whois service provides result by instantly searching Whois System DB when service user does a query. Thus there is no separate synchronization mechanism of Whois Server. Data extracted from SRS DB for Whois search is also applied real time to Whois Distributor when there is any change.

3. Abuse and mitigation
Abuse and mitigation method of Whois Service are as the following;
Since DOOSAN CORPORATION limits registration eligibility of new gTLD to employees of DOOSAN CORPORATION or its affiliates to prevent abuse and maintain accuracy of Whois, there is low chance of reckless registration abuse and Whois inaccuracy problems.
However, in case of an emergency situation, policies are as the following, and the domain will be prohibited and deleted according to Zero-Tolerance policy.

Whois Accuracy Policy
1) Registrants will be limited to employees of DOOSAN CORPORATION or its affiliates.
2) At least one of either registrant name and registrant email must be information associated with DOOSAN CORPORATION or its affiliates.
3) Registrant have obligation to regularly update for accurate and up-to-date Whois information.

Criteria for Registration Abuse
1) Usage of abusive, profane language that offensive against public morals.
2) Both registrant name and registrant email having no relevance to DOOSAN CORPORATION or its affiliates.
3) The website running with commercial purpose such as gambling and porno sites.
4) The registered domain undermining DOOSAN CORPORATIONʹs image.
5) The registered domain infringing public interest.
6) Other cases in which domain usage is considered improper.

Abuse Prevention Policy (Zero-Tolerance)
1) Immediately after domain registration abuse is identified, registrant will be notified by the email, mail or fax registered in Whois and will be asked to modify within 10 days including holidays.
2) If no modification is made within 10 days after abuse identification, it will go into redemption period (Status: Redemption Period), and the registrant will be notified of this by the email, mail or fax registered in Whois.
3) Once 30 days pass after domain registration abuse is confirmed and redeemed, it will be deleted. (Status : Delete Period)

In case of a problem, contact us:
Director Name: New gTLD Administration
E-Mail: doosan@yesnic.com, gtld@yesnic.com
Fax Number: +82-2-2028-0011

Personnel for Whois service operation are listed as the following:

〈Whois Service Admin〉
- 1 person
- Planning & Policy of Whois System
- Over 7 years experiences

〈Whois Service Operation〉
- 1 person
- Development & Maintenance of Whois Service
- Over 2 years experiences

Systems for Whois service are listed as the following:

1) Whois Server 1
Location : KISA Main Center, Seoul, Korea
System : Oracle T6320
CPUs : 1.2Ghz × 1
Memory(MB) : 16GB
Total Storage(GB) : 98GB
Usage of CPU : 11%
Usage of Memory : 31%

2) Whois Server 2
Location : KISA Main Center, Seoul, Korea
System : Oracle T6320
CPUs : 1.2Ghz × 1
Memory(MB) : 16GB
Total Storage(GB) : 98GB
Usage of CPU : 10%
Usage of Memory : 31%

3) Whois Server 3 (Backup)
Location : KISA Backup Center, Seongnam, Korea
System : Dell R810
CPUs : 2.66Ghz × 2
Memory(MB) : 64GB
Total Storage(GB) : -
Usage of CPU : -
Usage of Memory : -

1. Overview
Registration life cycle policy of dot DOOSAN(“.DOOSAN”) that DOOSAN CORPORATION plans on operating follows the registration life cycle presented by ICANN (Figure 27-1). DOOSAN CORPORATION will fundamentally apply standard EPP RFC and will not apply those policies not issued in EPP RFC.

Figure [27-1] Registration Life Cycle

Main states of registration life cycle are as following:

2. Available
It refers to the state in which a domain name is available for registration. Easiest method to check domain registration availability is by inquiring the domain name on Whois site (URL: whois. doosan). A public registrant can register desired domain name through a registrar.

3. Registered
Registration of issued domain will be between one to ten years. Once the domain is registered, it is put into a zone file within 24 hours. Add grace period is given, during which the registrant may cancel the domain within the five days of registration. During this period, no additional penalty will be given for the cancellation, but the domain cannot be transferred to another registrar. The domain name will be removed from the Zone file and become ʹavailableʹ again if its registration is cancelled.

4. Auto-Renewal Grace Period
If a registrant wishes renewal of his⁄her own domain names, he⁄she must renew the domain name through former registrar or ask to another registrar to transfer it. Within 45 day after the expiration date, registrar must notify the registry the renewal or transfer of the domain name. Domain name still exists in the zone file during this period.

5. Redemption Period
If the registrar does not notify the registry of the renewal or transfer of the domain name within 45 days after the expiration date, the domain name is deleted from the zone file. During the redemption period, domain and mail will not work anymore since the domain name is not in the zone. Only the former owner of the domain may renew the domain name within 30 days of redemption period and the 5 days are left as pending deletion period.

6. Released (Available) Period
After the redemption period, domain is deleted and becomes available. Anyone can register this domain.

7. Resource Procurement Plan
SRS system management is divided into EPP⁄ Application, and Database management.

〈EPP Operation Management〉
- 1 person
- EPP Operation Policy, Supervisor of SRS Management
- Over 7 years experiences

〈EPP Operation〉
- 2 persons
- EPP Program Development & Maintenance
- Over 20 years experiences, over 10 years experiences

〈Database〉
- 2 persons
- DBA (Domain Registration DB)
- Over 7 years experiences, over 3 years experiences

28. Abuse Prevention and Mitigation

1. Overview
Registration of dot DOOSAN(ʺ.DOOSANʺ) is limited to employees of DOOSAN group and its affiliates. Operation of dot DOOSAN(ʺ.DOOSANʺ) registry system proposed by DOOSAN CORPORATION is entrusted to Korea Internet & Security Agency(ʺKISAʺ).

Since DOOSAN group limits registration eligibility of dot DOOSAN(ʺ.DOOSANʺ) to employees of DOOSAN or its, it is expected that there will be no issue of reckless registration abuse and inaccuracy of Whois data.

However, in order to minimize conditions that might cause unexpected situations such as infringement on legal rights and communityʹs concern, an executive office will be established that will review and approve requested domain to determine its registration.

In addition, the following policies will be set to determine registration abuse and suspend or revoke the domain according to Zero-Tolerance policy when a violation that can cause problems for other registrants is confirmed.

2. Whois Accuracy Policy
1) Registrant is limited to employees of DOOSAN group or its affiliates.
2) At least one of either registrant name and registrant email must be information associated with DOOSAN group or its affiliates.
3) Registrant has obligation maintain accurate Whois information (update, transfer, deletion, etc.) with up-to-date information that reflects any modifications of contacts, email, etc. 
4) Registrantʹs appropriateness will be considered for registrant authentication, and when processing request to transfer or delete, it will be done after multiple identification such as email authentication or strong password.

3. Criteria for Registration Abuse
1) Usage of country name, internet operation words
2) Usage of abusive, profane language that is offensive against public morals
3) Neither registrant name nor registrant email having no relevance to DOOSAN group or its affiliates
4) Website running with commercial purpose such as gambling website and adult website
5) The registered domain undermining DOOSAN group’s image
6) The registered domain infringing public interest
7) Other cases in which domain usage is considered improper

4. Abuse Prevention Policies (Zero-Tolerance)
1) Immediately after domain registration abuse is identified, registrant will be notified by the email, mail or fax registered in Whois and will be asked to modify within 10 days including holidays.
2) If no modification is made within 10 days after abuse identification, it will go into redemption period(Status: Redemption Period), and the registrant will be notified of this by the email, mail or fax registered in Whois.
3) Once 35 days pass after domain registration abuse is confirmed and redeemed, it will be deleted.

In order to facilitate registration abuse prevention of dot DOOSAN(ʺ.DOOSANʺ) and complaint reception, DOOSAN CORPORATION will post 24 hour contact information as the following on the webpage.

Contact us
Director Name: New gTLD Administration
E-Mail: doosan@yesnic.com, gtld@yesnic.com
Fax Number: +82-2-2028-0011

5. Criteria for Registration Abuse (¡°3. Criteria for Registration Abuse”)

1)  Words under “3. 1)” of Registration Abuse Criteria
a. Country Name: 264 items (Nations DB of Ministry of Foreign Affairs and Trade, ISO3166 Republic of Korea, etc.)
Afghanistan, Akrotiri, Albania, Algeria, American Samoa, American, Samoa, Andorra, Angola, Anguilla, Antarctica, Antigua and Barbuda, Antigua, Argentina, Armenia, Aruba, Australia, Austria, Azerbaijan, Bahamas, Bahrain, Bangladesh, Barbados, Belarus, Belgium, Belize, Benin, Bermuda, Bhutan, Bolivia, Bosnia and Herzegovina, Bosnia, Herzegovina, Botswana, Bouvet Island, Brazil, British Indian Ocean Territory, British, Brunei, Bulgaria, Burkina Faso, Burma, Burundi, Cambodia, Cameroon, Canada, Cape Verde, Cayman Islands, Central African Republic, Chad, Chile, Christmas Island, Christmas, Cocos Keeling Islands, Cocos Islands, Colombia, Comoros, Congo, Cook Islands, Costa Rica, Costa, Rica, Croatia, Cuba, Cyprus, Czech Republic, Czech, Denmark, Dhekelia, Djibouti, Dominica, Dominican Republic, Dominican, Ecuador, Egypt, El Salvador, Equatorial Guinea, Guinea, Eritrea, Estonia, Ethiopia, Falkland Islands, Faroe Islands, Fiji, Finland, French Guiana, French Polynesia, French, Gabon, Gambia, Gaza Strip, Georgia, Germany, Ghana, Gibraltar, Glorioso Islands, Greece, Greenland, Grenada, Guadeloupe, Guam, Guatemala, Guernsey, Guinea, Guinea-Bissau, Guyana, Haiti, Heard Island and McDonald Islands, Holy See, Honduras, Hong Kong, Hungary, Iceland, India, Indonesia, Iran, Iraq, reland, Isle of Man, Israel, Italy, Jamaica, Jan Mayen, Japan, Jersey, Jordan, Kazakhstan, Kenya, Kiribati, Korea, Kuwait, Kyrgyzstan, Laos, Latvia, Lebanon, Lesotho, Liberia, Libya, Liechtenstein, Lithuania, Luxembourg, Macau, Macedonia, Madagascar, Malawi, Malaysia, Maldives, Mali, Malta, Marshall Islands, Martinique, Mauritania, Mauritius, Mayotte, Mexico, Micronesia Federated States of, Micronesia, Moldova, Monaco, Mongolia, Montserrat, Morocco, Mozambique, Namibia, Nauru, Navassa Island, Nepal, Netherlands, Netherlands Antilles, New Caledonia, New Zealand, Nicaragua, Niger, Nigeria, Niue, Norfolk Island, Northern Mariana Islands, Norway, Oman, Pakistan, Palau, Panama, Papua New Guinea, Paracel Islands, Paraguay, Peru, Philippines, Pitcairn Islands, Poland, Portugal, Puerto Rico, Qatar, Reunion, Romania, Rwanda, Saint Helena, Saint Kitts and Nevis, Saint Lucia, Saint Pierre and Miquelon, Saint Vincent and the Grenadines, Samoa, San Marino, Sao Tome and Principe, Saudi Arabia, Senegal, Serbia and Montenegro, Seychelles, Sierra Leone, Singapore, Slovakia, Slovenia, Solomon Islands, Somalia, South Africa, South Georgia and the South Sandwich Islands, Spratly Islands, Sri Lanka, Sudan, Suriname, Svalbard, Swaziland, Sweden, Switzerland, Syria, Taiwan, Tajikistan, Tanzania, Thailand, Timor-Leste, Togo, Tokelau, Tonga, Trinidad and Tobago, Tromelin Island, Tunisia, Turkey, Turkmenistan, Turks and Caicos Islands, Tuvalu, Uganda, Ukraine, United Arab Emirates, Arab Emirates, United Kingdom, Kingdom, United States, Uruguay, Uzbekistan, Vanuatu, Venezuela, Vietnam, Virgin Islands, Wake Island, Wallis and Futuna, West Bank, Western Sahara, Yemen, Zambia, Zimbabwe, CHINA, USA, FRANCE, RUSSIA, SPAIN, ARAB

b. Internet Operation: 26 items
EXAMPLE, IETF, ROOT-SERVERS, WWW, ASO, IRIS, INTERNIC, CCNSO, IANA, IRTF, AFRINIC, TEST, IANA-SERVERS, GAC, ICANN, ISTF, RFC-EDITOR, TLD, APNIC, GNSO, IESG, LACNIC, RIPE, GTLD-SERVERS, ARIN, IAB

2) Words under “3. 2)” of Registration Abuse Criteria 
갈보, 보짓물, 좃, 성매매, 갈보년, 빠걸, 좆, 성매수, 같은년, 빠구리, 죽일년, 아동포르노, 같은놈,  뻐큐, 죽일놈, 양귀비, 같은새끼, 뽁, 지미씨부럴놈, 엑스타시, 개갈보, 사까시, 찢어발길년, 원조교제, 개상년, 상년, 화냥년, 음란물, 개상놈, 상놈, 화냥잡년, 음란물사이트, 개새끼, 상놈새끼, 화냥질, 자살, 개쌍년, 상놈의새끼, 강간, 자살사이트, 개쌍놈, 쌍년, 강도, 자살카페, 개잡년, 쌍놈, 겜블, 장기매매, 개지랄, 섹알바, 난자매매, 절도, 걸레년, 쌍놈새끼, 노름, 조건만남, 공씹, 쌍놈의새끼, 논리폭탄, 청부, 니노지, 씨발, 대리모, 카드생성기, 돌림빵, 씨부랄년놈, 대마초, 코카인, 뒈질년, 씨부랄연놈, 도박, 포르노, porn뒈질놈, 씨팔, 동반자살, 폭력, 똥갈보, 씹, 마약, 폭발물제조, 똥갈보년, 양갈보, 매춘, 폭탄제조, 미친년, 육시랄, 메일폭탄, 필로폰, 미친놈, 자지, 사제총기, 해킹, 병신새끼, 잠지, 사제폭탄, 헤로인, 보지, 조까, 살인, 히로뽕, asshole, boji, bojijaji, bozi, bozizaji, bozizazi, fuck, jaji, jajiboji, jazi, zaji, zazi

1. Overview
Registration of dot DOOSAN(“.DOOSAN”) is limited to employees of DOOSAN CORPORATION, DOOSAN group and its affiliates. The reason for this limitation is to prevent reckless abuse of a third party and infringement of DOOSAN CORPORATION intellectual property.
Registered strings are expected to be those only related to DOOSAN group. Thus, it is expected that possibility for dispute or right protection is minimized, and resolution can be done through mutual consent. However, in case of an unexpected situation, it will follow the following policy.

2. Operation Policy for Right Protection
All Right Protection Mechanism (ʺRPMʺ) is implemented and complied for the registration of the new gTLD. Other than RPM, registry operator develops and executes RPM to encourage or limit infringement on legitimate rights or encouragement of domain name abuse.

For this, the following Right Protection policy is applied.
1) Trademark verification for the protection of trademark owners is based on data by TradeMark Clearinghouse Provider, specified by ICANN.
2) When registration eligibility is open to the public, there is Sunrise period for at least 30 days for the protection of trademark owners. Also, all trademark owners registered in TradeMark Clearinghouse will be notified of this.
3) Trademark Claims period is 60days at minimum by mandate.
4) All other Rights Protection Mechanisms by ICANN is to be implemented and complied.

3. Dispute Resolution Mechanism
Employees of DOOSAN CORPORATION, DOOSAN group and its affiliates will submit domain registration application to the registrar, and registrar clearly deliberates the relevance. In the process of deliberation, right protection mechanism of registered characters considers ICANN and DOOSAN groupʹs domain registration policies in seeking to prevent dispute issues.
As dot DOOSAN(ʺ.DOOSANʺ) is registered by employees of DOOSAN CORPORATION, DOOSAN group and its affiliates, it is judged that there will almost be no dispute element. In case of a dispute, it will be preferentially resolve within, but dispute that is hard to settle will follow ICANNʹs dispute resolution mechanism (PDDRP & RRDRP).
In preparation for dispute of registered strings, DOOSAN CORPORATION establishes dispute arbitration center (secretariat) or assigns personnel and perform rights arbitration by setting dispute resolution process and details.
In case of an international dispute, it will be processed by ICANNʹs dispute Secretariat. (Asia, Europe, North America, etc.)
1) ICANNʹs Post-Delegation Dispute Resolution Procedure (ʺPDDRPʺ) and Registry Restrictions Dispute Resolution Procedure (ʺRRDRPʺ) are posted on website.
2) Registry operator agrees to reimburse all fees that should have been paid to the provider if the panel deems the PDDRP complainant as the winning party.
3) Registry operator agrees to implement and comply to all of measures imposed by ICANN after the decision of PDDRP or RRDRP panel.

4. Registration Criteria
Domain registration criteria of DOOSAN CORPORATION is subject to the following criteria:
1) Domain name must be composed as a combination of a complete Hangul Syllable [11,172 characters], alphabet [A-Z], [a-z], numbers [0-9] and hyphen [-].
2) Domain name should be between 3 and 63 characters. If Hangul is included, it should be between 1 and 17.
3) Domain name must not start or end with a hyphen, and there cannot be two consecutive hyphens as the third and the fourth character.

5. Registration Process
Registration process is conducted by preparing regulations before and after delegation and registration policies. Primary opportunity of registration within dot DOOSAN(ʺ.DOOSANʺ) is first given to trademark owners, considering protection of rights of trademark owners in DOOSAN group.
Domain name registration through a registrar considers the following points in setting a criteria, and a range of possible strings falls under the following criteria.
1) Trademark owner registration is done online as one domain name per trademark through the registrar.
2) Process fees and its refunds is decided by the registrar.
3) Application is sent real time to the registry system from the registrar website.

Verification process validity of trademark, suitability if the domain, and whether or not trademark owner is the same as the domain applicant is operated when registrar and registry register.
1) Inadequate application will be returned after application verification.
2) If the same domain applied multi-times, is 2 candidates will be selected from a draw.

6. Dispute Resolution Procedure
In order to minimize complaints and disputes by domain registration of a disqualified person, there will be objection period about preliminary registrant result. Dispute resolution procedure from receiving objection to notifying results is as the following:
1) STEP 01 - Applications are submitted by completing forms designated by a dispute resolution center(secretariat) of registry and sending via e-mail or completing directly on the web page.
2) STEP 02 - Resolution procedure begins after all documents have been received, payment is confirmed, and accuracy of information on application is verified. Once resolution procedure has commenced, change of information of the respondentʹs domain name is limited.
3) STEP 03 - Dispute resolution center forwards the application form submitted through online to the domain name registrant and requests submission of response.
4) STEP 04 - Response must be submitted online to the Center within 20 days the request was sent to the respondent. Extension of time for response submission is not allowed in principle, but it can be done under the agreement of complainant.
5) STEP 05 - Arbitration panel consists of 1 or 3 arbitration members.
6) STEP 06 - Arbitration trial is documentary examination in principle, and the decision must be notified to the center within 14 days after the panel was organized.
7) STEP 07 - if complainantʹs claim falls under article 4(a) uniform Domain-Name Dispute-Resolution Policy(ʺUDRPʺ), the domain name is transferred, obliterated, or dismissed.
8) STEP 08 - Respondent may submit a case to the court if there is objection to transfer or obliteration decision of the panel. A registrar will execute the decision if respondent does not submit official document of case submission to the court to the registrar within 10 working days since receiving the decision.

7. Dispute Resolution
Decisions made by dispute resolution may either be transfer or obliteration, or dismissal of revision request.
Resolution may lead to transfer or obliteration under the following situations:
1) Registrantʹs domain name identical or confusingly similar to the trademark applicant has the right of.
2) Registrant having no right or legitimate interest of the domain name.
3) Registrantʹs domain name registered and used under a improper purpose.

Resolution may lead to dismissal under the following situations:
1) When there is no reason to the complainantʹs claim.
2) When respondent has legitimate rights or interests of the domain name registration or usage.
3) When registrant used the domain name or corresponding name for service without any dishonest intention or been doing considerable amount of preparation prior to receiving notice of dispute.
Registration is complete only after receiving result though the process above and registration fee is paid within the period through the registration agent.

1. KISAʹs Role
DOOSAN CORPORATION entrusts system operation of dot DOOSAN(“.DOOSAN”) to Korea Internet & Security Agency(ʺKISAʺ). DOOSAN CORPORATION follows KISAʹs security policy as the following:

KISAʹs main role is to plan Internet Policy, manage Internet address, operate CERT(Computer Emergency Response Task), protect information infrastructures, support information security(privacy⁄user), support International cooperation and promote business industry. KISAʹs Internet Resource Management Center(“Main Center”), which supports Internet address management, is managing the Internet policies regarding Korean ccTLD.

As one of the government agencies, the main of KISAʹs Internet address managing task is to develop and promote the Internet address resources and to build safe and secure infrastructures for the domestic and foreign Internet users as well as informationization of national society.
Since KISAʹs role in Internet address managing has national importance, it is designated as the Critical Information Infrastructure(CII). It is stated in the Information and Communication Infrastructure protection law article 5 to have the information level analyzed annually and also prepare protection plans through the regular auditing. The Critical Information Infrastructures are infrastructures with significant impact on national, economic and social society. To prevent the infrastructure from the physical and electronic attacks, CIIs have to analyze vulnerabilities and also establish protective measures to prove the information security level.

2. Information Infrastructure Protection Management Plan
Ever since the Internet address management system was designated as the Information Communication Infrastructure facility under the Communication Infrastructure protection law at year 2002, it is being operated systematically. To improve the security level of the nationally important infrastructures, areas such as finance, communication, national defense, and etc., the government is managing security by designating them as the Information Infrastructure. To increase the security level and to protect the assets, they achieved ISO-27001 certificate at 2006 and had maintained it for three years.

The current organization of KISA was established at 2009 by the national policy, (three organization, NIDA, KISA, KIICA, have combined into an agency), to activate the Internet business industry, enhance information infrastructure security level, and support the International cooperation. The former KISA was an agency to develop and activate information policy for private and public sector, operate KISC(Korea Internet Security Center) CERT, and authenticate Information Security Management System(ISMS). By developing and auditing Korean form of ISO-27001, they have performed the authentication of Korean-ISMS, PIMS, G-ISMS ever since the act became valid at year 2002.

KISA ISMS authentication status - 2012. Feb.
- KISMS(Korea Information Security Management System) – 131 cases(2002-2012)
- PIMS(Personal Information Security Management System) – 12 cases (2010-2012)
- GISMS(Government- Information Security Management System) - 36 cases(2010-2012)

These activities of managing Information Infrastructure is controlled by the Ministry Of Public Administration and Security(“MOPAS”), which is the control tower of the public Information Infrastructures. By following the National Information Security(“NIS”) polices, public office security policies and etc. MOPAS analyzes the national critical facilitiesʹ security plans and counter measures annually and by reviewing the validity with the NIS, gives the feedbacks to adopt the security plans.
To develop counter measures for the CII, it is stated under the act that only the reliable third party, designated as the Information Security Consulting Service Provider (ISCSP), is able to analyze and evaluate the vulnerabilities.

3. Information Communication Infrastructure Protection Law (ICIP law)
KISA evaluates and analyzes the important infrastructures designated under the Information communication Infrastructure Protection Law. This task is also stated in the law (ICIP law), and this evaluation must take place once a year.
Under Information Infrastructure Protection Act Article 9 (analysis and evaluation of the vulnerability)
1) The head of agency as prescribed by the Presidential Decree jurisdiction should regularly communicate critical information on infrastructure vulnerability analysis and be assessed.
2) The head of management agency under paragraph (1) assesses the vulnerability analysis, as prescribed by the Presidential Decree, if the vulnerability analysis and evaluation task force should be.
3) The head of management agency under paragraph (1)
If one wants vulnerability analysis and assessment of the following cases in the jurisdiction of the agencyʹs major information and communication infrastructure, they can be made. However, in the case under the provisions of paragraph (2) may be closed to the task force. 〈Revised by Act 12⁄18⁄2002, 12⁄21⁄2007, 05⁄22⁄2009〉

When former KISA was performing such certification and evaluation activities under the ICIP law, the united KISA has come to conclusion that KISA no longer needs to follow the ISO-27001 certification.( KISA was already under the law to perform Korean version of ISO-27001, such as K-ISMS, G-ISMS, PIMS and etc, and the certification object, the former NIDA, has become one organization) Since KISA is also has certification authority of its own, KISA stopped following the certification for the independence and fairness. However, since the organization is very important by the ICIP law, it is to be monitored and examine information security level to follow the appropriate security level Korean ISMS is requiring.

4. Information Communication Infrastructure Protection Control Lists
KISAʹs Internet address resource management center(“Main Center”), as an important infrastructure, is evaluated based on the ʺKISAʹs information security level examination methodsʺ in management security, physical security, technical security and other information security activities.
To examine the information security level, 12 areas, 54 control lists and 81 specific control lists were researched and developed from the ISO-27001 standard, NISʹs national information security regulation, Information Communication Infrastructure protection regulation.
This evaluation based on information and communication based on knowledge and information protection laws consulting companies (7 companies by Jun, 2012) can be performed.
This specialized vendors capital, expertise, personnel performing, technical skills, history of work performed by considering the vulnerability analysis assessment mission to private contractors a reasonable target was specified by government agencies.

Here are the 12 areas of Important Information Communication Infrastructure.
1) Information Security Policy
- Whether the documentation of information security duties in policy and procedures is properly done and followed as stated
2) Risk Analysis
- Whether the documentation of identifying the resourceʹs risks and planning the protection measures to prevent the information resources and the systems is properly done and followed as stated
3) Configuration Management
- IT configuration elements(procedure of software version and patch upgrades, hardware technical documents) must be properly managed and the procedure and policy must be prepared for configuration changes and must also be followed.
4) Maintenance
- the policy and procedure of the maintenance must be followed during the environmental disasters or illegal accesses, the device suppliers must perform proper repair within the time stated in the contract and only authorized employees can perform the maintenance.
5) Media Protection
- to protect the unauthorized flow out or misuse of media, the procedures and policy must be made and be operated as stated, and the operation procedures for the information stored devices and print outs must be prepared.
6) Security Awareness training
- including the CEOʹs security awareness, the information system(H⁄W, S⁄W, data management and etc. ) proper usage and other security requirements, legal authority, access control and other security issues must be trained regularly.
7) Contingency Plan
- for the variety of disasters and emergency cases, the important system‘s fusibility and reliance must be maintained. The procedures and policies must be stated and documented and also the systems must be operated as stated.
8) Physical and Environmental Security
- examines the location of important facilities and resources, and access control methods. Also evaluates the appropriate protective measures for the physical barrier and entrance control and limitation of the approach from the unauthorized ones.
9) Personnel Security
- The policy and procedures stating that the organization members and the third party that operates the information systems must be screened from the mistake, fraud, robbery, misuse.
10) Incident Response
- for the efficient and fast recovery from the hacking and virus attacks or physical attacks, the plans and procedures must be prepared depending on the areas, configuration system, duty or role definitions. This must documented and followed as stated.
11) Audit and Accountability
- All the records of who, what, how, when on which devices or services and the result of the access(pass or fail) must be audited.
12) System Access Control and Communication Protection
- Whenever developing, upgrading and doing other tasks accessing information systems, security requirements must be followed. And also to protect the data and S⁄W loss, faulty changes, misuses, the safety of the task must be always secured. The applications, service supporting process must be considered as important system and the security requirements appliance must be always reported.

5. Information Communication Infrastructure Protection Lawʹs Information Security Level Evaluation
- Internet address management centerʹs information security level must be annually audited with the Information Communication Infrastructure Information Protection level standards formed with 12 areas and 81 specific access control lists.

Table [30-1] Information Security Level Evaluation List

Information Security level was developed to evaluate the systematic structure of information systems in quantity and quality level and then it is divided into 5-levels of maturity levels. Address resource center(“Main Center”) received 83 point(year 2010: 68.2 point) for the level evaluation and 3rd level(3.67) in maturity level, which is a relatively high level compared to year 2010ʹs 3.50 level.
Important thing is that the evaluation method of maturity level is very negative. The total point in evaluation is the average of all the control lists. But, for the maturity level, it is decided by the lowest control list. This method came from an idea that the most vulnerable control list will eventually be the most threat to the system, and so by improving the weakest point in security will give the most effective way to protect the system.

Figure [30-1] Results of Information Security Level Evaluation

The meaning of maturity level 3, which KISAʹs internet address resource management center(“Main center”) received, is that KISA is properly following the Information Security level evaluation control lists and operating well with its documents and policies.
Also, this evaluation system does not look at the current situation, and level over 3 is given when improvement through task repetition that happened over at least three years can be proved. Considering that KISA was established as a new institution at year 2009, the maturity level received at year 2011 has its meanings.

Internet address management Center has several security regulations of its own and each regulation has its own specific procedures.

Table [30-2] Security regulations

New gTLD Application Submitted to ICANN by: Doosan Corporation

String: doosan

Originally Posted: 13 June 2012

Application ID: 1-1855-76721

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.