Back

25 Extensible Provisioning Protocol (EPP)

gTLDFull Legal NameE-mail suffixDetail
.playstationSony Computer Entertainment Inc.brights.jpView
We have engaged ARI Registry Services (ARI) to deliver services for this TLD. ARI provide registry services for a number of TLDs including the .au ccTLD. For more background information on ARI please see the attachment ‘Q25 – ARI Background & Roles.pdf’. This response describes the Extensible Provisioning Protocol (EPP) interface as implemented by ARI.

1 INTRODUCTION

ARI’s EPP service is XML compliant and XML Namespace aware. The service complies with the EPP protocol defined in RFC5730, and the object mappings for domain, hosts and contacts are compliant with RFC5731-3 respectively. The transport over TCP is implemented in compliance with RFC5734. The service also complies with the official extensions to support DNSSEC, RFC5910 and Redemption Grace Period, RFC3915. ARI implemented EPP draft version 0.6 in 2002, then migrated to EPP RFC 1.0 on its publishing in 2004. The system has operated live since 2002 in the .au ccTLD.
Descriptions in this response follow the terminology used in the EPP RFCs. When referring to the software involved in the process, ARI’s EPP interface is called the server, and the software used by Registrars is called the client.

2 TRANSPORT LAYER

The ARI EPP service implements the RFC5734 – EPP Transport over TCP. Connections are allowed using TLSv1 encryption, optionally supporting SSLv2 Hello for compatibility with legacy clients. AES cipher suites for TLS as described in RFC3268 are the only ones allowed.

2.1 Authentication
Registrar access to the EPP interface is authenticated and secured with multi-factor authentication (NIST Level 3) and digital assertion as follows. Registrars must:
– present a certificate, during TLS negotiation, signed by the ARI Certificate Authority (CA). The server returns a certificate also signed by the ARI CA. Not presenting a valid certificate results in session termination. ARI requires that the Common Name in the subject field of the certificate identifies the Registrar.
– originate connections from an IP address that is known to be assigned to the Registrar with that Common Name.
– Registrar must use authentication credentials provided to the Registrar via encrypted email
– Registrars aren’t able to exceed a fixed number of concurrent connections. The connection limit is prearranged and designed to prevent abuse of Registrars’ systems from affecting the Registry. The limit is set to reasonable levels for each Registrar, but can be increased to ensure legitimate traffic is unaffected. If any of the above conditions aren’t met the connection is terminated.
All communication between the Registrars and the EPP service is encrypted using at least 128 bit encryption which been designated as ‘Acceptable’ till ‘2031 and beyond’ by NIST Special Publication 800-57.

2.3 Connection Close
The server may close the connection as a result of a logout, an error where the state of the connection is indeterminate, or after a timeout. Timeout occurs where no complete EPP message is received on the connection for 10 minutes.

3 EPP PROTOCOL

This section describes the interface relating to the EPP protocol described in RFC5730. This includes session management, poll message functionality and object mappings for domains, hosts and contacts.

3.1 Session Management
Session management refers to login and logout commands, used to authenticate and end a session with the SRS. The Login command is used to establish a session between the client and the server. This command succeeds when:
– The username supplied matches the Common Name in the digital certificate used in establishing the TLS session.
– The provided password is valid for the user.
– The user’s access to the system isn’t suspended.
The Logout command is used to end an active session. On processing a logout the server closes the underlying connection. The Hello command can be used as a session keep-alive mechanism.

3.2 Service Messages
Offline notifications pertaining to certain events are stored in a queue. The client is responsible for polling this queue for new messages and to acknowledge read messages. Messages include notification about server modification of sponsored objects, transfer operations, and balance thresholds.

4 EPP OBJECT MAPPINGS

This section covers the interface for the 3 core EPP objects; domain, host and contact objects, as per RFC5731, 5732, & 5733 respectively.

