gTLD	Full Legal Name	E-mail suffix	Detail
.boston	The Boston Globe Newspaper Company Inc.	boston.com	View

1. Overview
The Registry Operator will comply with the latest version of the Extensible Provisioning Protocol (EPP). The domain name Registry is designed to strict EPP standards from the ground up. No proprietary EPP extensions have been developed. Upon selection of the Trademark Clearinghouse (TMCH) provider by ICANN, the EPP implementation will be complemented with an interface towards the TMCH, in line with community defined interface specifications.

2. EPP Registry – Registrar Model
The domain name Registry implementation features a ʺthickʺ model as represented by the rich object store managed by the centralized domain name Registry.
This object store can be managed by accredited Registrars via the EPP interface that will be using the interface protocol specified by the current EPP standard.
The EPP specification is broken up into an extensible object design with each of the primary objects given an individual but consistent interface that meet the base EPP framework as described below.

2.1. EPP Protocol Highlights

2.1.1. RFC 5730 - Extensible Provisioning Protocol (EPP)
This document describes the foundation upon which all the specific objects (Domain names, Hosts, Contacts) must adhere to in order to maintain a consistent interface. A standard domain name Registry specific extensible object management framework is also described in this document to handle any extra information need to satisfy policy or other agreements the domain name Registry may be required to sustain.

2.1.2. RFC 5731 - Extensible Provisioning Protocol (EPP) Domain Name Mapping
This document describes an 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.

2.1.3. RFC 5732 - Extensible Provisioning Protocol (EPP) Host Mapping
This document describes an 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.

2.1.4. RFC 5733 - Extensible Provisioning Protocol (EPP) Contact Mapping
This document describes an EPP mapping for the provisioning and management of identifiers representing individuals or organizations (known as ʺcontactsʺ) stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to contacts.

2.1.5. RFC 5734 - Extensible Provisioning Protocol (EPP) Transport over Transmission Control Protocol (TCP)
This document dictates the TCP connection strategies to use. The implemented transport layer is conform to RFC 5734 and RFC 2246. RFC 5734 specifies the low level transport and allows for a typical TCP connection to be used to serve as a client-server communication channel. To secure the communication between client and server, an obligatory Transport Layer Security (TLS) layer is run on top of the TCP connection, as specified in RFC 2246.
A number of security settings no longer comply with current security needs and are prohibited in RFC 6176. The security algorithms that are allowed to communicate were chosen to be secure and compliant with a wide variety of implementations currently in use on most operating systems. These security algorithms include Advanced Encryption Standard (AES) and Triple Data Encryption Standard (TripleDES) for encryption and RSA for negotiation.

2.1.6. RFC 5910 - Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)
This document describes the DNSSEC Extensions Mapping for EPP for the provisioning and management of DNS security extensions stored in a shared central repository. Specified in XML, the mapping defines EPP DNSSEC extensions to the command syntax and semantics as applied to domain names.

2.1.7. RFC 3915 - Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)
This document describes the Registry Grace Period (RGP) Extensions Mapping for EPP for the management of domain names subject to “grace period” policies defined by ICANN. Specified in XML, the mapping defines EPP RGP extensions to the command syntax and semantics as applied to domains.

2.2. Supported Command Set
A full set of EPP commands is implemented, as specified in the above mentioned RFCs. The EPP service provides all commands specified in the RFCs 5730, 5731, 5732, 5733, 3915 and 5910 in a fully functional fashion. The commands are implemented conform the specifications set forth in the RFCs. The fully compliant XSD schema describing the XML layout which can be used to validate the XML command can be found in RFC 5730-5733, 3915 and 5910.
Please note that two extensions are implemented:
1) RFC 3915 is a specific extension to implement the “grace period” policies, both in providing extra information to the Registrar, as well as the possibility to restore a domain name from redemption.
2) RFC 5910 is a specific description to comply with the DNSSEC extension, as is required by the Applicant Guidebook, to manage the DNSSEC keys of the domain name.
The domain name Registry will provide the following command sets to support the Registry Service:
1) Greeting
2) Session management
3) Object Query
4) Object Transform
All commands from the EPP client to the EPP server run over an encrypted connection. The EPP client has to identify itself by using the predefined session management command 〈login〉 using unique and out-of-band communicated credentials.
The command sets are described in detail below.

