Back

25 Extensible Provisioning Protocol (EPP)

gTLDFull Legal NameE-mail suffixDetail
.banqueGEXBAN SASgexban.netView
Table of Contents

1 - Global description
2 - Description of commands
2.1 - Introduction
2.2 - Global commands
2.2.1 - session management commands ‘greeting’, ‘hello’, ‘login’, ‘logout’
2.2.2 - poll command ‘poll’
2.3 - domain commands
2.3.1 - query commands ‘check’, ‘info’
2.3.2 - transform commands
2.4 - contact command
2.5 - Return Codes
3 - Compliance to RFCs
3.1 - Delivery process
3.2 - XML validation
3.3 - Cross checking
4 - Specific extensions
4.1 - Specific extension : DNSSEC
4.2 - Specific extension : IDN
4.3 - Specific extension : Sunrise period
4.3.1 - New objects
4.3.2 - Command extensions
4.3.2.1 - EPP Query Commands
4.3.2.2 - EPP Transform Commands
4.3.2.2.1 - EPP ʹcreateʹ Command
4.3.2.2.2 - EPP ʹupdateʹ Command
4.3.2.2.3 - EPP ʹdeleteʹ Command
5 - Resources
5.1 - Initial implementation
5.2 - On-going maintenance


------------------------
1 - Global description

The main service of the Shared Registration System (SRS) for its registrars is the Extensible Provisioning Protocol (EPP) interface. The interface has been developed and is maintained in full compliance with the relevant standards RFCs 5730-5732 and with RFCs 5910 and 3735 for the standard registration interface. Contacts are handled as described in RFC 5733. Transport is guaranteed according to RFC 5734. In addition, AFNIC’s EPP implementation is also compliant with RFCs 4034, 5730 and 5731 for DNSSEC support and with RFCs 5890 and 5891 for Internationalized Domain Name (IDN) support.

The EPP service is available through IPv4 and IPv6, based on a SSL certificate authentication.
No specific extension is used.

Note : Throughout the document we write the XML markups describing the EPP requests between the two characters ʹ and ʹ.

For contact management, the registry service provider uses a dedicated “Repository Identifier” for each TLD, this Repository identifier being declared to IANA prior to the launch of the TLD. It is also used as a post-extension to contact nic-handles, each contact for a given TLD being then identified by a unique code XX1234-REPID. An example of this declaration can be found for .fr extension (2008-05-10) at IANA epp repository identifier’s page :

[...]
NORID, #x004E #x004F #x0052 #x0049 #x0044 UNINETT Norid AS 2007-12-10 info&norid.no
FRNIC, #x0046 #x0052 #x004e #x0049 #x0043 AFNIC 2008-05-29 tld-tech&afnic.fr
CIRA, #x0043 #x0049 #x0052 #x0041 Canadian Internet Registration Authority 2009-07-22 info&cira.ca
[...]


------------------------
2 - Description of commands

------------------------
2.1 - Introduction

The EPP interface, based on a double system of real-time answer by the server and asynchronous notifications, implements all standard operations : ‘domain:create’ (1 to 10 years), ‘domain:info’, ‘domain:checkʹ, ‘domain:transfer’, ‘domain:update’, ‘domain:renew’. Similar commands are available concerning contact objects.
The registry’s EPP server implement name servers management as domain name attributes in conformity with RFC 5732.

[see attached diagram Q25_2.1_EPP_xsd_main_schema.pdf]
Diagram : EPP xsd main schema
Description : Registry service provider SRS EPP interface is based on standard xsd schema as defined in RFC 5730.

In the following description of the commands, an example of client command and server answer has been added only for the create command as an example. All other commands work in the same way in full compliance with descriptions and schema of RFCs 5730-5734 and same examples can be found in the RFCs text.

------------------------
2.2 - Global commands

------------------------
2.2.1 - session management commands ‘greeting’, ‘hello’, ‘login’, ‘logout’

As all of these commands are basic and totally compliant with the IETF’s STD69 (RFCs 5730 to 5734), they have not be described again here.

Focus points are :
* Enforcing a limit of 2 simultaneous connection per registrar (checked at login), ensuring equitable access for all registrars.
* List of namespaces announced in ʹgreetingʹ is strictly checked in registrar ʹloginʹ command.
* ʹhelloʹ can be used by registrars as a keepalive command, otherwise inactive sessions are closed by server after 20 minutes.

------------------------
2.2.2 - poll command ʹpollʹ

For some operation on objects, notifications are added in a queue that can be read by using the ʹpollʹ command. The use of the ʹpollʹ command will retrieve the oldest message in the queue. The number of messages awaiting in the queue is indicated at each command answer with the ʹmsgQʹ element. To delete a message from the queue, the ʹpollʹ command should be used with the message number as indicated in RFC 5730.

------------------------
2.3 - domain commands

------------------------
2.3.1 - query commands ʹcheckʹ, ʹinfoʹ