The EPP domain, contact and host object mapping describes an interface for the check, info, create, delete, renew (domain only), transfer (domain & contact only) and update commands. For domain objects the server doesn’t support the use of host attributes as described by RFC5731, but rather uses host objects as described by RFC5731 and RFC5732. Details of each command are:
– check command: checks availability of 1 or more domain, contact or host objects in the SRS. Domain names will be shown as unavailable if in use, invalid or reserved, other objects will be unavailable if in use or invalid.
– info command: retrieves the information of an object provisioned in the SRS. Full information is returned to the sponsoring client or any client that provides authorisation information for the object. Non-sponsoring clients are returned partial information (no more than is available in the WhoIs).
– create command: provisions objects in the SRS. To ascertain whether an object is available for provisioning, the same rules for the check command apply.
– delete command: begins the process of removing an object from the SRS. Domain names transition into the redemption period and any applicable grace periods are applied. Domain names within the Add Grace Period are purged immediately. All other objects are purged immediately if they are not linked.
– renew command (domain only): extends the registration period of a domain name. The renewal period must be between 1 to 10 years inclusive and the current remaining registration period, plus the amount requested in the renewal mustn’t exceed 10 years.
– transfer command (domain and contact only): provides several operations for the management of the transfer of object sponsorship between clients. Clients that provide correct authorisation information for the object can request transfers. Domain names may be rejected from transfer within 60 days of creation or last transfer. The requesting client may cancel the transfer, or the sponsoring client may reject or approve the transfer. Both the gaining and losing clients may query the status of the current pending or last completed transfer.
– update command: updates authorisation information, delegation information (domains), and registration data pertaining to an object.

5 NON-PROPRIETARY EPP MAPPINGS

ARI’s EPP service implements 2 non-proprietary EPP mappings, to support the required domain name lifecycle and to provide & manage DNSSEC information. The relevant schema documents aren’t provided as they are published as RFCs in the RFC repository.

5.1 Grace Period Mapping
The Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (as per RFC 3915) is used to support the domain name lifecycle as per existing TLDs. The update command is extended by the restore command to facilitate the restoration of previously deleted domains in the redemption period. This command defines 2 operations, request & report, described here:
– Request operation: requests the restoration of a domain.
– Report operation: completes the restoration by specifying the information supporting the restoration of the domain. The restore report must include a copy of the WhoIs information at both the time the domain was deleted & restored, including the restore reason.

5.2 DNSSEC Mapping
The Domain Name System (DNS) Security Extensions Mapping for EPP, as per RFC5910, is used to support the provisioning of DNS Security Extensions. ARI requires clients use the Key Data interface. Clients may associate a maximum of 4 keys per domain. The registry system generates the corresponding DS data using the SHA-256 digest algorithm for the domain and any active variant domains.
ARI is aware of issues DNSSEC causes when transferring DNS providers – a transfer of Registrar usually means a change in DNS provider. DNSSEC key data won’t be removed from the SRS or the DNS if a transfer occurs. It is the responsibility of and requires the cooperation of the registrant, Registrars, and DNS providers, to provide a seamless transition. ARI observes progress with this issue and implements industry agreed solutions as available. DNSSEC information is included in info responses when the secDNS namespace in login.

6 PROPRIETARY MAPPING

The registry system supports 3 additional EPP extensions where no published standard for the required functionality exists. Developed to conform to the requirements specified in RFC3735, these extensions include the provisioning of Internationalised Domain Names and domain name variants, and the association of arbitrary data with a domain name. These 3 extensions are introduced below, and further described in the attached schema documentation.

6.1 Internationalised Domain Names
ARI has developed an extension to facilitate the registration and management of Internationalised Domain Names as per RFCs 5890-5893 (collectively known as the IDNA 2008 protocol). This extension extends the domain create command and the info response.
The create command is extended to capture the language table identifier that identifies the corresponding IDN language table for the domain name. Additionally the extension requires the Unicode form to avoid an inconsistency with DNS-form, as per RFC 5891.
The domain info command is extended to identify the language tag and Unicode form provided in the initial create command. This information is disclosed to all querying clients that provided the extension namespace at login. This extension is documented in the attachment ‘Q25 – idnadomain-1.0.pdf’.

6.2 Variant
ARI has developed an extension to facilitate the management of Domain Name variants. This extension extends the domain update command and the domain create and info responses. The domain update command is extended to allow the addition (activation) and removal (de-activation) of domain name variants subject to registry operator policy.
The domain create and info responses are extended to return the list of activated domain name variants. This information is disclosed to all querying clients that provided the extension namespace at login. The extension is documented in the attachment ‘Q25 – variant-1.1.pdf’.

