25 Extensible Provisioning Protocol (EPP)

Prototypical answer:

25 Extensible Provisioning Protocol (EPP)
CONAC has selected Extensible Provisioning Protocol (EPP) 1.0 as the communication protocol between CONAC and registrars. EPP 1.0 has standardized formats and scalability, and can meet CONAC’s business requirements.

25.1 EPP Packet
EPP Packet is the implementation of EPP interface. It is a software package developed pursuant to RFCs and actual business demands, and it is responsible for the interaction and communication between registrars and CONAC. Description for EPP-based communication between CONAC and registrars can be found in Figure1of Q25_attachment.

The EPP Packet is developed by a highly experienced third-party software developer. CONAC selects the third-party developer based on ISO27000 and ISO9000 certificates and Capability Maturity Model Integration (CMMI). CONAC and the third-party developer develop software in strict compliance with Software Development Life Cycle (SDLC), review and audit software products and development activities on the basis of Software Quality Assurance (SQA) to ensure all software meet relevant standards. During the planning phase, CONAC signs an agreement with the third-party developer, stipulating development scope, schedule, cost, confidentiality as well as conditions for acceptance. During the demand analysis phase, CONAC proposes business demands and performance demands based on Service Level Agreement (SLA) to the third-party developer. During software designing, programming and software testing, CONAC participates in reviewing and auditing the software products and development activities to ensure the quality of the software. At the end of the project, the third-party developer shall submit the development outcomes including design document, source code, testing report, user guide and so on to CONAC. CONAC performs business test, performance test, and security test of the software in its own testing systems. The software that has passed the testing will be deployed in the production environment for operation, and maintained by the third-party developer. CONAC has already developed EPP Packet which passed SRS joint testing.

EPP Packet includes the server software (EppServer) and client software (EppClient). EppServer runs on CONAC side, while EppClient is on registrar side. Registrars send operation commands relating to domain name to CONAC EppServer via EppClient, and EppServer completes each operation.

EPPserver Packet is developed with C++ language and related technologies. EppServer supports high concurrent access.

25.2 Interfaces with Registrars
Based on the EPP protocol, CONAC provides a registration management interface with registrars in the EPP Packet. The interface establishes sessions with CONAC, registers and manages objects of domain, host, and contact, and receives and confirms asynchronous message (as shown in Figure 2 of Q25_attachment). On the basis of the interface provided by CONAC, registrars can realize complete business operations and functions, as well as their proprietary business processes.

The registration and management commands of each object are the commands defined in EPP protocols. Some commands are in full compliance with parameters required in EPP protocols, while others extend command parameters in compliance with RFC3735 to meet CONAC business demands. CONAC provides registrars with all EPP commands relating to domain, host and contact operations, including check, info, create, update, delete, transfer and renew. CONAC also provides registrars with EPP commands relating to establishing session with CONAC and sending message, including login, logout, hello⁄greeting and poll.

25.3 Compliance with EPP-Related RFCs
EPP Packet complies with RFC5730, RFC5731, RFC5732, RFC5733 and RFC5734, which are the latest descriptions of EPP 1.0. CONAC uses these RFC documents as the main reference while developing EPP Packet. Besides, EPP Packet also complies with RFC3915 and RFC5910 to realize EPP function extensions. RFC3735 is the guiding specification for EPP extensions. In the case that standard protocol cannot meet any CONAC business demands, CONAC will extend the protocol with RFC3735 as the guidance, and the extension is primarily at command-response level.

25.3.1 Compliance with RFC5730
As per RFC5730, EPP Packet implements session login⁄logout, hello command, the receipt of asynchronous message and command confirmation. Additionally, the format, response code, date format and internationalization support of EPP Packet also comply with RFC5730.