ʹcheckʹ command allows the client to check if a domain object is available.
ʹinfoʹ command allows the client to retrieve information on any objects (domain names or contacts) that are indicated in the command. Registrars can only use this command for objects they already manage in their portfolio. This command can also be used for domain names outside the registrar’s portfolio if the ʹauth_infoʹ code that protects the domain is given as well.

------------------------
2.3.2 - transform commands

In compliance with RFCs 5730 (commands presentation), 5731 (domain objects), 5732 (contact objects) and 5910 (DNSSEC specifications) AFNIC’s Registry solution use the following commands that allow for objects updates :

= ʹcreateʹ =

The EPP protocol (RFC 5730) allows domain name creation (RFC 5731). The registry service provider allows two types of creations: direct domain creations (with auth_info freely determined by the registrar) and domain names creation “with authorization code” (the correct auth_info value must be sent for the creation to succeed)

Both are standard domain:create command as defined in the RFCs.

[see attached diagram Q25_2.3.2_EPP_create_command_example.pdf]
Diagram : EPP client create command and server answer example
Description : This is a standard EPP client create command following RFC 5731. Parameters sent in the following example are domain name, period of registration, registrant identifier, administrative, technical and billing identifier, and auth_info password followed by standard EPP server create command answer compliant with RFC 5731. Parameters sent in the answer are result code, message, creation and expiry date, and client and server transaction ID.

Creation “with authorization code” enables the registry service provider to manage protected names or names under specific registration conditions. An authorization code is associated to three items (the registrar, the domain name and the holder nic-handle ) and is delivered outside the automated process through a manual process defined by a specific policy rule. The registry-generated authorization code must be present in the ʹdomain:authInfoʹ item of the creation request. No registrar-computed value is permitted.
In every case, domain creation proceeds through standard EPP command.

[see attached diagram Q25_2.3.2_SRS_authorisation_code.pdf]
Diagram : SRS authorisation code
Description : The EPP auth_info field that can usually be freely filled in by the registrar has a specific use for registration of reserved names : an authorisation_code is delivered through an out of band process and must be used in the create command for the answer to be successful.

= ʹupdateʹ =

The registry offers EPP ʹdomain:updateʹ command to :
* update the administrative, technical, registrant contacts of a domain name
* update the DNS and DNSsec configuration of a domain name
* update the status of a domain name or its auth_info

This command is also used to add or delete signed delegations (DS records), through a ʹsecDNS:updateʹ extension if DNSSEC operations are wanted and if the secDNS extension was chosen by the client at login.

When requested the status of domain name is changed to “pendingUpdate”.

= ʹdeleteʹ =

The whole deletion process (including redemption grace period and pending delete) of a domain name comes with a restoration mechanism (restore). This mechanism, based on RFC 3915, is applied to the deletion operation only.

The status of the domain name is switched to ʺpendingDeleteʺ for the total duration of the ʺredemption grace periodʺ and as long as the domain is not restored or totally deleted.

= ʹtransferʹ =

The registry offers standard EPP ʹdomain:transferʹ command to allow a change of registrar to the registrant.

A transfer can be initiated only by an incoming registrar and using the auth_info that the registrant has given him. This standard mechanism acts as a security and associates the triggering of transfer to the acceptance of the owner of the domain.
The transfer operation can be triggered only if the domain is not protected by a clientTransferProhibited lock.

The transfer implementation follows RFC 5730 section 2.9.3.4 and its lifecycle follow the inter registrar transfer policy as revised by the ICANN in 2008.

------------------------
2.4 - contact command

Postal addresses are managed as indicated in RFC 5731 with the following specific rules : only the type “loc” for postal addresses is accepted and only one element of type ʹcontact:postalInfoʹ can be indicated for the contact .

ʹdiscloseʹ parameters is implemented and enables to activate restricted publication in the RDDS.
The choice to activate restricted diffusion is made in compliance with the policy and the local rules of the TLD towards privacy law.

------------------------
2.5 - Return Codes

Some operations under normal working conditions of the SRS will answer with a 1000 return code. Otherwise, two different levels of return codes have been chosen according to the two different types of problems that can happen on the SRS :
* minor problems answer with Return code 1001 : Minor problems do not affect requests reception. This code indicates the command was taken into account but that its complete execution is delayed. The final result will be known later on and will be sent in a message placed in the notification queue of the concerned registrar(s).
* blocking problems answer with Return code 2400 “command failed” : no operations that transform a domain name can be taken into account.

------------------------
3 - Compliance to RFCs

The system has been launched compliant with RFCs. Mechanisms are in place to ensure that ongoing maintenance and new functional delivery stay compliant with RFCs.

------------------------
3.1 - Delivery process

The SRS evolutions are developed on the development environment.
The development process implies strict coding rules and use of shared best practices. Pair programming is standard practice. Unit test are developed prior to function development to ensure resiliency of the produced code.