2.2.1. Greeting
The EPP server will respond to a successful connection by returning a greeting to the client. The greeting response includes information such as:
1) The name of the server
2) The serverʹs current date and time in Coordinated Standard Time (UTC)
3) The features supported by this server, which may include:
a) One or more protocol versions supported by the server
b) One or more languages for the text response supported by the server
c) One or more 〈objURI〉 elements which identify the objects which the server is capable of managing
d) An optional 〈svcExtension〉 element that contains one or more 〈extURI〉 elements that contain namespace URIs representing object extensions supported by the server. Here the EPP server will announce support for rgp-1.0 (as defined in RFC 3915) and for secDNS-1.1 (as defined in RFC 5910).
At any time a 〈hello〉 command can be used to receive a 〈greeting〉 response.

2.2.2. Session Management
EPP provides two commands for session management: 〈login〉 to establish a session with a server, and 〈logout〉 to end a session with a server.
1) Login: The EPP 〈login〉 command is used to establish a session with an EPP server in response to a greeting issued by the server. A 〈login〉 command MUST be sent to a server before any other EPP command.
2) Logout: The EPP 〈logout〉 command is used to end a session with an EPP server.

2.2.3. Object Query Commands
EPP provides three commands to retrieve object information:
〈info〉 to retrieve detailed information associated with a known object,
〈check〉 to determine if an object is known to the server, and
〈transfer〉 to retrieve known object transfer status information. These are described into further detail below.
1) Info: The EPP 〈info〉 command is used to retrieve information associated with a known object. The elements needed to identify an object and the type of information associated with an object are both object-specific, so the child elements of the 〈info〉 command are specified using the EPP extension framework.
2) Check: The EPP 〈check〉 command is used to determine if an object is known to the server. The elements needed to identify an object are object-specific, so the child elements of the 〈check〉 command are specified using the EPP extension framework.
3) Poll: The EPP 〈poll〉 command is used to discover and retrieve notification messages queued by the server for individual Registrars. Some elements are object-specific, so the child elements of the 〈poll〉 response are specified using the EPP extension framework.
4) Transfer (Query): The EPP 〈transfer〉 command provides a query operation that allows a client to determine real-time status of pending and completed transfer requests. The elements needed to identify an object that is the subject of a transfer request are object-specific, so the child elements of the 〈transfer〉 query command are specified using the EPP extension framework.

2.2.4. Object Transform Commands
EPP provides five commands to transform objects:
〈create〉 to create an instance of an object with a server,
〈delete〉 to remove an instance of an object from a server,
〈renew〉 to extend the validity period of an object,
〈update〉 to change information associated with an object, and
〈transfer〉 to manage changes in client sponsorship of a known object. These are described into further detail below.
1) Create: The EPP 〈create〉 command is used to create an instance of an object. An object may be created for an indefinite period of time, or an object may be created for a specific validity period. The EPP mapping for an object MUST describe the status of an object with respect to time, to include expected client and server behavior if a validity period is used.
2) Delete: The EPP 〈delete〉 command is used to remove an instance of a known object. The elements needed to identify an object are object-specific, therefore the child elements of the 〈delete〉 command are specified using the EPP extension framework.
3) Renew: The EPP 〈renew〉 command is used to extend the validity period of an object. The elements needed to identify and extend the validity period of an object are object-specific, therefor the child elements of the 〈renew〉 command are specified using the EPP extension framework.
4) Transfer: The EPP 〈transfer〉 command is used to manage changes in client sponsorship of a known object. Clients may initiate a transfer request, cancel a transfer request, approve a transfer request, and reject a transfer request.
5) Update: The EPP 〈update〉 command is used to change information associated with a known object. The elements needed to identify and modify an object are object-specific, therefore the child elements of the 〈update〉 command are specified using the EPP extension framework.
All above transform commands can be processed by the Registry Operator in two ways:
1) immediately process the requested action;
2) initiate processing the requested action, but allow for off-line review or further interaction before completing the requested action. The response of the EPP server will clearly note that the requested action is “pending”.
In the latter case the state of the corresponding object will clearly reflect processing of the pending action. For more information on the domain name states, reference is made to the response to Question 27 (Domain Name Lifecycle).