6.3 Key-Value
ARI has developed an extension to facilitate the transport of arbitrary data between clients and the SRS without the need for developing EPP Extensions for each specific use-case. This extension extends the domain create and domain update transform commands and the domain info query command. This extension is documented in the attachment ‘Q25 – kv-1.0.pdf’.

7 ADDITIONAL SECURITY

The registry system provides additional mechanisms to support a robust interface. The use of command rate limiting enables the registry to respond to and withstand erroneous volumes of commands, while a user permission model provides fine-grained access to the EPP interface. These 2 mechanisms are described below.

7.1 Rate Limiting
The registry system supports command and global rate limits using a token-bucket algorithm. Limits apply to each connection to ensure fair and equitable use by all. Clients that exceed limits receive a command failed response message indicating breach of the limit.

7.2 User Permission Model
The registry system supports a fine-grained permission model controlling access to each specific command. By default, clients receive access to all functionality; however it is possible to remove access to a specific command in response to abuse or threat to stability of the system. Clients that attempt a command they have lost permission to execute, receive an EPP command failed response indicating loss of authorisation.

8 COMPLIANCE

Compliance with EPP RFCs is achieved through design and quality assurance (QA). The EPP interface was designed to validate all incoming messages against the respective XML Schema syntax. The XML Schema is copied directly from the relevant RFCs to avoid any ambiguity on version used. Inbound messages that are either malformed XML or invalid are rejected with a 2400 response. Outbound messages are validated against the XML Schema, and if an invalid response is generated, it is replaced with a known valid pre-composed 2400 response, and logged for later debugging.
A QA process provides confidence that changes don’t result in regressions in the interface. Automated build processes execute test suites that ensure every facet of the EPP service (including malformed input, commands sequencing and synchronisation, and boundary values) is covered and compliant with RFCs and the EPP service specification. These tests are executed prior to committing code and automatically nightly. The final deliverable is packaged and tested again to ensure no defects were introduced in the packaging process.
New versions of the EPP Service follow a deployment schedule. The new version is deployed into an OT&E environment for Registrar integration testing. Registrars are encouraged during this stage to test their systems operate correctly. After a fixed time in OT&E without issue, new versions are scheduled for production deployment. This ensures incompatibilities with RFCs that made it through QA processes are detected in test environments prior reaching production.
ARI surveys Registrars for information about the EPP client toolkit. These surveys indicated that while many Registrars use ARI toolkits, several Registrars use either their own or that from another registry. The ability for Registrars to integrate with the ARI EPP service without using the supplied toolkit indicates the service is compliant with RFCs.
ARI is committed to providing an EPP service that integrates with third party toolkits and as such tests are conducted using said toolkits. Any issues identified during testing fall into the following categories:
– Third-party toolkit not compliant with EPP
– EPP service not compliant with EPP
– Both third-party toolkit and EPP service are compliant, however another operational issue causes an issue
Defects are raised and change management processes are followed. Change requests may also be raised to promote integration of third-party toolkits and to meet common practice.

9 CAPACITY

This TLD is projected to reach 300 domains at its peak volume and will generate 0.21 EPP TPS. This will consume 0.0015% of the EPP resources. ARI’s SRS can easily accommodate this TLD. This was described in considerable detail in the capacity section of question 24.

10 RESOURCES

This function will be performed by ARI. ARI provides a technical support team to support Registrars and also provides Registrars with a tool kit (in Java and C++) implementing the EPP protocol. Normal operations for all registry services are managed by ARI’s Production Support Group (PSG), who ensure the EPP server is available and performing appropriately.
Faults relating to connections with or functionality of the EPP server are managed by PSG. ARI monitors EPP availability and functionality as part of its monitoring practices, and ensures PSG staff are available to receive fault reports from Registrars any time. PSG has the appropriate network, Unix and application (EPP and load balancing) knowledge to ensure the EPP service remains accessible and performs as required. These ARI departments support EPP:
– Products and Consulting Team (7 staff)
– Production Support Group (27 staff)
– Development Team (11 staff)
A detailed list of the departments, roles and responsibilities in ARI is provided as attachment ‘Q25 – ARI Background & Roles.pdf’. This attachment describes the functions of the above teams and the exact number and nature of staff within.
The number of resources required to design, build, operate and support the SRS does not vary significantly with, and is not linearly proportional to, the number or size of TLDs that ARI provides registry services to.
ARI provides registry backend services to 5 TLDs and has a wealth of experience in estimating the number of resources required to support a registry system.
Based on past experience ARI estimates that existing staff are adequate to support a registry system that supports in excess of 50M domains. Since this TLD projects 300 domains, 0.0006% of these resources are allocated to this TLD. See attachment ‘Q25 – Registry Scale Estimates & Resource Allocation_playstation.xlsx’ for more information.
ARI protects against loss of critical staff by employing multiple people in each role. Staff members have a primary role plus a secondary role for protection against personnel absence. Additionally ARI can scale resources as required, trained resources can be added to any of the above teams with a 2-month lead time.