Delivery process take place in four steps :
* 1st step : XML validation and RFC compliance is checked through automated tools. A 100% compliance signal must be received to be able to proceed to second step.
* 2nd step : delivery to the pre-production environment. The development is delivered on the preproduction environment. This environment is available for internal testing team. They proceed through a standard Operational Test which goes through a full lifecycle of a domain name. Specific tests are made on new functions in any.
* 3rd step : delivery to the sandbox environment. This sandbox environment is opened for registrar where they have two accounts to validate their clients before production activation.
* 4th step : the new release is delivered in production.

------------------------
3.2 - XML validation

EPP RFC compliance is reached through three mechanisms :
* a batch of unitary tests on each operation, each answer of the server being validated through the XSD schema.
* XML validation through perl XML::LibXML::Schema library
* fuzzy testing, by sending garbage input and checking error return codes.

------------------------
3.3 - Cross checking

EPP cross checking partnership is established with .at Registry operator to validate in sandbox environment prior to delivery in production through mutual agreement.

------------------------
4 - Specific extensions

------------------------
4.1 - Specific extension : DNSSEC

The EPP server provides the secDNS-1-1 extension as described in RFC 5910. Implementation specifications are as follows :
* The server only supports “the DS data interface” (ʹsecDNS:dsDataʹ); section 4.1 of RFC 5910, without information on the associated key (the ʹsecDNS:keyDataʹ element is not included); if information on the key is indicated the server will answer with a 2102 error code.
* DNSSEC elements are only accepted during an update operation request. If included during a create operation the server will answer with a 2103 error code.
* Each domain name can have up to 6 associated DS records : the number of elements ʹsecDNS:dsDataʹ present in the ʹsecDNS:addʹ section during an update operation is therefore limited in order to have the domain name’s final status with no more than 6 DS records.
* The maxSigLife attribute is not supported, its presence inside a client request will generate a 2102 error code.
* The urgent attribute is not supported, its presence inside a client request will generate a 2102 error code.

[see attached diagram Q25_4.1_EPP_xsd_dnssec_extension_schema.pdf]
Diagram : EPP xsd dnssec extension schema
Description : Registry service provider DNSsec EPP secDNS-1-1 extension is based on standard xsd schema as defined in RFC 5910.

------------------------
4.2 - Specific extension : IDN

No specific IDN extension has been used. The script used for the TLD is declared in the greetings and no further indication is needed in the following transaction. Usage is in full compliance with RFCs 5890, 5891, 5892, 5893, and 5894. This may be a pending situation : if a standard IDN extension was to be produced in the months to come it would be added to the EPP schema in order to deal more precisely with each specific language management policies.

------------------------
4.3 - Specific extension : Sunrise period

Sunrise period is managed through a specific EPP extension. The sunrise registration workflow is described in Question 29 (Right Protection Mechanism).

The extension used is described below but will follow work in progress at the IETF initiated by Cloud Registry (draft-tan-epp-launchphase-01.txt). The xsd schema has been designed by AFNIC’s partner CORE and is fully in accordance with the draft. It could be modified before the launch if the IETF draft was to be accepted as an RFC with modifications.

AFNIC Registry extension is fully compatible with extension mechanism described in RFC 5730. It offers trademark holders a specific mapping to provide information related to trademarks. It also enables query function to keep the sunrise process transparent to everybody.

For illustration and further information purposes, please refer to the Q25_4.3_EPP_xsd_sunrise_extension_schema.pdf file attached (EPP XSD sunrise extension schema) which describes the registry back-end services provider’s EPP extension XSD schema used to deal with sunrise period. This schema is designed based on the work in progress at IETF, as initiated by Cloud Registry (draft-tan-epp-launchphase-01.txt). This extension is fully compatible with extension mechanism described in RFC 5730.

------------------------
4.3.1 - New objects

application : to deal with multiple demands on same domain name. The server creates an application object corresponding to the request and assigns an identifier for the application and returns it to the client. This mapping defines an ʹlp:applicationIDʹ element which is used to specify an ID to this object.

phase : optionnal element ʹlp:phaseʹ to be used in case of multiple sunrise phases.

status : status of each application in link with internal state of the process of the application. The ʹlp:statusʹ values that can be used in order to process the applications are pending, invalid, validated, allocated, rejected. These statuses have to be mapped with the sunrise workflow described in Question 29 (Right Protection Mechanism).

claim : claim object contains the details needed to applicantʹs prior right to the domain name.
The ʹlp:claimʹ element has the boolean ʺpreValidatedʺ attribute, which indicates whether a third party validation agency has already validated the claim in case of inter connection with the IP clearing house.

Several child elements of the ʹlp:claimʹ element are defined :
ʹlp:pvrcʹ, the Pre-Validation Result Code, is a string issued by a third-party validation agent. ʹlp:claimIssuerʹ contains the ID of a contact object (as described in RFC 5733) identifying the contact information of the authority which issued the right (for example, a trade mark office or company registration bureau).
ʹlp:claimNameʹ identifies the text string in which the applicant is claiming a prior right. ʹlp:claimNumberʹ contains the registration number of the right (i.e. trademark number or company registration number).
ʹlp:claimTypeʹ indicates the type of claim being made (e.g. trademark, symbol, combined mark,
company name).
ʹlp:claimEntitlementʹ indicates the applicantʹs entitlement to the claim (i.e. owner or licensee). ʹlp:claimRegDateʹ contains the date of registration of the claim.
ʹlp:claimExDateʹ contains the date of expiration of the claim.
ʹlp:claimCountryʹ indicates the country in which the claim is valid.
ʹlp:claimRegionʹ indicates the name of a city, state, province or other geographic region in which the claim is valid. This may be a two-character code from WIPO standard ST.3.

