Back

25 Extensible Provisioning Protocol (EPP)

gTLDFull Legal NameE-mail suffixDetail
.autoUniregistry, Corp.internet.proView
TABLE OF CONTENTS

25.1 EPP SERVICE
25.1.1 Standards Compliance
25.1.2 EPP Service Features
25.1.3 Service Architecture
25.2 EPP EXTENSIONS
25.2.1 Internationalized Domain Names
25.2.2 Launch Phase
25.3 RESOURCING PLANS
25.3.1 Human Resources
25.3.2 Technical Platform
25.3.3 Facilities
25.4 ABOUT THIS RESPONSE

〈〉 - - - - - 〈〉

25.1. EPP SERVICE

EPP service is the primary interface between registrars and registries. Our EPP service supports a high transaction volume.

Our other registrar-facing service interface is a web-based service that has some additional capabilities not present in EPP, but with lower transactional volume. This web-based service is described in our answer to question 23.

Our EPP service is extensible, robust, secure, accountable, scalable, and conforms to all relevant ICANN requirements, internet standards and published best practices.

Our EPP service is designed with simplicity and intelligence at the application level to facilitate the most demanding operational models.

We believe that for a high-volume critical service to succeed, it must be modular. Therefore we have designed and built our EPP service to use multiple geographically distributed servers. These servers are front-ended with security firewalls and high performance load balancers. These load balancers ensure that client requests are sent to the least busy (hence best) EPP server.

The load balancers also monitor individual EPP server performance metrics and availability. Thus, in the case of failure or maintenance, the load balancers will automatically stop routing new work to non-responsive EPP server(s) and spread that work among the best of the remaining servers. This substantially improves the scalability of the registry by making it a relatively easy and non-critical task to add or remove EPP servers without interrupting ongoing operations.

25.1.1. Standards Compliance

Our EPP server implements the following RFCs:

* RFC 5730 - Extensible Provisioning Protocol (EPP)
This RFC describes an application-layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration.
* RFC 5731 - Extensible Provisioning Protocol (EPP) Domain Name Mapping
This RFC describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names.
* RFC 5732 - Extensible Provisioning Protocol (EPP) Host Mapping
This RFC describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names.
* RFC 5733 - Extensible Provisioning Protocol (EPP) Contact Mapping
This RFC describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as ʺcontactsʺ) stored in a shared central repository. Specified in Extensible Markup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts.
* RFC 5734 - Extensible Provisioning Protocol (EPP) Transport over TCP;
This RFC describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server.
* RFC 5910 - Domain Name System (DNS) Security Extensions Mapping
This RFC describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain Name System security (DNSSEC) extensions for domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of DNS security extensions.
* RFC 3915 - Domain Registry Grace Period Mapping
This RFC describes an Extensible Provisioning Protocol (EPP) extension mapping for the management of Domain Name System (DNS) domain names subject to ʺgrace periodʺ policies defined by the Internet Corporation for Assigned Names and Numbers (ICANN). Grace period policies exist to allow protocol actions to be reversed or otherwise revoked during a short period of time after the protocol action has been performed. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for grace period processing.
* RFC 5646 - Tags for Identifying Languages
This RFC describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange.
For IDN support, our implementation uses the following RFCs as guidelines:

* RFC 3454 - Preparation of Internationalized Strings (ʺstringprepʺ);
This RFC describes a framework for preparing Unicode text strings in order to increase the likelihood that string input and string comparison work in ways that make sense for typical users throughout the world. The stringprep protocol is useful for protocol identifier values, company and personal names, internationalized domain names, and other text strings.
* RFC 5890 - Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework
This RFC is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set.
* RFC 5891 - Internationalized Domain Names in Applications (IDNA): Protocol
This RFC is the revised protocol definition for Internationalized Domain Names (IDNs). The rationale for changes, the relationship to the older specification, and important terminology are provided in other documents. This document specifies the protocol mechanism, called Internationalized Domain Names in Applications (IDNA), for registering and looking up IDNs in a way that does not require changes to the DNS itself. IDNA is only meant for processing domain names, not free text.
In addition to the above-mentioned published RFCs, we have implemented a custom extension to associate the domain name to a language tag, as required by ICANNʹs Registry Implementation Committee. The specification of that extension has been prepared as an experimental Internet draft, suitable for eventual IETF consideration for the standards track.