2.3. Functionality to provision Registry services
To comply with the current EPP standard, a fully functional set of commands is at the Registrar’s disposal. These functions are based on the CRUD (Create – Read – Update – Delete) principle. The state of the data is maintained by creating (C), reading (R), updating (U) and eventually deleting (D) the data from the database.
The following basic objects exist in the database:
1) Domain: The domain object contains all relevant information to the domain name. This includes registration date, renewal date, status and DNSSEC key material.
2) Host: A host object defines a hostname which might be linked to a domain name. It is intrinsically needed to get the domain name working. It contains at least a domain name, possibly IP addresses and other references.
3) Contact: The contact object specifies a person or an organization. It contains various fields to identify such party. When linked to a domain name, a specific role is attributed to the relation.
The following commands, per object, allow for the full CRUD cycle to be implemented conform the above specified relevant RFCʹs. Please note that the read commands as referred to in the CRUD terminology are defined as query commands in the EPP-centric documentation. All objects are attributed to a specific Registrar and remain under its supervision. No other Registrar is granted access to these objects.
Registrars should first verify if the object is manageable (and owned) by using the 〈check〉 command. To get the content of an object, use the 〈info〉 command.
(View attachment for Table 1: Commands per object type)
By assigning a Registrar to all objects, a unique identifiable party is assigned to any object as the owner that is allowed to change and delete the object. To maintain a history of all changes, both a full trace log identifying Registrar, IP address, time and command as well as a history of the objects are stored in the database. This allows for a swift reconstruction of any interaction with the system. For more information we refer to the response to Question 33 of the evaluation criteria (Database Capabilities).

3. EPP Extensions
In order to be compliant with ICANNʹs Applicant Guidebook, an additional extension to maintain the domain object is needed to integrate with the Trademark ClearingHouse (Module V of ICANN’s Applicant Guidebook).
At the moment, no party has been appointed to perform the TradeMark Clearinghouse function, hence no specifications for interfacing have been established.
The function of the TradeMark Clearinghouse is to enable trademark holders to register their right in a central database, from where the trademark holder receives a validation code that can be used to apply for a domain name in a new TLD.
To that extent, ongoing community effort led already to a Launch Phase Mapping for EPP. This Internet-Draft describes an extension mapping for EPP that specifies a flexible scheme that can be used to implement several common use cases related to the provisioning and management of launch phase extension in a domain name Registry.
This mapping enables the Registrar to apply for⁄claim a domain name in the sunrise phase using the Pre-Validation Result Code 〈pvrc〉 from the TM Clearinghouse.

4. Security
It is imperative to make sure the service is not blocked by Denial Of Service attacks (DOS). To prevent this from happening, a number of security barriers are in place:
1) rate limiting the number of connections on the border router;
2) allowing only specific IP addresses specified by the Registrar;
3) limiting the number of concurrent connections per Registrar.
The EPP service will run on its own virtual machine. Resources available to the machine are constantly monitored. Early warnings are sent out in case any of the resources are deemed to be inadequately provisioned.
Security is enhanced by limiting the access to the EPP server to a Transport Layer Security (TLS) connection using high-grade encryption.
The Registrar is authenticated using the predefined session commands as defined in the above RFCs. The initial credentials are exchanged between the Registry Operator and the Registrar over an out-of-band channel.
A strict object-to-Registrar link exists such that a Registrar can only view, access and modify its own managed objects.