------------------------
4.3.2 - command extensions

------------------------
4.3.2.1 - EPP Query Commands

ʹinfoʹ command is the only extended query command.

In order to indicate that the query is meant for an application object, an ʹlp:infoʹ element is sent along with the regular ʹinfoʹ domain command.

The ʹlp:infoʹ element contains the following child elements :
ʹlp:applicationIDʹ, the application identifier for which the client wishes to query, and ʹlp:phaseʹ (optional), the phase the application is associated with.
If the query was successful, the server replies with an ʹlp:infDataʹ element along with the regular EPP ʹresDataʹ. The ʹlp:infData contains the following child elements:
* ʹlp:applicationIDʹ the application identifier of the returned application.
* ʹlp:phaseʹ (optional) the phase during which the application was submitted or is associated with.
* ʹlp:statusʹ (optional) status of the application.
* ʹlp:claimʹ (optional) one or more ʹlp:claimʹ elements.
If present, the ʹlp:claimʹ elements may contain the child elements as described above in the claim object description.

------------------------
4.3.2.2 - EPP Transform Commands

There are three extended EPP transform commands : ʹcreateʹ, ʹdeleteʹ and ʹrenewʹ

------------------------
4.3.2.2.1 - EPP ʹcreateʹ Command

The EPP ʹcreateʹ command is used to create an application. Additional information is required to submit a domain name application during a launch phase :
* ʹlp:phaseʹ (optional), the phase the application should be associated with
* ʹlp:claimʹ (optional) elements to substantiate the prior rights of the applicant.

When such a ʹcreateʹ command has been processed successfully, the EPP ʹextensionʹ element in the response contains a child ʹlp:creDataʹ element that identifies the registry launchphase namespace and the location of the registry launchphase schema. The ʹlp:creDataʹ element contains a child ʹlp:applicationIDʹ element, which informs the registrar about the application ID the server has assigned.

------------------------
4.3.2.2.2 - EPP ʹupdateʹ Command

This extension defines additional elements to extend the EPP ʹupdateʹ command to be used in conjunction with the domain name mapping.
Registry policies permitting, clients may update an application object by submitting an EPP ʹupdateʹ command along with an ʹlp:updateʹ element to indicate the application object to be updated.
The ʹlp:updateʹ element contains the following child elements:
* ʹlp:applicationIDʹ the application identifier for which the client wishes to update.
* ʹlp:phaseʹ (optional) the phase during which the application was submitted or is associated with.

------------------------
4.3.2.2.3 - EPP ʹdeleteʹ Command

Registry policies permitting, clients may withdraw an application by submitting an EPP ʹdeleteʹ command along with an ʹlp:deleteʹ element to indicate the application object to be deleted. The ʹlp:deleteʹ element contains the following child elements:
* ʹlp:applicationIDʹ the application identifier for which the client wishes to delete.
* ʹlp:phaseʹ (optional) the phase during which the application was submitted or is associated with.


------------------------
5 - Resources

Four categories of profiles are needed to run the Registry’s Technical Operations : Registry Operations Specialists (I), Registry Systems Administrators (II), Registry Software Developer (III) and Registry Expert Engineers (IV). These categories, skill set and global availability of resources have been detailed in Question 31 (Technical Overview of Proposed Registry) including specific resources set and organisation to provide 24⁄7 coverage and maintenance capacity.
Specific workload for EPP management is detailed below.

------------------------
5.1 - Initial implementation

The set up is operated on the pre-installed virtualization infrastructure. It implies actions by system, database and network administrators to create the virtual servers and install the applicative packages.

Then, developers, assisted by a senior staff member expert in internet technologies and RFCs apply proper configuration for the given TLD. Compliance is strictly tested.

The initial implementation effort is estimated as follows :

Database Administrator 0.03 man.day
Network Administrator 0.03 man.day
System Administrator 0.03 man.day
Software Developer 0.10 man.day
Software Engineer 0.20 man.day

------------------------
5.2 - On-going maintenance

On-going maintenance on the SRS includes integration of new policy rules, evolution of technology, bug fixing, infrastructure evolution, failover testing.

Although all the defined technical profiles are needed for such on-going maintenance operations, on a regular basis, it is mainly a workload handled by monitoring and development teams for alert management, new functional developments and RFC compliance checks, respectively.

The on-going maintenance effort per year is estimated as follows, on a yearly basis :