25.1.2. EPP Service Features

Our EPP implementation includes the following features:

* Both IPv6 and IPv4 transport and record support.
* Automatic load balancing among server instances.
* Geographic distribution of servers with diversity of communications paths to mitigate the extent of local or regional failures.
* Transaction journaling and statistics for both performance and transactions.
* Authentication: our EPP implementation uses a multi-factor system to authenticate registrars; the process is as follows:
** Source IP address is verified and checked against a whitelist at connection time;
** X.509 Certificate validation back to a known certificate issuing authority at TLSv1.2 session initiation; and
** User⁄Password authentication at the EPP level.
* All data transmitted over the network is encrypted using TLS v1.2.
* Well-formedness check: If at any given time, a command is sent to the server in a format other than proper well-formed XML, the server will drop the connection and de-authenticate the client. This protects against defective clients and adds a measure of protection against exploration by rogue users.
* XML Validation: every EPP command is validated against the associated XML Schema, as specified in the RFC or custom extension. When a client sends an XML command that does not pass the validation check, the EPP server sends the registrar a ʺSyntaxʺ error response signaling the inappropriate message format.
* Time Outs: Every session automatically times out after 15 seconds of client inactivity. Issuing an EPP ʺhelloʺ or ʺgreetingʺ command resets the time out counter, allowing the registrar to use it as a keep-alive method. Once the registrar has been authenticated, it is allowed to perform commands to manage the session, query and transform objects, as permitted by registry policy. When issuing a ʺlogoutʺ command, the server acknowledges it and terminates the session.
25.1.3. Service Architecture

25.1.3.1. Authentication

Service authentication is achieved using a multi level system to authenticate access to the EPP interface, as shown in the EXHIBIT ʺ25-Figure-EPP-Authentication.pngʺ.

By using three successive access control methods, we significantly improve the overall system security. Registrars wishing to use the EPP system must provide in advance the list of IPv4 and IPv6 addresses from which they will access the EPP Service. Each service request will be authenticated in the following manner:

* At the firewall level the system will check for source IP, comparing it to those in the registered Access Control Lists;
* Once the IP has been verified, the next step is to initiate the TLS session, which will trigger:
** Secure Channel communication
** Client X.509 certificate check, which must be signed by the registry-operated Certificate Authority (CA), and must not be in the revocation list;
* The registrar must authenticate itself to the EPP service with a user⁄password combination.
This multilayer approach to client authentication protects against many forms of unauthorized access.

25.1.3.2. Server Selection

Our system performs load balancing to send clients to the best available EPP server. This balancing is done as part of the DNS name resolution process when the client seeks to connect to an EPP server. Each load balancer continuously monitors performance metrics, such as server load and geographic location, to determine the best server binding for each incoming client. This choice is delivered to the client through the address records in the DNS response returned to the client when it looks up the EPP server by name.

EXHIBIT ʺ25-Figure-EPP-Network-Diagram.pngʺ, explains how the client is directed to the EPP Servers using DNS queries to which the response is determined by performance data.

Server selection description:

* Clients (Registrar A and B) initiate the process by sending a DNS query to EPP.[TLD].registry.isc.org, where [TLD] is the string that represents the top-level domain
* [TLD].registry.isc.org. is a sub-domain delegated to the load balancers, thus the queries are sent to one of the load balancers (it does not matter which load balancer receives the clientʹs query.);
* Each load balancer evaluates the performance metrics from all four EPP Servers, and decides which EPP server is the best fit and returns the IP address of that server to the client;
* Clients connect to the IP as supplied by the Load Balancer that handled its request, initiate the EPP connection, and perform the desired EPP operations using that IP address.
25.1.3.3. EPP Session Handling