10.1 Team Details
The products and consulting team is responsible for product management of the EPP solution, and works with clients and industry to identify required system features or changes. The team consists of:
– 1 Products and Consulting Manager
– 1 Product Manager
– 1 Technical Product Manager
– 4 Domain Name Industry Consultants
The Production Support Group (PSG) is responsible for the design, deployment and maintenance of the EPP infrastructure including capacity planning, monitoring, and security. This team ensures the EPP services are available and performing appropriately. The team consists of:
– Production Support Manager
– Service Desk:
– 1 Level 1 Support Team Lead
– 8 Customer Support Representatives (Level 1 support)
– 1 Level 2 Support Team Lead
– 4 Registry Specialists (Level 2 support)
– Operations (Level 3 support):
– 1 Operations Team Lead
– 2 Systems Administrators
– 2 Database Administrators
– 2 Network Engineers
– Implementation:
– 1 Project Manager
– 2 Systems Administrators
– 1 Database Administrator
– 1 Network Engineer
The development team is responsible for EPP changes and features, bug fixes and issue diagnosis. The team consists of:
– 1 Development Manager
– 2 Business Analysts
– 6 Developers
– 2 Quality Analysts
These resources sufficiently accommodate the needs of this TLD, and are included in ARI’s fees as described in our financial responses.
gTLDFull Legal NameE-mail suffixDetail
.websVistaprint Limitedvistaprint.comView

The Applicant has engaged ARI Registry Services (ARI) to deliver services for this TLD. ARI provide registry services for a number of TLDs including the .au ccTLD. For more background information on ARI please see the attachment ‘Q25 – ARI Background & Roles.pdf’. This response describes the Extensible Provisioning Protocol (EPP) interface as implemented by ARI.

1 INTRODUCTION

ARI’s EPP service is XML compliant and XML Namespace aware. The service complies with the EPP protocol defined in RFC5730, and the object mappings for domain, hosts and contacts are compliant with RFC5731-3 respectively. The transport over TCP is implemented in compliance with RFC5734. The service also complies with the official extensions to support DNSSEC, RFC5910 and Redemption Grace Period, RFC3915. ARI implemented EPP draft version 0.6 in 2002, then migrated to EPP RFC 1.0 on its publishing in 2004. The system has operated live since 2002 in the .au ccTLD.
Descriptions in this response follow the terminology used in the EPP RFCs. When referring to the software involved in the process, ARI’s EPP interface is called the server, and the software used by Registrars is called the client.

2 TRANSPORT LAYER

The ARI EPP service implements the RFC5734 – EPP Transport over TCP. Connections are allowed using TLSv1 encryption, optionally supporting SSLv2 Hello for compatibility with legacy clients. AES cipher suites for TLS as described in RFC3268 are the only ones allowed.

2.1 Authentication
Registrar access to the EPP interface is authenticated and secured with multi-factor authentication (NIST Level 3) and digital assertion as follows. Registrars must:
– present a certificate, during TLS negotiation, signed by the ARI Certificate Authority (CA). The server returns a certificate also signed by the ARI CA. Not presenting a valid certificate results in session termination. ARI requires that the Common Name in the subject field of the certificate identifies the Registrar.
– originate connections from an IP address that is known to be assigned to the Registrar with that Common Name.
– Registrar must use authentication credentials provided to the Registrar via encrypted email
– Registrars aren’t able to exceed a fixed number of concurrent connections. The connection limit is prearranged and designed to prevent abuse of Registrars’ systems from affecting the Registry. The limit is set to reasonable levels for each Registrar, but can be increased to ensure legitimate traffic is unaffected. If any of the above conditions aren’t met the connection is terminated.
All communication between the Registrars and the EPP service is encrypted using at least 128 bit encryption which been designated as ‘Acceptable’ till ‘2031 and beyond’ by NIST Special Publication 800-57.