Operations Specialist 0.20 man.day
System Administrator 0.10 man.day
Software Developer 0.15 man.day
Software Engineer 0.10 man.day
gTLDFull Legal NameE-mail suffixDetail
.bzhAssociation www.bzhafnic.frView
Table of Contents

1 - Global description
2 - Description of commands
2.1 - Introduction
2.2 - Global commands
2.2.1 - session management commands ‘greeting’, ‘hello’, ‘login’, ‘logout’
2.2.2 - poll command ‘poll’
2.3 - domain commands
2.3.1 - query commands ‘check’, ‘info’
2.3.2 - transform commands
2.4 - contact command
2.5 - Return Codes
3 - Compliance to RFCs
3.1 - Delivery process
3.2 - XML validation
3.3 - Cross checking
4 - Specific extensions
4.1 - Specific extension : DNSSEC
4.2 - Specific extension : IDN
4.3 - Specific extension : Sunrise period
4.3.1 - New objects
4.3.2 - Command extensions
4.3.2.1 - EPP Query Commands
4.3.2.2 - EPP Transform Commands
4.3.2.2.1 - EPP ʹcreateʹ Command
4.3.2.2.2 - EPP ʹupdateʹ Command
4.3.2.2.3 - EPP ʹdeleteʹ Command
5 - Resources
5.1 - Initial implementation
5.2 - On-going maintenance


------------------------
1 - Global description

The main service of the Shared Registration System (SRS) for its registrars is the Extensible Provisioning Protocol (EPP) interface. The interface has been developed and is maintained in full compliance with the relevant standards RFCs 5730-5732 and with RFCs 5910 and 3735 for the standard registration interface. Contacts are handled as described in RFC 5733. Transport is guaranteed according to RFC 5734. In addition, AFNIC’s EPP implementation is also compliant with RFCs 4034, 5730 and 5731 for DNSSEC support and with RFCs 5890 and 5891 for Internationalized Domain Name (IDN) support.

The EPP service is available through IPv4 and IPv6, based on a SSL certificate authentication.
No specific extension is used.

Note : Throughout the document we write the XML markups describing the EPP requests between the two characters ʹ and ʹ.

For contact management, the registry service provider uses a dedicated “Repository Identifier” for each TLD, this Repository identifier being declared to IANA prior to the launch of the TLD. It is also used as a post-extension to contact nic-handles, each contact for a given TLD being then identified by a unique code XX1234-REPID. An example of this declaration can be found for .fr extension (2008-05-10) at IANA epp repository identifier’s page :

[...]
NORID, #x004E #x004F #x0052 #x0049 #x0044 UNINETT Norid AS 2007-12-10 info&norid.no
FRNIC, #x0046 #x0052 #x004e #x0049 #x0043 AFNIC 2008-05-29 tld-tech&afnic.fr
CIRA, #x0043 #x0049 #x0052 #x0041 Canadian Internet Registration Authority 2009-07-22 info&cira.ca
[...]


------------------------
2 - Description of commands

------------------------
2.1 - Introduction

The EPP interface, based on a double system of real-time answer by the server and asynchronous notifications, implements all standard operations : ‘domain:create’ (1 to 10 years), ‘domain:info’, ‘domain:checkʹ, ‘domain:transfer’, ‘domain:update’, ‘domain:renew’. Similar commands are available concerning contact objects.
The registry’s EPP server implement name servers management as domain name attributes in conformity with RFC 5732.

[see attached diagram Q25_2.1_EPP_xsd_main_schema.pdf]
Diagram : EPP xsd main schema
Description : Registry service provider SRS EPP interface is based on standard xsd schema as defined in RFC 5730.

In the following description of the commands, an example of client command and server answer has been added only for the create command as an example. All other commands work in the same way in full compliance with descriptions and schema of RFCs 5730-5734 and same examples can be found in the RFCs text.

------------------------
2.2 - Global commands

------------------------
2.2.1 - session management commands ‘greeting’, ‘hello’, ‘login’, ‘logout’

As all of these commands are basic and totally compliant with the IETF’s STD69 (RFCs 5730 to 5734), they have not be described again here.

Focus points are :
* Enforcing a limit of 2 simultaneous connection per registrar (checked at login), ensuring equitable access for all registrars.
* List of namespaces announced in ʹgreetingʹ is strictly checked in registrar ʹloginʹ command.
* ʹhelloʹ can be used by registrars as a keepalive command, otherwise inactive sessions are closed by server after 20 minutes.

------------------------
2.2.2 - poll command ʹpollʹ

For some operation on objects, notifications are added in a queue that can be read by using the ʹpollʹ command. The use of the ʹpollʹ command will retrieve the oldest message in the queue. The number of messages awaiting in the queue is indicated at each command answer with the ʹmsgQʹ element. To delete a message from the queue, the ʹpollʹ command should be used with the message number as indicated in RFC 5730.

------------------------
2.3 - domain commands

------------------------
2.3.1 - query commands ʹcheckʹ, ʹinfoʹ