The numbers on this diagram correspond to the numbers in the EXHIBIT ʺ25-Figure-EPP-Flow-Diagram.pngʺ:

Once the Registrar has passed the source-IP verification and the TLS X.509 certificate validation, the EPP session follows this life cycle:

* Registrar initiates a connection to the server on TCP port 700 (EPP Port);
* The server replies with an EPP ʺgreetingʺ response, displaying the namespaces for objects and extensions available on the system;
* The Client processes the greeting and sends an EPP ʺloginʺ command with its credentials (user⁄password), along with the namespaces of the extensions that it wishes to use during this session;
* The EPP server checks the credentials against the Back-end system, and answers either with an EPP success or failure response;
* The registrar evaluates the authentication response from the server. In case it is a failure, it has the option of either disconnecting itself, timing out, or to try sending new authentication credentials again (step 3);
* If authentication succeeds, the client reads the next available command from its command queue and forwards it to the EPP Server;
* The server processes the command and responds back to the client with the requested data, confirmation receipt or EPP failure response;
* The client will then read another command from its queue; if that queue is empty, it will send an EPP ʺlogoutʺ command
* If the command requested was an EPP ʺlogoutʺ the server disconnects the client after sending the EPP success⁄ending session response back to the client.
25.2. EPP EXTENSIONS

25.2.1. Internationalized Domain Names

See EXHIBIT ʺ25-EXHIBIT-EPP-IDN.pdfʺ

25.2.2. Launch Phase

Domain registries typically operate in special modes within certain periods of time to facilitate allocation of domain names for a subset of the zone namespace that becomes available. This document uses the term ʺlaunch phaseʺ to refer to such a period.

The EPP domain name mapping RFC5731 is designed for the steady state operation of a registry. During a launch phase, registries typically accept multiple applications for a given domain name. This document proposes an extension to the domain name application in order to unambiguously manage the received applications.

See EXHIBIT ʺ25-EXHIBIT-EPP-LaunchPhase.pdfʺ

25.3. RESOURCING PLANS

Costs and procurement of the resources described here are detailed in response to Question 47.

25.3.1. Human Resources

See EXHIBIT: ʺ25-Chart-Resourcing.pngʺ

The resourcing plan specific to this response follows the principles, guidelines and information set forth in our response to Question 23.

The accompanying chart shows the human resources allocated to the functions depicted in this response.

25.3.2. Technical Platform

A total of four (4) high performance servers will be made available to registrars to interact with the registry. Provisioning of additional servers is a straightforward procedure that can be triggered by demand thresholds, which is currently set a eighty percent (80%) of the systemʹs total capacity. Provision of additional EPP servers does not disrupt ongoing operations.

Each of the registry locations, Palo Alto and Chicago, will, by itself, be able to sustain the entire estimated traffic level. Nevertheless, we expect that traffic load will remain equally distributed among them to provide a better user experience.

In addition, the Registry Operations Center will be monitoring source traffic to gather data that can be used to plan the location of potential new sites aimed when expansion becomes necessary.

25.3.3. Facilities

Two carrier grade data centers will be used to host the registry platform:

* Palo Alto Internet Exchange (PAIX) in Palo Alto, CA, operated by Equinix; and
* Equinix Co-location in Chicago, IL.
Although the sites have not yet been provisioned, the plan for the deployment of the registry takes into consideration the contracting of the datacenter space in mid 2012 so that it is fully provisioned by the time of delegation.

Each facility must cover the following criteria:

25.3.3.1. Power

Provide a minimum N+1 redundancy for every power system, to maximize uptime availability.

Uninterruptible Power Supply (UPS) systems to prevent power spikes, surges, and brownouts, and redundant backup diesel generators provide additional runtime.

Provide continuous monitoring of all power system components on-site or remotely, to respond quickly to any situations.

25.3.3.2. Cooling