2.3 Connection Close
The server may close the connection as a result of a logout, an error where the state of the connection is indeterminate, or after a timeout. Timeout occurs where no complete EPP message is received on the connection for 10 minutes.

3 EPP PROTOCOL

This section describes the interface relating to the EPP protocol described in RFC5730. This includes session management, poll message functionality and object mappings for domains, hosts and contacts.

3.1 Session Management
Session management refers to login and logout commands, used to authenticate and end a session with the SRS. The Login command is used to establish a session between the client and the server. This command succeeds when:
– The username supplied matches the Common Name in the digital certificate used in establishing the TLS session.
– The provided password is valid for the user.
– The user’s access to the system isn’t suspended.
The Logout command is used to end an active session. On processing a logout the server closes the underlying connection. The Hello command can be used as a session keep-alive mechanism.

3.2 Service Messages
Offline notifications pertaining to certain events are stored in a queue. The client is responsible for polling this queue for new messages and to acknowledge read messages. Messages include notification about server modification of sponsored objects, transfer operations, and balance thresholds.

4 EPP OBJECT MAPPINGS

This section covers the interface for the 3 core EPP objects; domain, host and contact objects, as per RFC5731, 5732, & 5733 respectively.

The EPP domain, contact and host object mapping describes an interface for the check, info, create, delete, renew (domain only), transfer (domain & contact only) and update commands. For domain objects the server doesn’t support the use of host attributes as described by RFC5731, but rather uses host objects as described by RFC5731 and RFC5732. Details of each command are:
– check command: checks availability of 1 or more domain, contact or host objects in the SRS. Domain names will be shown as unavailable if in use, invalid or reserved, other objects will be unavailable if in use or invalid.
– info command: retrieves the information of an object provisioned in the SRS. Full information is returned to the sponsoring client or any client that provides authorisation information for the object. Non-sponsoring clients are returned partial information (no more than is available in the WhoIs).
– create command: provisions objects in the SRS. To ascertain whether an object is available for provisioning, the same rules for the check command apply.
– delete command: begins the process of removing an object from the SRS. Domain names transition into the redemption period and any applicable grace periods are applied. Domain names within the Add Grace Period are purged immediately. All other objects are purged immediately if they are not linked.
– renew command (domain only): extends the registration period of a domain name. The renewal period must be between 1 to 10 years inclusive and the current remaining registration period, plus the amount requested in the renewal mustn’t exceed 10 years.
– transfer command (domain and contact only): provides several operations for the management of the transfer of object sponsorship between clients. Clients that provide correct authorisation information for the object can request transfers. Domain names may be rejected from transfer within 60 days of creation or last transfer. The requesting client may cancel the transfer, or the sponsoring client may reject or approve the transfer. Both the gaining and losing clients may query the status of the current pending or last completed transfer.
– update command: updates authorisation information, delegation information (domains), and registration data pertaining to an object.

5 NON-PROPRIETARY EPP MAPPINGS

ARI’s EPP service implements 2 non-proprietary EPP mappings, to support the required domain name lifecycle and to provide & manage DNSSEC information. The relevant schema documents aren’t provided as they are published as RFCs in the RFC repository.

5.1 Grace Period Mapping
The Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (as per RFC 3915) is used to support the domain name lifecycle as per existing TLDs. The update command is extended by the restore command to facilitate the restoration of previously deleted domains in the redemption period. This command defines 2 operations, request & report, described here:
– Request operation: requests the restoration of a domain.
– Report operation: completes the restoration by specifying the information supporting the restoration of the domain. The restore report must include a copy of the WhoIs information at both the time the domain was deleted & restored, including the restore reason.