25.3.2 Compliance with RFC5731
As per RFC5731, EPP Packet implements the domain object commands of create, update, delete, check, info, renew and transfer. To support Chinese IDN, all domain operation commands support Chinese IDN input directly. CONAC Chinese IDN policy stipulates that the registrant applying for a simplified Chinese domain name will be given the traditional counterpart of the domain name free of charge, and vice versa. In response to the policy, the simultaneous application for simplified Chinese domain name and traditional Chinese domain name are supported. The correlation of the simplified Chinese domain name and traditional Chinese domain name is managed in SRS.

25.3.3 Compliance with RFC5732
As per RFC5732, EPP Packet implements the host object commands of create, update, delete, check, and info. The host object subordinate to a domain object will be transferred automatically along with the transfer of the domain object. The host IP can be either IPv4 or IPv6.

25.3.4 Compliance with RFC5733
As per RFC5733, EPP Packet implements the contact object commands of create, update, delete, check, info and transfer. CONAC contact information supports Chinese and ASCII, but disclose attribute is not supported for the moment.

25.3.5 Compliance with RFC5734
As per RFC5734, EPP mapping based on TCP (Transmission Control Protocol) transport layer is realized, and Secure Sockets Layer (SSL) protocol is utilized on TCP. The format of EPP Packet, the relationship between the session and TCP connection, the communication sequence between the client and the server, as well as the listening port all comply with the requirements of RFC5734.

25.3.6 Compliance with RFC3735
As a result of the specificity of CONAC business, CONAC extends several functions in addition to the standard EPP functions. These extensions are command-response, and consistent with RFC3735. The specific extensions include providing Punycode for Chinese IDN domain names in the response to domain object command of info. For XML Schema of EPP extension, please refer to Appendix: EPP Domain Name Mapping Extension for Chinese Domain Names.

25.3.7 Compliance with RFC3915
As per RFC3915, CONAC implements domain name redemption grace period policy.

25.3.8 DNS Security Extensions (DNSSEC)
While implementing EPP Packet, CONAC has realized function extension to support DNSSEC. EPP Packet is implemented in accordance with RFC5910 (obsolete RFC4310). EPP Packet extends commands in the domain object operations, and supports the transmission of Delegation Signer (DS) information during the communication between the registrars and CONAC.

25.4 EPP Schema of Interface with Registrars
EPP schema used by CONAC includes EPP XML schema defined in RFCs and EPP XML schema in response to proprietary extensions.

25.4.1 EPP XML Schema Defined in RFCs
urn:ietf:params:xml:ns:eppcom-1.0 (Refer to RFC5730)
urn:ietf:params:xml:ns:epp-1.0 (Refer to RFC5730)
urn:ietf:params:xml:ns:domain-1.0 (Refer to RFC5731)
urn:ietf:params:xml:ns:host-1.0 (Refer to RFC5732)
urn:ietf:params:xml:ns:contact-1.0 (Refer to RFC5733)
urn:ietf:params:xml:ns:rgp-1.0 (Refer to RFC3915)
urn:ietf:params:xml:ns:secDNS-1.1 (Refer to RFC5910)

25.4.2 EPP XML Schema of CONAC’s Proprietary Extensions
As per RFC5731, CONAC provides Chinese domain name (CDN) extension to info command. For details, please refer to Appendix: EPP Domain Name Mapping Extension for Chinese Domain Names.

25.5 Resourcing Plan
To support the stable and reliable operation of EPP, CONAC allocates 7 staff in terms of technology, and customer support to this area. Detailed human resource allocation is as follow.

1 software engineer (software engineer role B: 1 staff), responsible for the software maintenance;
3 system engineers (software engineer role A: 3 staff), responsible for the system monitoring;
1 network engineer (network engineer role B: 1 staff) responsible for system network maintenance;
1 marketing staff (marketing staff role A: 1 staff), responsible for communication and outreach for “.公益” TLD;
1 customer support staff (customer support role B: 1 staff), responsible for answering client questions and addressing problems detected in EPP system operation for users.

All the aforementioned staff are currently in place. Detailed skillset requirements on the staff can be found in section 31.3.3 in response to Question 31.