Includes a robust HVAC system to provide stable airflow, temperature and humidity, with minimum N+1 redundancy for all major equipment.

Representative Specifications:

* 13,652 BTUH per cabinet
* Six (6) 750-ton centrifugal chillers
* Six (6) variable primary chilled water pumps
* Six (6) condenser pumps
* Six (6) cooling towers
* 24 air handling units in the colocation area
25.3.3.3. Flood Control

Built above sea level with no basements and have the following flood control features:

* Moisture barriers on exterior walls
* Dedicated pump rooms
* Drainage⁄evacuation systems
* Moisture detection sensors
25.3.3.4. Fire Detection and Suppression

Key features of the fire detection and suppression system must include:

* Multi-zoned, dry-pipe, double-interlock, pre-action fire suppression system
* Very Early Smoke Detection and Alarm (VESDA)
25.3.3.5. Earthquake

Must meet or exceed local building codes for lateral seismic design forces. Equipment and nonstructural components, including cabinets, are anchored and braced.

25.4. ABOUT THIS RESPONSE

This answer meets the requirements of this question:

* Our EPP protocols, interfaces, and data conform to all relevant internet standards, best practices, and RFCs.
* Our EPP service is highly robust and scalable, with dynamic load balancing, geographic distribution, high levels of security and access control, and fast fail-over.
* We have defined an EPP extension (to support internationalized names) in conformance with all relevant internet standards and RFCs. We will be submitting this extension to the IETF.
* That EPP extension is documented fully in this answer.
* That EPP extension is fully integrated into our registry technical approach and operations; it has no significant financial or resource impact.
* Our EPP service in conjunction with the EPP extensions defined here are consistent with the technical, operational, and financial approach as described in this application.
* Many of the needed technical resources (computers, network access, software, facilities, and management) are either already on-hand (and in some cases are already operational). Other technical resources are easily acquired as commercial off-the-shelf (COTS) items (such as servers, firewalls, and routers.) We already have presence in several data centers. And we already have the financial and staff resources.
gTLDFull Legal NameE-mail suffixDetail
.designUniregistry, Corp.uniregistry.comView
TABLE OF CONTENTS

25.1 EPP SERVICE
25.1.1 Standards Compliance
25.1.2 EPP Service Features
25.1.3 Service Architecture
25.2 EPP EXTENSIONS
25.2.1 Internationalized Domain Names
25.2.2 Launch Phase
25.3 RESOURCING PLANS
25.3.1 Human Resources
25.3.2 Technical Platform
25.3.3 Facilities
25.4 ABOUT THIS RESPONSE

- - - - -

25.1. EPP SERVICE

EPP service is the primary interface between registrars and registries. Our EPP service supports a high transaction volume.

Our other registrar-facing service interface is a web-based service that has some additional capabilities not present in EPP, but with lower transactional volume. This web-based service is described in our answer to question 23.

Our EPP service is extensible, robust, secure, accountable, scalable, and conforms to all relevant ICANN requirements, internet standards and published best practices.

Our EPP service is designed with simplicity and intelligence at the application level to facilitate the most demanding operational models.

We believe that for a high-volume critical service to succeed, it must be modular. Therefore we have designed and built our EPP service to use multiple geographically distributed servers. These servers are front-ended with security firewalls and high performance load balancers. These load balancers ensure that client requests are sent to the least busy (hence best) EPP server.

The load balancers also monitor individual EPP server performance metrics and availability. Thus, in the case of failure or maintenance, the load balancers will automatically stop routing new work to non-responsive EPP server(s) and spread that work among the best of the remaining servers. This substantially improves the scalability of the registry by making it a relatively easy and non-critical task to add or remove EPP servers without interrupting ongoing operations.

25.1.1. Standards Compliance

Our EPP server implements the following RFCs:

* RFC 5730 - Extensible Provisioning Protocol (EPP)

This RFC describes an application-layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration.
* RFC 5731 - Extensible Provisioning Protocol (EPP) Domain Name Mapping