ʹcheckʹ command allows the client to check if a domain object is available.
ʹinfoʹ command allows the client to retrieve information on any objects (domain names or contacts) that are indicated in the command. Registrars can only use this command for objects they already manage in their portfolio. This command can also be used for domain names outside the registrar’s portfolio if the ʹauth_infoʹ code that protects the domain is given as well.

------------------------
2.3.2 - transform commands

In compliance with RFCs 5730 (commands presentation), 5731 (domain objects), 5732 (contact objects) and 5910 (DNSSEC specifications) AFNIC’s Registry solution use the following commands that allow for objects updates :

= ʹcreateʹ =

The EPP protocol (RFC 5730) allows domain name creation (RFC 5731). The registry service provider allows two types of creations: direct domain creations (with auth_info freely determined by the registrar) and domain names creation “with authorization code” (the correct auth_info value must be sent for the creation to succeed)

Both are standard domain:create command as defined in the RFCs.

[see attached diagram Q25_2.3.2_EPP_create_command_example.pdf]
Diagram : EPP client create command and server answer example
Description : This is a standard EPP client create command following RFC 5731. Parameters sent in the following example are domain name, period of registration, registrant identifier, administrative, technical and billing identifier, and auth_info password followed by standard EPP server create command answer compliant with RFC 5731. Parameters sent in the answer are result code, message, creation and expiry date, and client and server transaction ID.

Creation “with authorization code” enables the registry service provider to manage protected names or names under specific registration conditions. An authorization code is associated to three items (the registrar, the domain name and the holder nic-handle ) and is delivered outside the automated process through a manual process defined by a specific policy rule. The registry-generated authorization code must be present in the ʹdomain:authInfoʹ item of the creation request. No registrar-computed value is permitted.
In every case, domain creation proceeds through standard EPP command.

[see attached diagram Q25_2.3.2_SRS_authorisation_code.pdf]
Diagram : SRS authorisation code
Description : The EPP auth_info field that can usually be freely filled in by the registrar has a specific use for registration of reserved names : an authorisation_code is delivered through an out of band process and must be used in the create command for the answer to be successful.

= ʹupdateʹ =

The registry offers EPP ʹdomain:updateʹ command to :
* update the administrative, technical, registrant contacts of a domain name
* update the DNS and DNSsec configuration of a domain name
* update the status of a domain name or its auth_info

This command is also used to add or delete signed delegations (DS records), through a ʹsecDNS:updateʹ extension if DNSSEC operations are wanted and if the secDNS extension was chosen by the client at login.

When requested the status of domain name is changed to “pendingUpdate”.

= ʹdeleteʹ =

The whole deletion process (including redemption grace period and pending delete) of a domain name comes with a restoration mechanism (restore). This mechanism, based on RFC 3915, is applied to the deletion operation only.

The status of the domain name is switched to ʺpendingDeleteʺ for the total duration of the ʺredemption grace periodʺ and as long as the domain is not restored or totally deleted.

= ʹtransferʹ =

The registry offers standard EPP ʹdomain:transferʹ command to allow a change of registrar to the registrant.

A transfer can be initiated only by an incoming registrar and using the auth_info that the registrant has given him. This standard mechanism acts as a security and associates the triggering of transfer to the acceptance of the owner of the domain.
The transfer operation can be triggered only if the domain is not protected by a clientTransferProhibited lock.

The transfer implementation follows RFC 5730 section 2.9.3.4 and its lifecycle follow the inter registrar transfer policy as revised by the ICANN in 2008.

------------------------
2.4 - contact command

Postal addresses are managed as indicated in RFC 5731 with the following specific rules : only the type “loc” for postal addresses is accepted and only one element of type ʹcontact:postalInfoʹ can be indicated for the contact .

ʹdiscloseʹ parameters is implemented and enables to activate restricted publication in the RDDS.
The choice to activate restricted diffusion is made in compliance with the policy and the local rules of the TLD towards privacy law.

------------------------
2.5 - Return Codes

Some operations under normal working conditions of the SRS will answer with a 1000 return code. Otherwise, two different levels of return codes have been chosen according to the two different types of problems that can happen on the SRS :
* minor problems answer with Return code 1001 : Minor problems do not affect requests reception. This code indicates the command was taken into account but that its complete execution is delayed. The final result will be known later on and will be sent in a message placed in the notification queue of the concerned registrar(s).
* blocking problems answer with Return code 2400 “command failed” : no operations that transform a domain name can be taken into account.


------------------------
3 - Compliance to RFCs

The system has been launched compliant with RFCs. Mechanisms are in place to ensure that ongoing maintenance and new functional delivery stay compliant with RFCs.

------------------------
3.1 - Delivery process

The SRS evolutions are developed on the development environment.
The development process implies strict coding rules and use of shared best practices. Pair programming is standard practice. Unit test are developed prior to function development to ensure resiliency of the produced code.