5. Resourcing Plan

5.1. Technical Resources
This service is delivered by a JAVA application running on a TOMCAT server. To ensure the database is consistent at all times, a lock is set per Registrar to ensure multiple connections set up by a Registrar are serialized at the application level. To maintain high speed at all time, a locking mechanism is also active at the domain name level, ensuring no two domain name registrations for the same domain name are modified, while still allowing the necessary concurrency.
Experience has learned that, under high load conditions, the bottleneck will rather be located at the database level, and not at the application level. If extra CPU power is required to deal with high volumes, an extra EPP service will be provided using an alternate IP address or using a load balancer.
To improve database security, the EPP serverʹs access to the database is limited to a specific separate network. For a more complete and detailed picture, reference is made to the response to Question 32 of the evaluation criteria (System & Network Architecture).

5.2. Personnel
With regards to resourcing, reference is made to the global resourcing scheme as part of response to Question 31 (Technical Overview of the Proposed Registry). Implementation and maintenance of the Extensible Provisioning Protocol is under the authority of the Software Developer, under control of the Operations Manager. The technical infrastructure is implemented and maintained by the Network & System Administrator.

gTLD	Full Legal Name	E-mail suffix	Detail
.med	HEXAP SAS	hexap.com	View

1. OVERVIEW

The Registry Operator will comply with the latest version of the Extensible
Provisioning Protocol (EPP). The domain name Registry is designed to strict
EPP standards from the ground up. No proprietary EPP extensions have been
developed. Upon selection of the Trademark Clearinghouse (TMCH) provider by
ICANN, the EPP implementation will be complemented with an interface towards
the TMCH, in line with community defined interface specifications.

2. EPP REGISTRY – REGISTRAR MODEL

The domain name registry implementation features a ʺthickʺ model as
represented by the rich object store managed by the centralized domain name
registry.

This object store can be managed by accredited Registrars via the EPP
interface that will be using the interface protocol specified by the current
EPP standard.

The EPP specification is broken up into an extensible object design with
each of the primary objects given an individual but consistent interface
that meet the base EPP framework as described below.

2.1. EPP PROTOCOL HIGHLIGHTS

2.1.1. RFC 5730 - EXTENSIBLE PROVISIONING PROTOCOL (EPP)

This document describes the foundation upon which all the specific objects
(Domain names, Hosts, Contacts) must adhere to in order to maintain a
consistent interface. A standard domain name registry specific extensible
object management framework is also described in this document to handle any
extra information need to satisfy policy or other agreements the domain name
registry may be required to sustain.

2.1.2. RFC 5731 - EXTENSIBLE PROVISIONING PROTOCOL (EPP) DOMAIN NAME MAPPING

This document describes an 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.

2.1.3. RFC 5732 - EXTENSIBLE PROVISIONING PROTOCOL (EPP) HOST MAPPING

This document describes an 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.

2.1.4. RFC 5733 - EXTENSIBLE PROVISIONING PROTOCOL (EPP) CONTACT MAPPING

This document describes an EPP mapping for the provisioning and management
of identifiers representing individuals or organizations (known as
ʺcontactsʺ) stored in a shared central repository. Specified in XML, the
mapping defines EPP command syntax and semantics as applied to contacts.

2.1.5. RFC 5734 - EXTENSIBLE PROVISIONING PROTOCOL (EPP) TRANSPORT OVER
TRANSMISSION CONTROL PROTOCOL (TCP)

This document dictates the TCP connection strategies to use. The implemented
transport layer is conform to RFC 5734 and RFC 2246. RFC 5734 specifies the
low level transport and allows for a typical TCP connection to be used to
serve as a client-server communication channel. To secure the communication
between client and server, an obligatory Transport Layer Security (TLS)
layer is run on top of the TCP connection, as specified in RFC 2246.