CONAC uses 6 servers to provide EPP services, 4 servers in the primary operations center and 2 servers in the backup operations center. These servers also provide SRS services. Details for software and hardware can be found in the response to Question 32.

These resources are sufficient for the initial implementation and ongoing maintenance.

Costs of resources allocation are detailed in costs and capital expenditures of Question 47a and 47b.




Appendix: EPP Domain Name Mapping Extension for Chinese Domain Names


Internet Engineering Task Force Z. Wang
Internet-Draft CONAC
Intended status: Informational February 21, 2012
Expires: January 5, 2013

Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for
Chinese Domain Names
draft-wang-epp-cdn-mapping-00

Abstract

This document describes an extension of Extensible Provisioning Protocol (EPP) domain name mapping for the provisioning and management of Chinese Domain Names (CDNs). Specified in XML, this extended mapping is applied to provide additional features required by CDNs Registration.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF).
Note that other groups may also distribute working documents as Internet-Drafts.
The list of current Internet-Drafts is at http:⁄⁄datatracker.ietf.org⁄drafts⁄current⁄.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ʺwork in progress.ʺ

This Internet-Draft will expire on January 5, 2013.

Copyright Notice

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trustʹs Legal Provisions Relating to IETF Documents (http:⁄⁄trustee.ietf.org⁄license-info) in effect on the date of publication of this document.

Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008.

The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.


Table of Contents

1. Introduction
2. Terminology
3. Object Attributes
4. EPP Command Mapping
4.1. EPP Query Commands
4.1.1. EPP 〈check〉 Command
4.1.2. EPP 〈info〉 Command
4.1.3. EPP 〈transfer〉 Query Command
4.2. EPP Transform Commands
4.2.1. EPP 〈create〉 Command
4.2.2. EPP 〈delete〉 Command
4.2.3. EPP 〈renew〉 Command
4.2.4. EPP 〈transfer〉 Command
4.2.5. EPP 〈update〉 Command
5. Formal Syntax
6. Internationalization Considerations
7. IANA Considerations
8. Security considerations
9. References
Author’s Address


1. Introduction
Many Chinese characters in common use have variants in Simplified Chinese (SC) form, Traditional Chinese (TC) form or other variant forms.

For example, the Chinese character ʺU+5B81ʺ has 5 variants:
ʺU+5B81ʺ (SC form), ʺU+5BE7ʺ (TC form), ʺU+21A34ʺ , ʺU+5BDCʺ and ʺU+5BCDʺ (other variant forms).

For Chinese users, the variants of a Chinese character in SC form, TC form and other variant forms are regarded as the same.

To simplify the EPP implementations with supprt for CDN, Chinese Domain Names (CDNs) containing different variant forms (SC form, TC form, and other variant forms) are regarded as seperated ones in this extension, whereas the association between variant forms are ensured by registration management which is out of scope of this specification.

In order to meet above requirements of the CDNs registration, this document describes an extension of the Extensible Provisioning Protocol (EPP) domain name mapping [RFC5731] for the provisioning and management of CDNs.

This document is specified using the Extensible Markup Language (XML) 1.0 as described in [W3C.REC-xml-20040204] and XML Schema notation as described in [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028].

The EPP core protocol specification [RFC5730] provides a complete description of EPP command and response structures.

A thorough understanding of the base protocol specification is necessary to understand the extension of mapping described in this document.

2. Terminology
The key words ʺMUSTʺ, ʺMUST NOTʺ, ʺREQUIREDʺ, ʺSHALLʺ, ʺSHALL NOTʺ, ʺSHOULDʺ, ʺSHOULD NOTʺ, ʺRECOMMENDEDʺ, ʺMAYʺ, and ʺOPTIONALʺ in this document are to be interpreted as described in [RFC2119].

ʺcdn-1.0ʺ in this document is used as an abbreviation for urn:ietf:params:xml:ns:cdn-1.0.

In examples, ʺC:ʺ represents lines sent by a protocol client and ʺS:ʺ represents lines returned by a protocol server.