Delivery process take place in four steps :
* 1st step : XML validation and RFC compliance is checked through automated tools. A 100% compliance signal must be received to be able to proceed to second step.
* 2nd step : delivery to the pre-production environment. The development is delivered on the preproduction environment. This environment is available for internal testing team. They proceed through a standard Operational Test which goes through a full lifecycle of a domain name. Specific tests are made on new functions in any.
* 3rd step : delivery to the sandbox environment. This sandbox environment is opened for registrar where they have two accounts to validate their clients before production activation.
* 4th step : the new release is delivered in production.

------------------------
3.2 - XML validation

EPP RFC compliance is reached through three mechanisms :
* a batch of unitary tests on each operation, each answer of the server being validated through the XSD schema.
* XML validation through perl XML::LibXML::Schema library
* fuzzy testing, by sending garbage input and checking error return codes.

------------------------
3.3 - Cross checking

EPP cross checking partnership is established with .at Registry operator to validate in sandbox environment prior to delivery in production through mutual agreement.


------------------------
4 - Specific extensions

------------------------
4.1 - Specific extension : DNSSEC

The EPP server provides the secDNS-1-1 extension as described in RFC 5910. Implementation specifications are as follows :
* The server only supports “the DS data interface” (ʹsecDNS:dsDataʹ); section 4.1 of RFC 5910, without information on the associated key (the ʹsecDNS:keyDataʹ element is not included); if information on the key is indicated the server will answer with a 2102 error code.
* DNSSEC elements are only accepted during an update operation request. If included during a create operation the server will answer with a 2103 error code.
* Each domain name can have up to 6 associated DS records : the number of elements ʹsecDNS:dsDataʹ present in the ʹsecDNS:addʹ section during an update operation is therefore limited in order to have the domain name’s final status with no more than 6 DS records.
* The maxSigLife attribute is not supported, its presence inside a client request will generate a 2102 error code.
* The urgent attribute is not supported, its presence inside a client request will generate a 2102 error code.

[see attached diagram Q25_4.1_EPP_xsd_dnssec_extension_schema.pdf]
Diagram : EPP xsd dnssec extension schema
Description : Registry service provider DNSsec EPP secDNS-1-1 extension is based on standard xsd schema as defined in RFC 5910.

------------------------
4.2 - Specific extension : IDN

No specific IDN extension has been used. The script used for the TLD is declared in the greetings and no further indication is needed in the following transaction. Usage is in full compliance with RFCs 5890, 5891, 5892, 5893, and 5894. This may be a pending situation : if a standard IDN extension was to be produced in the months to come it would be added to the EPP schema in order to deal more precisely with each specific language management policies.

----------------------
4.3. Specific extension : Sunrise period

Sunrise period is managed through a specific EPP extension. The sunrise registration workflow is described in Question 29 (Right Protection Mechanism).

The extension used is described below but will follow work in progress at the IETF initiated by Cloud Registry (draft-tan-epp-launchphase-01.txt). The xsd schema has been designed by AFNIC’s partner CORE and is fully in accordance with the draft. It could be modified before the launch if the IETF draft was to be accepted as an RFC with modifications.

AFNIC Registry extension is fully compatible with extension mechanism described in RFC 5730. It offers trademark holders a specific mapping to provide information related to trademarks. It also enables query function to keep the sunrise process transparent to everybody.

For illustration and further information purposes, please refer to the Q25_4.3_EPP_xsd_sunrise_extension_schema.pdf file attached (EPP XSD sunrise extension schema) which describes the registry back-end services provider’s EPP extension XSD schema used to deal with sunrise period. This schema is designed based on the work in progress at IETF, as initiated by Cloud Registry (draft-tan-epp-launchphase-01.txt). This extension is fully compatible with extension mechanism described in RFC 5730.

----------------------
4.3.1 New objects

application : to deal with multiple demands on same domain name. The server creates an application object corresponding to the request and assigns an identifier for the application and returns it to the client. This mapping defines an ʹlp:applicationIDʹ element which is used to specify an ID to this object.

phase : optional element ʹlp:phaseʹ to be used in case of multiple sunrise phases.

status : status of each application in link with internal state of the process of the application. The ʹlp:statusʹ values that can be used in order to process the applications are pending, invalid, validated, allocated, rejected. These statuses have to be mapped with the sunrise workflow described in Question 29 (Right Protection Mechanism).

claim : claim object contains the details needed to applicantʹs prior right to the domain name.

The ʹlp:claimʹ element has the boolean ʺpreValidatedʺ attribute, which indicates whether a third party validation agency has already validated the claim in case of inter connection with the IP clearing house.

Several child elements of the ʹlp:claimʹ element are defined :
* ʹlp:pvrcʹ, the Pre-Validation Result Code, is a string issued by a third-party validation agent.
* ʹlp:claimIssuerʹ contains the ID of a contact object (as described in RFC 5733) identifying the contact information of the authority which issued the right (for example, a trade mark office or company registration bureau).
* ʹlp:claimNameʹ identifies the text string in which the applicant is claiming a prior right.
* ʹlp:claimNumberʹ contains the registration number of the right (i.e. trademark number or company registration number).
* ʹlp:claimTypeʹ indicates the type of claim being made (e.g. trademark, symbol, combined mark,
company name).
* ʹlp:claimEntitlementʹ indicates the applicantʹs entitlement to the claim (i.e. owner or licensee).
* ʹlp:claimRegDateʹ contains the date of registration of the claim.
* ʹlp:claimExDateʹ contains the date of expiration of the claim.
* ʹlp:claimCountryʹ indicates the country in which the claim is valid.
* ʹlp:claimRegionʹ indicates the name of a city, state, province or other geographic region in which the claim is valid. This may be a two-character code from WIPO standard ST.3.