This RFC describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names.
* RFC 5732 - Extensible Provisioning Protocol (EPP) Host Mapping

This RFC describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names.
* RFC 5733 - Extensible Provisioning Protocol (EPP) Contact Mapping

This RFC describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as ʺcontactsʺ) stored in a shared central repository. Specified in Extensible Markup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts.
* RFC 5734 - Extensible Provisioning Protocol (EPP) Transport over TCP;

This RFC describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server.
* RFC 5910 - Domain Name System (DNS) Security Extensions Mapping

This RFC describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain Name System security (DNSSEC) extensions for domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of DNS security extensions.
* RFC 3915 - Domain Registry Grace Period Mapping

This RFC describes an Extensible Provisioning Protocol (EPP) extension mapping for the management of Domain Name System (DNS) domain names subject to ʺgrace periodʺ policies defined by the Internet Corporation for Assigned Names and Numbers (ICANN). Grace period policies exist to allow protocol actions to be reversed or otherwise revoked during a short period of time after the protocol action has been performed. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for grace period processing.
* RFC 5646 - Tags for Identifying Languages

This RFC describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange.
For IDN support, our implementation uses the following RFCs as guidelines:

* RFC 3454 - Preparation of Internationalized Strings (ʺstringprepʺ);

This RFC describes a framework for preparing Unicode text strings in order to increase the likelihood that string input and string comparison work in ways that make sense for typical users throughout the world. The stringprep protocol is useful for protocol identifier values, company and personal names, internationalized domain names, and other text strings.
* RFC 5890 - Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework

This RFC is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set.
* RFC 5891 - Internationalized Domain Names in Applications (IDNA): Protocol

This RFC is the revised protocol definition for Internationalized Domain Names (IDNs). The rationale for changes, the relationship to the older specification, and important terminology are provided in other documents. This document specifies the protocol mechanism, called Internationalized Domain Names in Applications (IDNA), for registering and looking up IDNs in a way that does not require changes to the DNS itself. IDNA is only meant for processing domain names, not free text.
In addition to the above-mentioned published RFCs, we have implemented a custom extension to associate the domain name to a language tag, as required by ICANNʹs Registry Implementation Committee. The specification of that extension has been prepared as an experimental Internet draft, suitable for eventual IETF consideration for the standards track.

25.1.2. EPP Service Features

Our EPP implementation includes the following features:

* Both IPv6 and IPv4 transport and record support.
* Automatic load balancing among server instances.
* Geographic distribution of servers with diversity of communications paths to mitigate the extent of local or regional failures.
* Transaction journaling and statistics for both performance and transactions.
* Authentication: our EPP implementation uses a multi-factor system to authenticate registrars; the process is as follows:
** Source IP address is verified and checked against a whitelist at connection time;
** X.509 Certificate validation back to a known certificate issuing authority at TLSv1.2 session initiation; and
** User⁄Password authentication at the EPP level.
* All data transmitted over the network is encrypted using TLS v1.2.
* Well-formedness check: If at any given time, a command is sent to the server in a format other than proper well-formed XML, the server will drop the connection and de-authenticate the client. This protects against defective clients and adds a measure of protection against exploration by rogue users.
* XML Validation: every EPP command is validated against the associated XML Schema, as specified in the RFC or custom extension. When a client sends an XML command that does not pass the validation check, the EPP server sends the registrar a ʺSyntaxʺ error response signaling the inappropriate message format.
* Time Outs: Every session automatically times out after 15 seconds of client inactivity. Issuing an EPP ʺhelloʺ or ʺgreetingʺ command resets the time out counter, allowing the registrar to use it as a keep-alive method. Once the registrar has been authenticated, it is allowed to perform commands to manage the session, query and transform objects, as permitted by registry policy. When issuing a ʺlogoutʺ command, the server acknowledges it and terminates the session.

25.1.3. Service Architecture

25.1.3.1. Authentication