A number of security settings no longer comply with current security needs
and are prohibited in RFC 6176. The security algorithms that are allowed to
communicate were chosen to be secure and compliant with a wide variety of
implementations currently in use on most operating systems. These security
algorithms include Advanced Encryption Standard (AES) and Triple Data
Encryption Standard (TripleDES) for encryption and RSA for negotiation.

2.1.6. RFC 5910 - DOMAIN NAME SYSTEM (DNS) SECURITY EXTENSIONS MAPPING FOR THE
EXTENSIBLE PROVISIONING PROTOCOL (EPP)

This document describes the DNSSEC Extensions Mapping for EPP for the
provisioning and management of DNS security extensions stored in a shared
central repository. Specified in XML, the mapping defines EPP DNSSEC
extensions to the command syntax and semantics as applied to domain names.

2.1.7. RFC 3915 - DOMAIN REGISTRY GRACE PERIOD MAPPING FOR THE EXTENSIBLE
PROVISIONING PROTOCOL (EPP)

This document describes the Registry Grace Period (RGP) Extensions Mapping
for EPP for the management of domain names subject to ʺgrace periodʺ
policies defined by ICANN. Specified in XML, the mapping defines EPP RGP
extensions to the command syntax and semantics as applied to domains.

2.2. SUPPORTED COMMAND SET

A full set of EPP commands is implemented, as specified in the above
mentioned RFCs. The EPP service provides all commands specified in the RFCs
5730, 5731, 5732, 5733, 3915 and 5910 in a fully functional fashion. The
commands are implemented conform the specifications set forth in the RFCs.
The fully compliant XSD schema describing the XML layout which can be used
to validate the XML command can be found in RFC 5730-5733, 3915 and 5910.

Please note that two extensions are implemented:

- RFC 3915 is a specific extension to implement the ʺgrace periodʺ policies,
both in providing extra information to the Registrar, as well as the
possibility to restore a domain name from redemption.

- RFC 5910 is a specific description to comply with the DNSSEC extension, as
is required by the Applicant Guidebook, to manage the DNSSEC keys of the
domain name.

The domain name registry will provide the following command sets to support
the Registry Service:

- Greeting

- Session management

- Object Query

- Object Transform

All commands from the EPP client to the EPP server run over an encrypted
connection. The EPP client has to identify itself by using the predefined
session management command 〈login〉 using unique and out-of-band communicated
credentials.

The command sets are described in detail below.

2.2.1. GREETING

The EPP server will respond to a successful connection by returning a
greeting to the client. The greeting response includes information such as:

- The name of the server

- The serverʹs current date and time in Coordinated Standard Time (UTC)

- The features supported by this server, which may include:

* One or more protocol versions supported by the server

* One or more languages for the text response supported by the server

* One or more 〈objURI〉 elements which identify the objects which the
server is capable of managing

* An optional 〈svcExtension〉 element that contains one or more 〈extURI〉
elements that contain namespace URIs representing object extensions
supported by the server. Here the EPP server will announce support for
rgp-1.0 (as defined in RFC 3915) and for secDNS-1.1 (as defined in RFC
5910).

At any time a 〈hello〉 command can be used to receive a 〈greeting〉 response.

2.2.2. SESSION MANAGEMENT

EPP provides two commands for session management: 〈login〉 to establish a
session with a server, and 〈logout〉 to end a session with a server.

- Login: The EPP 〈login〉 command is used to establish a session with an EPP
server in response to a greeting issued by the server. A 〈login〉 command
MUST be sent to a server before any other EPP command.

- Logout: The EPP 〈logout〉 command is used to end a session with an EPP
server.

2.2.3. OBJECT QUERY COMMANDS

EPP provides three commands to retrieve object information:

- 〈info〉 to retrieve detailed information associated with a known object,

- 〈check〉 to determine if an object is known to the server, and

- 〈transfer〉 to retrieve known object transfer status information. These are
described into further detail below.