----------------------
4.3.2 command extensions

----------------------
4.3.2.1 EPP Query Commands

ʹinfoʹ command is the only extended query command.

In order to indicate that the query is meant for an application object, an ʹlp:infoʹ element is sent along with the regular ʹinfoʹ domain command.

The ʹlp:infoʹ element contains the following child elements :
* ʹlp:applicationIDʹ, the application identifier for which the client wishes to query, and ʹlp:phaseʹ (optional), the phase the application is associated with.
If the query was successful, the server replies with an ʹlp:infDataʹ element along with the regular EPP ʹresDataʹ. The ʹlp:infData contains the following child elements:
* ʹlp:applicationIDʹ the application identifier of the returned application.
* ʹlp:phaseʹ (optional) the phase during which the application was submitted or is associated with.
* ʹlp:statusʹ (optional) status of the application.
* ʹlp:claimʹ (optional) one or more ʹlp:claimʹ elements.
If present, the ʹlp:claimʹ elements may contain the child elements as described above in the claim object description.

----------------------
4.3.2.2 EPP Transform Commands

There are three extended EPP transform commands : ʹcreateʹ, ʹdeleteʹ and ʹrenewʹ

----------------------
4.3.2.2.1 EPP ʹcreateʹ Command

The EPP ʹcreateʹ command is used to create an application. Additional information is required to submit a domain name application during a launch phase :
* ʹlp:phaseʹ (optional), the phase the application should be associated with
* ʹlp:claimʹ (optional) elements to substantiate the prior rights of the applicant.

When such a ʹcreateʹ command has been processed successfully, the EPP ʹextensionʹ element in the response contains a child ʹlp:creDataʹ element that identifies the registry launchphase namespace and the location of the registry launchphase schema. The ʹlp:creDataʹ element contains a child ʹlp:applicationIDʹ element, which informs the registrar about the application ID the server has assigned.

----------------------
4.3.2.2.2 EPP ʹupdateʹ Command

This extension defines additional elements to extend the EPP ʹupdateʹ command to be used in conjunction with the domain name mapping.
Registry policies permitting, clients may update an application object by submitting an EPP ʹupdateʹ command along with an ʹlp:updateʹ element to indicate the application object to be updated.
The ʹlp:updateʹ element contains the following child elements:
* ʹlp:applicationIDʹ the application identifier for which the client wishes to update.
* ʹlp:phaseʹ (optional) the phase during which the application was submitted or is associated with.

----------------------
4.3.2.2.3 EPP ʹdeleteʹ Command

Registry policies permitting, clients may withdraw an application by submitting an EPP ʹdeleteʹ command along with an ʹlp:deleteʹ element to indicate the application object to be deleted. The ʹlp:deleteʹ element contains the following child elements:
* ʹlp:applicationIDʹ the application identifier for which the client wishes to delete.
* ʹlp:phaseʹ (optional) the phase during which the application was submitted or is associated with.


------------------------
5 - Resources

Four categories of profiles are needed to run the Registry’s Technical Operations : Registry Operations Specialists (I), Registry Systems Administrators (II), Registry Software Developer (III) and Registry Expert Engineers (IV). These categories, skill set and global availability of resources have been detailed in Question 31 (Technical Overview of Proposed Registry) including specific resources set and organisation to provide 24⁄7 coverage and maintenance capacity.
Specific workload for EPP management is detailed below.

------------------------
5.1 - Initial implementation

The set up is operated on the pre-installed virtualization infrastructure. It implies actions by system, database and network administrators to create the virtual servers and install the applicative packages.

Then, developers, assisted by a senior staff member expert in internet technologies and RFCs apply proper configuration for the given TLD. Compliance is strictly tested.

The initial implementation effort is estimated as follows :

Database Administrator 0.10 man.day
Network Administrator 0.10 man.day
System Administrator 0.10 man.day
Software Developer 0.40 man.day
Software Engineer 0.80 man.day

------------------------
5.2 - On-going maintenance

On-going maintenance on the SRS includes integration of new policy rules, evolution of technology, bug fixing, infrastructure evolution, failover testing.

Although all the defined technical profiles are needed for such on-going maintenance operations, on a regular basis, it is mainly a workload handled by monitoring and development teams for alert management, new functional developments and RFC compliance checks, respectively.

The on-going maintenance effort per year is estimated as follows, on a yearly basis :

Operations Specialist 0.80 man.day
System Administrator 0.40 man.day
Software Developer 1.60 man.day
Software Engineer 0.40 man.day