Service authentication is achieved using a multi level system to authenticate access to the EPP interface, as shown in the EXHIBIT ʺ25-Figure-EPP-Authentication.pngʺ.

By using three successive access control methods, we significantly improve the overall system security. Registrars wishing to use the EPP system must provide in advance the list of IPv4 and IPv6 addresses from which they will access the EPP Service. Each service request will be authenticated in the following manner:

* At the firewall level the system will check for source IP, comparing it to those in the registered Access Control Lists;
* Once the IP has been verified, the next step is to initiate the TLS session, which will trigger:
** Secure Channel communication
** Client X.509 certificate check, which must be signed by the registry-operated Certificate Authority (CA), and must not be in the revocation list;
* The registrar must authenticate itself to the EPP service with a user⁄password combination.

This multilayer approach to client authentication protects against many forms of unauthorized access.

25.1.3.2. Server Selection

Our system performs load balancing to send clients to the best available EPP server. This balancing is done as part of the DNS name resolution process when the client seeks to connect to an EPP server. Each load balancer continuously monitors performance metrics, such as server load and geographic location, to determine the best server binding for each incoming client. This choice is delivered to the client through the address records in the DNS response returned to the client when it looks up the EPP server by name.

EXHIBIT ʺ25-Figure-EPP-Network-Diagram.pngʺ, explains how the client is directed to the EPP Servers using DNS queries to which the response is determined by performance data.

Server selection description:

* Clients (Registrar A and B) initiate the process by sending a DNS query to EPP.[TLD].registry.isc.org, where [TLD] is the string that represents the top-level domain
* [TLD].registry.isc.org. is a sub-domain delegated to the load balancers, thus the queries are sent to one of the load balancers (it does not matter which load balancer receives the clientʹs query.);
* Each load balancer evaluates the performance metrics from all four EPP Servers, and decides which EPP server is the best fit and returns the IP address of that server to the client;
* Clients connect to the IP as supplied by the Load Balancer that handled its request, initiate the EPP connection, and perform the desired EPP operations using that IP address.

25.1.3.3. EPP Session Handling

The numbers on this diagram correspond to the numbers in the EXHIBIT ʺ25-Figure-EPP-Flow-Diagram.pngʺ:

Once the Registrar has passed the source-IP verification and the TLS X.509 certificate validation, the EPP session follows this life cycle:

* Registrar initiates a connection to the server on TCP port 700 (EPP Port);
* The server replies with an EPP ʺgreetingʺ response, displaying the namespaces for objects and extensions available on the system;
* The Client processes the greeting and sends an EPP ʺloginʺ command with its credentials (user⁄password), along with the namespaces of the extensions that it wishes to use during this session;
* The EPP server checks the credentials against the Back-end system, and answers either with an EPP success or failure response;
* The registrar evaluates the authentication response from the server. In case it is a failure, it has the option of either disconnecting itself, timing out, or to try sending new authentication credentials again (step 3);
* If authentication succeeds, the client reads the next available command from its command queue and forwards it to the EPP Server;
* The server processes the command and responds back to the client with the requested data, confirmation receipt or EPP failure response;
* The client will then read another command from its queue; if that queue is empty, it will send an EPP ʺlogoutʺ command
* If the command requested was an EPP ʺlogoutʺ the server disconnects the client after sending the EPP success⁄ending session response back to the client.

25.2. EPP EXTENSIONS

25.2.1. Internationalized Domain Names

See EXHIBIT ʺ25-EXHIBIT-EPP-IDN.pdfʺ

25.2.2. Launch Phase

Domain registries typically operate in special modes within certain periods of time to facilitate allocation of domain names for a subset of the zone namespace that becomes available. This document uses the term ʺlaunch phaseʺ to refer to such a period.

The EPP domain name mapping RFC5731 is designed for the steady state operation of a registry. During a launch phase, registries typically accept multiple applications for a given domain name. This document proposes an extension to the domain name application in order to unambiguously manage the received applications.