5.2 DNSSEC Mapping
The Domain Name System (DNS) Security Extensions Mapping for EPP, as per RFC5910, is used to support the provisioning of DNS Security Extensions. ARI requires clients use the Key Data interface. Clients may associate a maximum of 4 keys per domain. The registry system generates the corresponding DS data using the SHA-256 digest algorithm for the domain and any active variant domains.
ARI is aware of issues DNSSEC causes when transferring DNS providers – a transfer of Registrar usually means a change in DNS provider. DNSSEC key data won’t be removed from the SRS or the DNS if a transfer occurs. It is the responsibility of and requires the cooperation of the registrant, Registrars, and DNS providers, to provide a seamless transition. ARI observes progress with this issue and implements industry agreed solutions as available. DNSSEC information is included in info responses when the secDNS namespace in login.

6 PROPRIETARY MAPPING

The registry system supports 3 additional EPP extensions where no published standard for the required functionality exists. Developed to conform to the requirements specified in RFC3735, these extensions include the provisioning of Internationalised Domain Names and domain name variants, and the association of arbitrary data with a domain name. These 3 extensions are introduced below, and further described in the attached schema documentation.

6.1 Internationalised Domain Names
ARI has developed an extension to facilitate the registration and management of Internationalised Domain Names as per RFCs 5890-5893 (collectively known as the IDNA 2008 protocol). This extension extends the domain create command and the info response.
The create command is extended to capture the language table identifier that identifies the corresponding IDN language table for the domain name. Additionally the extension requires the Unicode form to avoid an inconsistency with DNS-form, as per RFC 5891.
The domain info command is extended to identify the language tag and Unicode form provided in the initial create command. This information is disclosed to all querying clients that provided the extension namespace at login. This extension is documented in the attachment ‘Q25 – idnadomain-1.0.pdf’.

6.2 Variant
ARI has developed an extension to facilitate the management of Domain Name variants. This extension extends the domain update command and the domain create and info responses. The domain update command is extended to allow the addition (activation) and removal (de-activation) of domain name variants subject to registry operator policy.
The domain create and info responses are extended to return the list of activated domain name variants. This information is disclosed to all querying clients that provided the extension namespace at login. The extension is documented in the attachment ‘Q25 – variant-1.1.pdf’.

6.3 Key-Value
ARI has developed an extension to facilitate the transport of arbitrary data between clients and the SRS without the need for developing EPP Extensions for each specific use-case. This extension extends the domain create and domain update transform commands and the domain info query command. This extension is documented in the attachment ‘Q25 – kv-1.0.pdf’.

7 ADDITIONAL SECURITY

The registry system provides additional mechanisms to support a robust interface. The use of command rate limiting enables the registry to respond to and withstand erroneous volumes of commands, while a user permission model provides fine-grained access to the EPP interface. These 2 mechanisms are described below.

7.1 Rate Limiting
The registry system supports command and global rate limits using a token-bucket algorithm. Limits apply to each connection to ensure fair and equitable use by all. Clients that exceed limits receive a command failed response message indicating breach of the limit.

7.2 User Permission Model
The registry system supports a fine-grained permission model controlling access to each specific command. By default, clients receive access to all functionality; however it is possible to remove access to a specific command in response to abuse or threat to stability of the system. Clients that attempt a command they have lost permission to execute, receive an EPP command failed response indicating loss of authorisation.

8 COMPLIANCE

Compliance with EPP RFCs is achieved through design and quality assurance (QA). The EPP interface was designed to validate all incoming messages against the respective XML Schema syntax. The XML Schema is copied directly from the relevant RFCs to avoid any ambiguity on version used. Inbound messages that are either malformed XML or invalid are rejected with a 2400 response. Outbound messages are validated against the XML Schema, and if an invalid response is generated, it is replaced with a known valid pre-composed 2400 response, and logged for later debugging.
A QA process provides confidence that changes don’t result in regressions in the interface. Automated build processes execute test suites that ensure every facet of the EPP service (including malformed input, commands sequencing and synchronisation, and boundary values) is covered and compliant with RFCs and the EPP service specification. These tests are executed prior to committing code and automatically nightly. The final deliverable is packaged and tested again to ensure no defects were introduced in the packaging process.
New versions of the EPP Service follow a deployment schedule. The new version is deployed into an OT&E environment for Registrar integration testing. Registrars are encouraged during this stage to test their systems operate correctly. After a fixed time in OT&E without issue, new versions are scheduled for production deployment. This ensures incompatibilities with RFCs that made it through QA processes are detected in test environments prior reaching production.
ARI surveys Registrars for information about the EPP client toolkit. These surveys indicated that while many Registrars use ARI toolkits, several Registrars use either their own or that from another registry. The ability for Registrars to integrate with the ARI EPP service without using the supplied toolkit indicates the service is compliant with RFCs.
ARI is committed to providing an EPP service that integrates with third party toolkits and as such tests are conducted using said toolkits. Any issues identified during testing fall into the following categories:
– Third-party toolkit not compliant with EPP
– EPP service not compliant with EPP
– Both third-party toolkit and EPP service are compliant, however another operational issue causes an issue
Defects are raised and change management processes are followed. Change requests may also be raised to promote integration of third-party toolkits and to meet common practice.