Info: The EPP 〈info〉 command is used to retrieve information associated with
a known object. The elements needed to identify an object and the type of
information associated with an object are both object-specific, so the child
elements of the 〈info〉 command are specified using the EPP extension
framework.

Check: The EPP 〈check〉 command is used to determine if an object is known to
the server. The elements needed to identify an object are object-specific,
so the child elements of the 〈check〉 command are specified using the EPP
extension framework.

Poll: The EPP 〈poll〉 command is used to discover and retrieve notification
messages queued by the server for individual Registrars. Some elements are
object-specific, so the child elements of the 〈poll〉 response are specified
using the EPP extension framework.

Transfer (Query): The EPP 〈transfer〉 command provides a query operation that
allows a client to determine real-time status of pending and completed
transfer requests. The elements needed to identify an object that is the
subject of a transfer request are object-specific, so the child elements of
the 〈transfer〉 query command are specified using the EPP extension
framework.

2.2.4. OBJECT TRANSFORM COMMANDS

EPP provides five commands to transform objects:

- 〈create〉 to create an instance of an object with a server,

- 〈delete〉 to remove an instance of an object from a server,

- 〈renew〉 to extend the validity period of an object,

- 〈update〉 to change information associated with an object, and

- 〈transfer〉 to manage changes in client sponsorship of a known object.
These are described into further detail below.

Create: The EPP 〈create〉 command is used to create an instance of an object.
An object may be created for an indefinite period of time, or an object may
be created for a specific validity period. The EPP mapping for an object
MUST describe the status of an object with respect to time, to include
expected client and server behavior if a validity period is used.

Delete: The EPP 〈delete〉 command is used to remove an instance of a known
object. The elements needed to identify an object are object-specific,
therefore the child elements of the 〈delete〉 command are specified using the
EPP extension framework.

Renew: The EPP 〈renew〉 command is used to extend the validity period of an
object. The elements needed to identify and extend the validity period of an
object are object-specific, therefor the child elements of the 〈renew〉
command are specified using the EPP extension framework.

Transfer: The EPP 〈transfer〉 command is used to manage changes in client
sponsorship of a known object. Clients may initiate a transfer request,
cancel a transfer request, approve a transfer request, and reject a transfer
request.

Update: The EPP 〈update〉 command is used to change information associated
with a known object. The elements needed to identify and modify an object
are object-specific, therefore the child elements of the 〈update〉 command
are specified using the EPP extension framework.

All above transform commands can be processed by the Registry Operator in
two ways:

- immediately process the requested action;

- initiate processing the requested action, but allow for off-line review or
further interaction before completing the requested action. The response
of the EPP server will clearly note that the requested action is
ʺpendingʺ.

In the latter case the state of the corresponding object will clearly
reflect processing of the pending action. For more information on the domain
name states, reference is made to the response to Question 27 (Domain Name
Lifecycle).

2.3. FUNCTIONALITY TO PROVISION REGISTRY SERVICES

To comply with the current EPP standard, a fully functional set of commands
is at the Registrarʹs disposal. These functions are based on the CRUD
(Create – Read – Update – Delete) principle. The state of the data is
maintained by creating (C), reading (R), updating (U) and eventually
deleting (D) the data from the database.

The following basic objects exist in the database:

- Domain: The domain object contains all relevant information to the domain
name. This includes registration date, renewal date, status and DNSSEC key
material.

- Host: A host object defines a hostname which might be linked to a domain
name. It is intrinsically needed to get the domain name working. It
contains at least a domain name, possibly IP addresses and other
references.

- Contact: The contact object specifies a person or an organization. It
contains various fields to identify such party. When linked to a domain
name, a specific role is attributed to the relation.

The following commands, per object, allow for the full CRUD cycle to be
implemented conform the above specified relevant RFCʹs. Please note that the
read commands as referred to in the CRUD terminology are defined as query
commands in the EPP-centric documentation. All objects are attributed to a
specific Registrar and remain under its supervision. No other Registrar is
granted access to these objects.