Indentation and white space in examples are provided only to illustrate element relationships and are not a REQUIRED feature of this specification.

XML is case sensitive.

Unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented to develop a conforming implementation.

3. Object Attributes
This extension defines one additional element to the EPP domain name mapping [RFC5731]. It can be got from 〈domain:info〉 command.

The CDN Punycode domain name is a domain name in Punycode [RFC3492] which is converted from the corresponding CDN.

In this document, its corresponding element is 〈cdn:CDNPunycode〉.

4. EPP Command Mapping
A detailed description of the EPP syntax and semantics can be found in the EPP core protocol specification [RFC5730].

The command mappings described here are specifically for use in provisioning and managing CDNs via EPP.

4.1. EPP Query Commands
EPP provides three commands to retrieve domain information: 〈check〉 to determine if a domain object can be provisioned within a repository, 〈info〉 to retrieve detailed information associated with a domain object, and 〈transfer〉 to retrieve domain-object transfer status information.

4.1.1. EPP 〈check〉 Command
This extension does not add any element to the EPP 〈check〉 command or 〈check〉 response described in the EPP domain name mapping [RFC5731].

When a domain name has not been registered, but the domain which the user submitted for check is in the CDN list of a registered domain name, 〈check〉 response must contain explanation in the reason field to tell the user that this domain name is a CDN of a registered domain name, and can be activitated by the registrant by 〈create〉 command.

4.1.2. EPP 〈info〉 Command
This extension does not add any element to the EPP 〈info〉 command described in the EPP domain mapping [RFC5731]. However, additional elements are defined for the 〈info〉 response.

When an 〈info〉 command has been processed successfully, the EPP 〈resData〉 element MUST contain child elements as described in the EPP domain mapping [RFC5731].

In addition, the EPP 〈extension〉 element SHOULD contain a child 〈cdn:infData〉 element that identifies the extension namespace if the domain object has data associated with this extension and based on server policy.

The 〈cdn:infData〉 element contains one child element:

o An OPTIONAL 〈cdn:CDNPunycode〉 element that contains the Punycode of the CDN.

Example 〈info〉 Response for an authorized client:

S:〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ standalone=ʺnoʺ?〉
S:〈epp xmlns=ʺurn:ietf:params:xml:ns:epp-1.0ʺ〉
S: 〈response〉
S: 〈result code=ʺ1000ʺ〉
S: 〈msg〉Command completed successfully〈⁄msg〉
S: 〈⁄result〉
S: 〈resData〉
S: 〈domain:infData
S: xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ〉
S: 〈domain:name〉
S: ʺU+5B9EʺʺU+4f8bʺ.ʺU+4E2DʺʺU+56FDʺ〈⁄domain:name〉
S: 〈domain:roid〉58812678-domain〈⁄domain:roid〉
S: 〈domain:status s=ʺokʺ⁄〉
S: 〈domain:registrant〉123〈⁄domain:registrant〉
S: 〈domain:contact type=ʺadminʺ〉123〈⁄domain:contact〉
S: 〈domain:contact type=ʺtechʺ〉123〈⁄domain:contact〉
S: 〈domain:ns〉
S: 〈domain:hostObj〉ns1.example.cn〈⁄domain:hostObj〉
S: 〈⁄domain:ns〉
S: 〈domain:clID〉ClientX〈⁄domain:clID〉
S: 〈domain:crID〉ClientY〈⁄domain:crID〉
S: 〈domain:crDate〉2011-04-03T22:00:00.0Z〈⁄domain:crDate〉
S: 〈domain:exDate〉2012-04-03T22:00:00.0Z〈⁄domain:exDate〉
S: 〈domain:authInfo〉
S: 〈domain:pw〉2fooBAR〈⁄domain:pw〉
S: 〈⁄domain:authInfo〉
S: 〈⁄domain:infData〉
S: 〈⁄resData〉
S: 〈extension〉
S: 〈cdn:infData
S: xmlns:cdn=ʺurn:ietf:params:xml:ns:cdn-1.0ʺ〉
S: 〈cdn:CDNPunycode〉
S: xn--fsq270a.xn--fiqs8s〈⁄cdn:CDNPunycode〉
S: 〈⁄cdn:infData〉
S: 〈⁄extension〉
S: 〈trID〉
S: 〈clTRID〉ABC-12345〈⁄clTRID〉
S: 〈svTRID〉54322-XYZ〈⁄svTRID〉
S: 〈⁄trID〉
S: 〈⁄response〉
S:〈⁄epp〉