9 CAPACITY

This TLD is projected to reach 150000 domains at its peak volume and will generate 105 EPP TPS. This will consume 0,75% of the EPP resources. ARI’s SRS can easily accommodate this TLD. This was described in considerable detail in the capacity section of question 24.

10 RESOURCES

This function will be performed by ARI. ARI provides a technical support team to support Registrars and also provides Registrars with a tool kit (in Java and C++) implementing the EPP protocol. Normal operations for all registry services are managed by ARI’s Production Support Group (PSG), who ensure the EPP server is available and performing appropriately.
Faults relating to connections with or functionality of the EPP server are managed by PSG. ARI monitors EPP availability and functionality as part of its monitoring practices, and ensures PSG staff are available to receive fault reports from Registrars any time. PSG has the appropriate network, Unix and application (EPP and load balancing) knowledge to ensure the EPP service remains accessible and performs as required. These ARI departments support EPP:
– Products and Consulting Team (7 staff)
– Production Support Group (27 staff)
– Development Team (11 staff)
A detailed list of the departments, roles and responsibilities in ARI is provided as attachment ‘Q25 – ARI Background & Roles.pdf’. This attachment describes the functions of the above teams and the exact number and nature of staff within.
The number of resources required to design, build, operate and support the SRS does not vary significantly with, and is not linearly proportional to, the number or size of TLDs that ARI provides registry services to.
ARI provides registry backend services to 5 TLDs and has a wealth of experience in estimating the number of resources required to support a registry system.
Based on past experience ARI estimates that existing staff are adequate to support a registry system that supports in excess of 50M domains. Since this TLD projects 150000 domains, 0,3% of these resources are allocated to this TLD. See attachment ‘Q25 – Registry Scale Estimates & Resource Allocation.xlsx’ for more information.
ARI protects against loss of critical staff by employing multiple people in each role. Staff members have a primary role plus a secondary role for protection against personnel absence. Additionally ARI can scale resources as required, trained resources can be added to any of the above teams with a 2-month lead time.

10.1 Team Details
The products and consulting team is responsible for product management of the EPP solution, and works with clients and industry to identify required system features or changes. The team consists of:
– 1 Products and Consulting Manager
– 1 Product Manager
– 1 Technical Product Manager
– 4 Domain Name Industry Consultants
The Production Support Group (PSG) is responsible for the design, deployment and maintenance of the EPP infrastructure including capacity planning, monitoring, and security. This team ensures the EPP services are available and performing appropriately. The team consists of:
– Production Support Manager
– Service Desk:
– 1 Level 1 Support Team Lead
– 8 Customer Support Representatives (Level 1 support)
– 1 Level 2 Support Team Lead
– 4 Registry Specialists (Level 2 support)
– Operations (Level 3 support):
– 1 Operations Team Lead
– 2 Systems Administrators
– 2 Database Administrators
– 2 Network Engineers
– Implementation:
– 1 Project Manager
– 2 Systems Administrators
– 1 Database Administrator
– 1 Network Engineer
The development team is responsible for EPP changes and features, bug fixes and issue diagnosis. The team consists of:
– 1 Development Manager
– 2 Business Analysts
– 6 Developers
– 2 Quality Analysts
These resources sufficiently accommodate the needs of this TLD, and are included in ARI’s fees as described in our financial responses.