Registrars should first verify if the object is manageable (and owned) by
using the 〈check〉 command. To get the content of an object, use the 〈info〉
command.

(View attachment for Table 1: Commands per object type)

By assigning a Registrar to all objects, a unique identifiable party is
assigned to any object as the owner that is allowed to change and delete the
object. To maintain a history of all changes, both a full trace log
identifying Registrar, IP address, time and command as well as a history of
the objects are stored in the database. This allows for a swift
reconstruction of any interaction with the system. For more information we
refer to the response to Question 33 of the evaluation criteria (Database
Capabilities).

To avoid confusion on the responsibility of contact objects, the Registry
Operator will not allow transfers of such contact objects between
Registrars. A contact object will always remain under maintenance of the
Registrar that created it. As a consequence the Registry Operator will
complete a transfer domain operation by implicitly cloning all contact
objects attached to the domain under transfer, so that the gaining Registrar
will have full control over his contact objects.

3. EPP EXTENSIONS

In order to be compliant with ICANNʹs Applicant Guidebook, an additional
extension to maintain the domain object is needed to integrate with the
Trademark ClearingHouse (Module V of ICANNʹs Applicant Guidebook).

At the moment, no party has been appointed to perform the TradeMark
Clearinghouse function, hence no specifications for interfacing have been
established.

The function of the TradeMark Clearinghouse is to enable trademark holders
to register their right in a central database, from where the trademark
holder receives a validation code that can be used to apply for a domain
name in a new TLD.

To that extent, ongoing community effort led already to a Launch Phase
Mapping for EPP. This Internet-Draft describes an extension mapping for EPP
that specifies a flexible scheme that can be used to implement several
common use cases related to the provisioning and management of launch phase
extension in a domain name registry.

This mapping enables the Registrar to apply for⁄claim a domain name in the
sunrise phase using the Pre-Validation Result Code 〈pvrc〉 from the TM
Clearinghouse.

4. SECURITY

It is imperative to make sure the service is not blocked by Denial Of
Service attacks (DOS). To prevent this from happening, a number of security
barriers are in place:

- rate limiting the number of connections on the border router;

- allowing only specific IP addresses specified by the Registrar;

- limiting the number of concurrent connections per Registrar.

The EPP service will run on its own virtual machine. Resources available to
the machine are constantly monitored. Early warnings are sent out in case
any of the resources are deemed to be inadequately provisioned.

Security is enhanced by limiting the access to the EPP server to a Transport
Layer Security (TLS) connection using high-grade encryption.

The Registrar is authenticated using the predefined session commands as
defined in the above RFCs. The initial credentials are exchanged between the
Registry Operator and the Registrar over an out-of-band channel.

A strict object-to-Registrar link exists such that a Registrar can only
view, access and modify its own managed objects.

5. RESOURCING PLAN

5.1. TECHNICAL RESOURCES

This service is delivered by a JAVA application running on a TOMCAT server.
To ensure the database is consistent at all times, a lock is set per
Registrar to ensure multiple connections set up by a Registrar are
serialized at the application level. To maintain high speed at all time, a
locking mechanism is also active at the domain name level, ensuring no two
domain name registrations for the same domain name are modified, while still
allowing the necessary concurrency.

Experience has learned that, under high load conditions, the bottleneck will
rather be located at the database level, and not at the application level.
If extra CPU power is required to deal with high volumes, an extra EPP
service will be provided using an alternate IP address or using a load
balancer.

To improve database security, the EPP serverʹs access to the database is
limited to a specific separate network. For a more complete and detailed
picture, reference is made to the response to Question 32 of the evaluation
criteria (System & Network Architecture).

5.2. PERSONNEL

With regards to resourcing, reference is made to the global resourcing
scheme as part of response to Question 31 (Technical Overview of the
Proposed Registry). Implementation and maintenance of the Extensible
Provisioning Protocol is under the authority of the Software Developer,
under control of the Operations Manager. The technical infrastructure is
implemented and maintained by the Network & System Administrator.