〈info〉 Response for the unauthorized client has not been changed,see [RFC5731] for detail.

An EPP error response MUST be returned if an 〈info〉 command cannot be processed for any reason.

4.1.3. EPP 〈transfer〉 Query Command
This extension does not add any element to the EPP 〈transfer〉 command described in the EPP domain mapping [RFC5731].

4.2. EPP Transform Commands
EPP provides five commands to transform domain objects: 〈create〉 to create an instance of a domain object, 〈delete〉 to delete an instance of a domain object, 〈renew〉 to extend the validity period of a domain object, 〈transfer〉 to manage domain object sponsorship changes, and 〈update〉 to change information associated with a domain object.

4.2.1. EPP 〈create〉 Command
This extension defines additional elements to extend the EPP 〈create〉 command described in the EPP domain name mapping [RFC5731] for CDN registration.

4.2.2. EPP 〈delete〉 Command
This extension does not add any element to the EPP 〈delete〉 command described in the EPP domain mapping [RFC5731].

4.2.3. EPP 〈renew〉 Command
This extension does not add any element to the EPP 〈renew〉 command described in the EPP domain mapping [RFC5731].

4.2.4. EPP 〈transfer〉 Command
This extension does not add any element to the EPP 〈transfer〉 command described in the EPP domain mapping [RFC5731].

4.2.5. EPP 〈update〉 Command
This extension does not add any element to the EPP 〈update〉 command described in the EPP domain mapping [RFC5731].

5. Formal Syntax
An EPP object name mapping extension for CDN is specified in XML Schema notation.

The formal syntax presented here is a complete schema representation of the object mapping suitable for automated validation of EPP XML instances.

The BEGIN and END tags are not part of the schema; they are used to note the beginning and ending of the schema for URI registration purposes.

BEGIN
〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ?〉

〈schema targetNamespace=ʺurn:ietf:params:xml:ns:cdn-1.0ʺ
xmlns:cdn=ʺurn:ietf:params:xml:ns:cdn-1.0ʺ
xmlns:epp=ʺurn:iana:xml:ns:epp-1.0ʺ
xmlns:eppcom=ʺurn:iana:xml:ns:eppcom-1.0ʺ
xmlns=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
elementFormDefault=ʺqualifiedʺ〉

〈!--
Import common element types.
--〉
〈import namespace=ʺurn:iana:xml:ns:eppcom-1.0ʺ
schemaLocation=ʺeppcom-1.0.xsdʺ⁄〉
〈import namespace=ʺurn:iana:xml:ns:epp-1.0ʺ
schemaLocation=ʺepp-1.0.xsdʺ⁄〉

〈annotation〉
〈documentation〉
Extensible Provisioning Protocol v1.0
CONAC Domain Extension Schema v1.0
〈⁄documentation〉
〈⁄annotation〉


〈!--
Child elements found in EPP commands.
--〉
〈element name=ʺinfDataʺ type=ʺcdn:infDataTypeʺ⁄〉


〈!--
Child elements of the 〈cdn:infData〉 command
All elements must be present at time of creation
--〉
〈complexType name=ʺinfDataTypeʺ〉
〈sequence〉
〈element name=ʺCDNPunycodeʺ type=ʺeppcom:labelTypeʺ
minOccurs=ʺ0ʺ ⁄〉
〈⁄sequence〉
〈⁄complexType〉


〈!--
End of schema.
--〉
〈⁄schema〉
END