See EXHIBIT ʺ25-EXHIBIT-EPP-LaunchPhase.pdfʺ

25.3. RESOURCING PLANS

Costs and procurement of the resources described here are detailed in response to Question 47.

25.3.1. Human Resources

See EXHIBIT: ʺ25-Chart-Resourcing.pngʺ

The resourcing plan specific to this response follows the principles, guidelines and information set forth in our response to Question 23.

The accompanying chart shows the human resources allocated to the functions depicted in this response.

25.3.2. Technical Platform

A total of four (4) high performance servers will be made available to registrars to interact with the registry. Provisioning of additional servers is a straightforward procedure that can be triggered by demand thresholds, which is currently set a eighty percent (80%) of the systemʹs total capacity. Provision of additional EPP servers does not disrupt ongoing operations.

Each of the registry locations, Palo Alto and Chicago, will, by itself, be able to sustain the entire estimated traffic level. Nevertheless, we expect that traffic load will remain equally distributed among them to provide a better user experience.

In addition, the Registry Operations Center will be monitoring source traffic to gather data that can be used to plan the location of potential new sites aimed when expansion becomes necessary.

25.3.3. Facilities

Two carrier grade data centers will be used to host the registry platform:

* Palo Alto Internet Exchange (PAIX) in Palo Alto, CA, operated by Equinix; and
* Equinix Co-location in Chicago, IL.

Although the sites have not yet been provisioned, the plan for the deployment of the registry takes into consideration the contracting of the datacenter space in mid 2012 so that it is fully provisioned by the time of delegation.

Each facility must cover the following criteria:

25.3.3.1. Power

Provide a minimum N+1 redundancy for every power system, to maximize uptime availability.

Uninterruptible Power Supply (UPS) systems to prevent power spikes, surges, and brownouts, and redundant backup diesel generators provide additional runtime.

Provide continuous monitoring of all power system components on-site or remotely, to respond quickly to any situations.

25.3.3.2. Cooling

Includes a robust HVAC system to provide stable airflow, temperature and humidity, with minimum N+1 redundancy for all major equipment.

Representative Specifications:

* 13,652 BTUH per cabinet
* Six (6) 750-ton centrifugal chillers
* Six (6) variable primary chilled water pumps
* Six (6) condenser pumps
* Six (6) cooling towers
* 24 air handling units in the colocation area

25.3.3.3. Flood Control

Built above sea level with no basements and have the following flood control features:

* Moisture barriers on exterior walls
* Dedicated pump rooms
* Drainage⁄evacuation systems
* Moisture detection sensors

25.3.3.4. Fire Detection and Suppression

Key features of the fire detection and suppression system must include:

* Multi-zoned, dry-pipe, double-interlock, pre-action fire suppression system
* Very Early Smoke Detection and Alarm (VESDA)

25.3.3.5. Earthquake

Must meet or exceed local building codes for lateral seismic design forces. Equipment and nonstructural components, including cabinets, are anchored and braced.

25.4. ABOUT THIS RESPONSE

This answer meets the requirements of this question:

* Our EPP protocols, interfaces, and data conform to all relevant internet standards, best practices, and RFCs.
* Our EPP service is highly robust and scalable, with dynamic load balancing, geographic distribution, high levels of security and access control, and fast fail-over.
* We have defined an EPP extension (to support internationalized names) in conformance with all relevant internet standards and RFCs. We will be submitting this extension to the IETF.
* That EPP extension is documented fully in this answer.
* That EPP extension is fully integrated into our registry technical approach and operations; it has no significant financial or resource impact.
* Our EPP service in conjunction with the EPP extensions defined here are consistent with the technical, operational, and financial approach as described in this application.
* Many of the needed technical resources (computers, network access, software, facilities, and management) are either already on-hand (and in some cases are already operational). Other technical resources are easily acquired as commercial off-the-shelf (COTS) items (such as servers, firewalls, and routers.) We already have presence in several data centers. And we already have the financial and staff resources.