6. Internationalization Considerations
EPP is represented in XML, which provides native support for encoding information using the Unicode character set and its more compact representations including UTF-8.

Conformant XML processors recognize both UTF-8 and UTF-16.

Though XML includes provisions to identify and use other character encodings through use of an ʺencodingʺ attribute in an 〈?xml?〉 declaration, use of UTF-8 is RECOMMENDED.

As an extension of the EPP domain name mapping, the elements, element content described in this document MUST inherit the internationalization conventions used to represent higher-layer domain and core protocol structures present in an XML instance that includes this extension.

7. IANA Considerations
This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688].

IANA is requested to assignment the following two URI.

Registration request for the CDN namespace:

o URI: urn:ietf:params:xml:ns:cdn-1.0

o Registrant Contact: See the ʺAuthorʹs Addressʺ section of this document.

o XML: None.
Namespace URI does not represent an XML specification.

Registration request for the CDN XML schema:

o URI: urn:ietf:params:xml:schema:cdn-1.0

o Registrant Contact: See the ʺAuthorʹs Addressʺ section of this document.

o XML: See the ʺFormal Syntaxʺ section of this document.

8. Security considerations
The object mapping extension described in this document does not provide any other security services or introduce any additional considerations beyond those described by [RFC5730] or those caused by the protocol layers used by EPP.

9. References
[RFC2119] Bradner, S., ʺKey words for use in RFCs to Indicate
Requirement Levelsʺ, BCP 14, RFC 2119, March 1997.

[RFC3492] Costello, A., ʺPunycode: A Bootstring encoding of Unicode
for Internationalized Domain Names in Applications
(IDNA)ʺ, RFC 3492, March 2003.

[RFC3688] Mealling, M., ʺThe IETF XML Registryʺ, BCP 81, RFC 3688,
January 2004.

[RFC5730] Hollenbeck, S., ʺExtensible Provisioning Protocol (EPP)ʺ,
STD 69, RFC 5730, August 2009.

[RFC5731] Hollenbeck, S., ʺExtensible Provisioning Protocol (EPP)
Domain Name Mappingʺ, STD 69, RFC 5731, August 2009.

[RFC5890] Klensin, J., ʺInternationalized Domain Names for
Applications (IDNA): Definitions and Document Frameworkʺ,
RFC 5890, August 2010.

[RFC5891] Klensin, J., ʺInternationalized Domain Names in
Applications (IDNA): Protocolʺ, RFC 5891, August 2010.

[RFC5892] Faltstrom, P., ʺThe Unicode Code Points and
Internationalized Domain Names for Applications (IDNA)ʺ,
RFC 5892, August 2010.

[W3C.REC-xml-20040204]
Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and
F. Yergeau, ʺʺExtensible Markup Language (XML) 1.0 (Third
Edition)ʺ, World Wide Web Consortium FirstEdition REC-
xml-20040204ʺ, February 2004,
〈http:⁄⁄www.w3.org⁄TR⁄2004⁄REC-xml-20040204〉.

[W3C.REC-xmlschema-1-20041028]
Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
ʺʺXML Schema Part 1: Structures Second Editionʺ, World
Wide Web Consortium Recommendation REC-xmlschema-1-
20041028ʺ, October 2004,
〈http:⁄⁄www.w3.org⁄TR⁄2004⁄REC-xmlschema-1-20041028〉.

[W3C.REC-xmlschema-2-20041028]
Biron, P. and A. Malhotra, ʺʺXML Schema Part 2: Datatypes
Second Editionʺ, World Wide Web Consortium Recommendation
REC-xmlschema-2-20041028ʺ, October 2004,
〈http:⁄⁄www.w3.org⁄TR⁄2004⁄REC-xmlschema-2-20041028〉.

Authorʹs Address

Zheng Wang
CONAC
JIA 31, North Guangximen, Xibahe, Chaoyang District
Beijing, Beijing 100028
China

Phone: +86 10 5203 5185
Email: wangzheng@conac.cn

Similar gTLD applications: (1)