Back

27 Registration Life Cycle

gTLDFull Legal NameE-mail suffixDetail
.seatSEAT, S.A. (Sociedad Unipersonal)abril.catView
Q27 - Registration Life Cycle

The CORE Registration System used by CORE Internet Council of Registrars to operate the .seat TLD implements a registration life cycle that conforms with best practices and procedures widely used by existing top level domain registries. While the life cycle fully complies with all relevant EPP RFCs, it also simplifies the processing of automatic domain renewals in order to ease domain data management for registrars.

The attached state diagram (Figure Q27-F1) depicts the typical life cycle of a .seat domain during the General Availability phase, from its creation to its release. In the following, the various triggers, states and transitions involved in the registration life cycle (denoted by capital letters in parentheses) are described in detail. Blue boxes denote domain states, yellow boxes denote actions caused by registrar commands, grey boxes denote automatic actions by the system, white boxes denote timed conditions reached at some point in the life cycle.


1. Domain Creation

(A) After receiving a ʺdomain:createʺ command from the registrarʹs EPP client, the specified domain name is checked for availability and compliance with the registryʹs rules and policies. If these checks are passed, a corresponding domain object is created in the repository. Its expiration date is set according to the registration period specified in the ʺdomain:createʺ command (1-10 years) and the EPP commandʹs time stamp.

With its creation, the domain also enters the Add Grace Period (AGP), which lasts 5 days; during this time frame, the registrar may delete the domain for a full refund of the registration fee (as long as the limits specified by the AGP Limits Policy are not exceeded). Also, a domain deleted during the AGP will not enter the Redemption Grace Period (RGP), but will instead be released immediately. To indicate the AGP, the domainʹs Grace Period (GP) status according to RFC 3915 is set to ʺaddPeriodʺ; this status is automatically removed after the end of the AGP.

(B) The domain is registered. Provided that at least two name servers are present in the domain and the domain has not been put into status ʺclientHoldʺ or ʺserverHoldʺ, it is published in the TLD zone and carries the EPP status ʺokʺ. If no name servers are associated with the domain, the domain carries the EPP status ʺinactiveʺ to indicate that no delegation information is present. Note that a .seat domain may either have zero name servers or 2-13 name servers; the case of exactly one name server is prohibited by server policy. In any case, the domainʹs current data is published on the Whois server (according to the disclosure settings set by the registrar).


2. Domain Update

(C) After receiving an EPP ʺdomain:updateʺ command, the domain is modified in the repository according to the data specified in the command. The domain returns to the registered state (B). Should the update change the domainʹs name servers or its ʺclientHoldʺ status, its publication in the TLD zone is affected according to the condition described in state (B). An update command may set other domain status values, such as ʺclientDeleteProhibitedʺ; see below for a full list of all supported status values. The TLD name servers and Whois servers are updated to reflect the domainʹs new data.


3. Domain Renewal (Automatic or Explicit)

(D) If a domain reaches its expiration date, it is automatically renewed; it will not be deleted, but remains in the registered state. Note that, in order to avoid unduly disruption of the domainʹs operation, this automatic renewal will even take place if the domain carries the status ʺclientRenewProhibitedʺ; this status will only disallow the explicit renewal of domains.

(E) With reaching its expiration date, the domain enters the so-called ʺAuto Renew Grace Periodʺ (ARGP), which lasts 45 days. During this time period, the registrar has the opportunity of deleting the domain name without being charged for the renewal. In order to avoid the necessity of a refund in this case, the CORE Registration System only charges the registrar with the renewal fee after the end of the ARGP (i.e., when the renewal is final). If the registrar deletes the domain during the Auto Renew Grace Period, nothing has been charged yet, so no refund is required either. Note that this differs from the commonly used practice of charging the renewal fee already at the beginning of the Auto Renew Grace Period, which requires complicated refunds in case the domain is deleted or transferred in this period. During the Auto Renew Grace Period, the domain carries the ʺautoRenewPeriodʺ GP status, which is also displayed in the Whois along with the previous expiration date (now in the past). Only after the end of the Auto Renew Grace Period, the expiration date is increased.

(F) If the end of the ARGP is reached before the registrar deletes the domain, the registrar is charged with the renewal fee. The domainʹs ʺautoRenewPeriodʺ GP status is removed.

(G) After explicit renewal (or final automatic renewal), the domainʹs expiration date is increased. The domainʹs Whois output is changed to reflect this.

(H) If the registrar explicitly renews a domain by sending a ʺdomain:renewʺ EPP command, the CORE Registration System increases the domainʹs expiration date according to the period value specified in the command. Note that a domainʹs remaining registration period may not last more than 10 years; renewal requests that would make a domain exceed this limit are rejected. The registrar is charged with the corresponding renewal fee. The domainʹs ʺRenew Grace Periodʺ is started, which lasts 5 days; during this period, the domain may be deleted for a full refund of the renewal fee. This is indicated via the ʺrenewPeriodʺ GP status, which is automatically removed when the Renew Grace Period ends.


4. Domain Deletion

(I) After receiving an EPP ʺdomain:deleteʺ command, the deletion of the domain from the repository is initiated.

(J) If the domain is in its AGP when the delete command is received, it will be released immediately, i.e. it will be available for new registrations right away. The domain will not enter the Redemption Grace Period (RGP) in this case, and the registrar receives a refund of the registration fee (as long as the limits specified by the AGP Limits Policy are not exceeded).

(K) The domain is released (i.e., purged from the repository) and available for new registrations. This marks the end of the domainʹs life cycle. If the domain was in its Add, Auto Renew, Renew or Transfer Grace Period when the delete command was received, the related charges are refunded to the sponsoring registrar.


5. Domain Restore After Deletion - the Redemption Grace Period (RGP)

(L) If the domain is not in its AGP when the delete command is received, it enters the Redemption Grace Period (RGP), which lasts 30 days. This means that the domain is not released immediately, but is only put into the EPP status ʺpendingDeleteʺ (which is also displayed in the domainʹs Whois output) and withheld from DNS publication.

The CORE Registration System fully supports the Redemption Grace Period procedures and protocols, as defined by RFC 3915. During the RGP, the domain may be restored by the previous registrar by sending a ʺdomain:updateʺ command carrying an EPP RGP extension according to the RFC.

(M) The domain is in the Redemption Grace Period (RGP). During this phase, it is not present in the TLD zone. The domain carries the EPP status ʺpendingDeleteʺ and the RGP status ʺredemptionPeriodʺ according to RFC 3915.

(N) If the domain is not restored by the previous registrar before the end of the RGP, the domain will be scheduled for release. The EPP status ʺpendingDeleteʺ is retained, the domainʹs RGP status is changed to ʺpendingDeleteʺ.

(O) The domain is no longer restorable by the registrar and due for release. It will remain in this state for a time period defined by registry policy; this could, for example, be a variable time period with a random offset in order to make the release date and time less predictable for domain snipers. Once this time period ends, the domain is released and put into the final state (K).

(P) If the previous registrar restores the domain before the end of the RGP (by sending a ʺdomain:updateʺ command carrying an EPP RGP extension according to RFC 3915), the domainʹs RGP status is changed to ʺpendingRestoreʺ. If the registrar also sends the RGP restore report within 5 days (or along with the update command), the ʺpendingDeleteʺ status value is removed from the domain and the domain will be put back into the registered state (B). If the conditions described under (B) are met, the domain will be re-added to the TLD zone. If, however, the restore report is not received within 5 days, the domain goes back into the RGP (RGP status ʺredemptionPeriodʺ), i.e. into state (M); the RGP is not restarted in this case, but is resumed at the point when the restoration was initiated by the registrar.


6. Domain Transfer

(Q) Upon request by a domainʹs registrant, a registrar (called ʺgainingʺ registrar in this case) may request to transfer a domain name currently sponsored by a different registrar (the so-called ʺlosingʺ registrar) into its own domain portfolio. This is done by sending an EPP ʺdomain:transferʺ command with operation ʺrequestʺ. After receiving such a command, the domain is marked with a ʺpendingTransferʺ EPP status value. ʺdomain:trnDataʺ EPP poll messages are placed in the message queues of both gaining and losing registrar to inform them about the transfer request. The gaining registrar is charged with the transfer fee.

A request for a domain transfer will only succeed if certain conditions are met. In particular, the provided authorisation information must be correct, and the domain must not have the ʺclientTransferProhibitedʺ or ʺserverTransferProhibitedʺ status values set. Note that the status ʺserverTransferProhibitedʺ is automatically set and maintained for 60 days by the SRS after a domain is first created, as well as after each successful registrar transfer. This is common practice among registries and avoids the problem of ʺregistrar hoppingʺ, i.e. frequent registrar changes (after e.g. hijacking a domain name) in order obstruct takedown procedures.

(R) The domain transfer is pending. The CORE Registration System waits for either the transfer to time out (after 5 days), or for the reception of an approval, rejection or cancellation before the time-out. The losing registrar may approve or reject the transfer by sending an EPP ʺdomain:transferʺ command with operation ʺapproveʺ or ʺrejectʺ, respectively. The gaining registrar may cancel the transfer by sending an EPP ʺdomain:transferʺ command with operation ʺcancelʺ.

(S) The transfer was completed successfully, either by approval of the losing registrar or by time-out (which by default automatically approves the transfer; this behaviour is configurable). The ʺpendingTransferʺ EPP status value is removed from the domain. The domain is assigned to the gaining registrar and removed from the losing registrarʹs portfolio. ʺdomain:trnDataʺ poll messages are placed in the message queues of both gaining and losing registrar. The domain returns to status (B). A successful transfer starts the domainʹs ʺTransfer Grace Periodʺ (TGP) which lasts 5 days; during the TGP (which is indicated by the ʺtransferPeriodʺ GP status), the domain may be deleted by the gaining registrar for a full refund of the transfer fee.

(T) The transfer was unsuccessful, i.e. it was rejected by the losing registrar or cancelled by the gaining registrar. The EPP status ʺpendingTransferʺ is removed from the domain. ʺdomain:trnDataʺ poll messages are placed in the message queues of both gaining and losing registrar. The domain returns to status (B). The transfer fee previously charged to the gaining registrar is refunded.


7. EPP and Grace Period Status Values

As described above, the .seat domain life cycle involves various EPP Domain and Grace Period status values and uses them in compliance with RFCs 5730-5733 and 3915 (note that RFC 5910 does not specify any status values). This section provides an overview of the status values and describes whether and how they are used in the life cycle.

In general, status values starting with ʺclientʺ may only be set or removed by the registrar, while all other status values (including those starting with ʺserverʺ) may only be set or removed by the registry, either automatically or manually by registry staff.


7.1 EPP Domain Status Values (from RFC 5731)

* clientDeleteProhibited: Indicates that the domain cannot be deleted by a ʺdomain:deleteʺ command.
* clientHold: Indicates that the domain is not published in the .seat zone.
* clientRenewProhibited: Indicates that the domain cannot be renewed by an explicit ʺdomain:renewʺ command; the status does not prevent automatic renewal.
* clientTransferProhibited: Indicates that the domain cannot be transferred.
* clientUpdateProhibited: Indicates that the domain cannot be modified.
* inactive: The domain has no delegation information, i.e. no name servers are associated. The domain is not published in the .seat zone.
* ok: The domain is active, i.e. it resolves, has no pending operations or prohibitions, and carries no other status values.
* pendingCreate: Indicates that the domainʹs creation is pending, i.e. that an asynchronous process is in progress to finish the domainʹs creation. This status is supported, e.g. for use during launch phases such as Sunrise and Landrush (to indicate that a domain applicationʹs asynchronous review is pending); please refer to the answer to question 29 (Rights Protection Mechanisms) for more information about the special life cycle support offered by the CORE Registration System for launch phases.
* pendingDelete: Indicates that the domain is being deleted; depending on its RGP status (see below), it may be restorable or not.
* pendingRenew: Indicates that the domain is pending a renewal. While supported by the CORE Registration System, this status not used in the designated .seat domain life cycle.
* pendingTransfer: Indicates that the domain is in the process of being transferred from one registrar to another registrar.
* pendingUpdate: Indicates that an update to the domain is pending, i.e. that an asynchronous process is in progress to finish the domainʹs modification. While supported by the CORE Registration System, this status not used in the designated .seat domain life cycle.
* serverDeleteProhibited: Indicates that the domain cannot be deleted.
* serverHold: Indicates that the domain is not published in the .seat zone.
* serverRenewProhibited: Indicates that the domain cannot be renewed by an explicit ʺdomain:renewʺ command; the status does not prevent auto-renewal.
* serverTransferProhibited: Indicates that the domain cannot be transferred. This status is automatically set and maintained for 60 days by the SRS after a domain is first created, as well as after each successful registrar transfer.
* serverUpdateProhibited: Indicates that the domain cannot be modified.


7.2 EPP Grace Period Status Values (from RFC 3915)

* addPeriod: Indicates that the domain is in the Add Grace Period.
* autoRenewPeriod: Indicates that the domain is in the Auto Renew Grace Period.
* renewPeriod: Indicates that the domain is in the Renew Grace Period.
* transferPeriod: Indicates that the domain is in the Transfer Grace Period.
* pendingDelete: Indicates that a deleted domain is scheduled for release, i.e. it can no longer be restored by the registrar.
* pendingRestore: Indicates that a request to restore a deleted domain has been received, and that the registry awaits the restore report from the registrar.
* redemptionPeriod: Indicates that a deleted domain is in its Redemption Grace Period, i.e. it may be restored by the registrar.


8. Consistence with Commitments to Registrants

The registration life cycle described above is consistent with the registryʹs commitments to registrants, as laid out in the answer to Question 30a. In particular, the handling of auto-renewals and the Redemption Grace Period ensures the ʺProtection of Investmentʺ part of that commitment, since it protects the domain from vanishing unintendedly.


9. Resourcing Plans

The CORE Registration System already supports the life cycle described above at the time of writing. Since the system is highly configurable, the adjustment of any variables and flags defining the process (such as name validity policies, or the durations of involved grace periods and time-outs) merely requires changing the respective settings within the system configuration. No coding is required for this, which means that no special developing resources will be needed. However, the staff on duty at CORE Internet Council of Registrars will need to define the related policies and set up the system to support and maintain the desired registration life cycle.

For the initial setup, the following resources are allotted:

* Registry Policy Officer: finalising policies, creating documentation: 3 man days
* System Administrator: configuring system for policies: 4 man hours
* First Level Support: training: 3 man hours per person

For the ongoing maintenance, the following resources are allotted:

* System Administrator: 4 man hours per month

Employees already working for CORE Internet Council of Registrars will be handling these tasks. The numbers above were determined by averaging the effort required for comparable tasks conducted by CORE in the past over the course of 12 months.

gTLDFull Legal NameE-mail suffixDetail
.lacaixaCAIXA DʹESTALVIS I PENSIONS DE BARCELONAabril.catView
Q27 - Registration Life Cycle

The CORE Registration System used by CORE Internet Council of Registrars to operate the .lacaixa TLD implements a registration life cycle that conforms with best practices and procedures widely used by existing top level domain registries. While the life cycle fully complies with all relevant EPP RFCs, it also simplifies the processing of automatic domain renewals in order to ease domain data management for registrars.

The attached state diagram (Figure Q27-F1) depicts the typical life cycle of a .lacaixa domain during the General Availability phase, from its creation to its release. In the following, the various triggers, states and transitions involved in the registration life cycle (denoted by capital letters in parentheses) are described in detail. Blue boxes denote domain states, yellow boxes denote actions caused by registrar commands, grey boxes denote automatic actions by the system, white boxes denote timed conditions reached at some point in the life cycle.


1. Domain Creation

(A) After receiving a ʺdomain:createʺ command from the registrarʹs EPP client, the specified domain name is checked for availability and compliance with the registryʹs rules and policies. If these checks are passed, a corresponding domain object is created in the repository. Its expiration date is set according to the registration period specified in the ʺdomain:createʺ command (1-10 years) and the EPP commandʹs time stamp.

With its creation, the domain also enters the Add Grace Period (AGP), which lasts 5 days; during this time frame, the registrar may delete the domain for a full refund of the registration fee (as long as the limits specified by the AGP Limits Policy are not exceeded). Also, a domain deleted during the AGP will not enter the Redemption Grace Period (RGP), but will instead be released immediately. To indicate the AGP, the domainʹs Grace Period (GP) status according to RFC 3915 is set to ʺaddPeriodʺ; this status is automatically removed after the end of the AGP.

(B) The domain is registered. Provided that at least two name servers are present in the domain and the domain has not been put into status ʺclientHoldʺ or ʺserverHoldʺ, it is published in the TLD zone and carries the EPP status ʺokʺ. If no name servers are associated with the domain, the domain carries the EPP status ʺinactiveʺ to indicate that no delegation information is present. Note that a .lacaixa domain may either have zero name servers or 2-13 name servers; the case of exactly one name server is prohibited by server policy. In any case, the domainʹs current data is published on the Whois server (according to the disclosure settings set by the registrar).


2. Domain Update

(C) After receiving an EPP ʺdomain:updateʺ command, the domain is modified in the repository according to the data specified in the command. The domain returns to the registered state (B). Should the update change the domainʹs name servers or its ʺclientHoldʺ status, its publication in the TLD zone is affected according to the condition described in state (B). An update command may set other domain status values, such as ʺclientDeleteProhibitedʺ; see below for a full list of all supported status values. The TLD name servers and Whois servers are updated to reflect the domainʹs new data.


3. Domain Renewal (Automatic or Explicit)

(D) If a domain reaches its expiration date, it is automatically renewed; it will not be deleted, but remains in the registered state. Note that, in order to avoid unduly disruption of the domainʹs operation, this automatic renewal will even take place if the domain carries the status ʺclientRenewProhibitedʺ; this status will only disallow the explicit renewal of domains.

(E) With reaching its expiration date, the domain enters the so-called ʺAuto Renew Grace Periodʺ (ARGP), which lasts 45 days. During this time period, the registrar has the opportunity of deleting the domain name without being charged for the renewal. In order to avoid the necessity of a refund in this case, the CORE Registration System only charges the registrar with the renewal fee after the end of the ARGP (i.e., when the renewal is final). If the registrar deletes the domain during the Auto Renew Grace Period, nothing has been charged yet, so no refund is required either. Note that this differs from the commonly used practice of charging the renewal fee already at the beginning of the Auto Renew Grace Period, which requires complicated refunds in case the domain is deleted or transferred in this period. During the Auto Renew Grace Period, the domain carries the ʺautoRenewPeriodʺ GP status, which is also displayed in the Whois along with the previous expiration date (now in the past). Only after the end of the Auto Renew Grace Period, the expiration date is increased.

(F) If the end of the ARGP is reached before the registrar deletes the domain, the registrar is charged with the renewal fee. The domainʹs ʺautoRenewPeriodʺ GP status is removed.

(G) After explicit renewal (or final automatic renewal), the domainʹs expiration date is increased. The domainʹs Whois output is changed to reflect this.

(H) If the registrar explicitly renews a domain by sending a ʺdomain:renewʺ EPP command, the CORE Registration System increases the domainʹs expiration date according to the period value specified in the command. Note that a domainʹs remaining registration period may not last more than 10 years; renewal requests that would make a domain exceed this limit are rejected. The registrar is charged with the corresponding renewal fee. The domainʹs ʺRenew Grace Periodʺ is started, which lasts 5 days; during this period, the domain may be deleted for a full refund of the renewal fee. This is indicated via the ʺrenewPeriodʺ GP status, which is automatically removed when the Renew Grace Period ends.


4. Domain Deletion

(I) After receiving an EPP ʺdomain:deleteʺ command, the deletion of the domain from the repository is initiated.

(J) If the domain is in its AGP when the delete command is received, it will be released immediately, i.e. it will be available for new registrations right away. The domain will not enter the Redemption Grace Period (RGP) in this case, and the registrar receives a refund of the registration fee (as long as the limits specified by the AGP Limits Policy are not exceeded).

(K) The domain is released (i.e., purged from the repository) and available for new registrations. This marks the end of the domainʹs life cycle. If the domain was in its Add, Auto Renew, Renew or Transfer Grace Period when the delete command was received, the related charges are refunded to the sponsoring registrar.


5. Domain Restore After Deletion - the Redemption Grace Period (RGP)

(L) If the domain is not in its AGP when the delete command is received, it enters the Redemption Grace Period (RGP), which lasts 30 days. This means that the domain is not released immediately, but is only put into the EPP status ʺpendingDeleteʺ (which is also displayed in the domainʹs Whois output) and withheld from DNS publication.

The CORE Registration System fully supports the Redemption Grace Period procedures and protocols, as defined by RFC 3915. During the RGP, the domain may be restored by the previous registrar by sending a ʺdomain:updateʺ command carrying an EPP RGP extension according to the RFC.

(M) The domain is in the Redemption Grace Period (RGP). During this phase, it is not present in the TLD zone. The domain carries the EPP status ʺpendingDeleteʺ and the RGP status ʺredemptionPeriodʺ according to RFC 3915.

(N) If the domain is not restored by the previous registrar before the end of the RGP, the domain will be scheduled for release. The EPP status ʺpendingDeleteʺ is retained, the domainʹs RGP status is changed to ʺpendingDeleteʺ.

(O) The domain is no longer restorable by the registrar and due for release. It will remain in this state for a time period defined by registry policy; this could, for example, be a variable time period with a random offset in order to make the release date and time less predictable for domain snipers. Once this time period ends, the domain is released and put into the final state (K).

(P) If the previous registrar restores the domain before the end of the RGP (by sending a ʺdomain:updateʺ command carrying an EPP RGP extension according to RFC 3915), the domainʹs RGP status is changed to ʺpendingRestoreʺ. If the registrar also sends the RGP restore report within 5 days (or along with the update command), the ʺpendingDeleteʺ status value is removed from the domain and the domain will be put back into the registered state (B). If the conditions described under (B) are met, the domain will be re-added to the TLD zone. If, however, the restore report is not received within 5 days, the domain goes back into the RGP (RGP status ʺredemptionPeriodʺ), i.e. into state (M); the RGP is not restarted in this case, but is resumed at the point when the restoration was initiated by the registrar.


6. Domain Transfer

(Q) Upon request by a domainʹs registrant, a registrar (called ʺgainingʺ registrar in this case) may request to transfer a domain name currently sponsored by a different registrar (the so-called ʺlosingʺ registrar) into its own domain portfolio. This is done by sending an EPP ʺdomain:transferʺ command with operation ʺrequestʺ. After receiving such a command, the domain is marked with a ʺpendingTransferʺ EPP status value. ʺdomain:trnDataʺ EPP poll messages are placed in the message queues of both gaining and losing registrar to inform them about the transfer request. The gaining registrar is charged with the transfer fee.

A request for a domain transfer will only succeed if certain conditions are met. In particular, the provided authorisation information must be correct, and the domain must not have the ʺclientTransferProhibitedʺ or ʺserverTransferProhibitedʺ status values set. Note that the status ʺserverTransferProhibitedʺ is automatically set and maintained for 60 days by the SRS after a domain is first created, as well as after each successful registrar transfer. This is common practice among registries and avoids the problem of ʺregistrar hoppingʺ, i.e. frequent registrar changes (after e.g. hijacking a domain name) in order obstruct takedown procedures.

(R) The domain transfer is pending. The CORE Registration System waits for either the transfer to time out (after 5 days), or for the reception of an approval, rejection or cancellation before the time-out. The losing registrar may approve or reject the transfer by sending an EPP ʺdomain:transferʺ command with operation ʺapproveʺ or ʺrejectʺ, respectively. The gaining registrar may cancel the transfer by sending an EPP ʺdomain:transferʺ command with operation ʺcancelʺ.

(S) The transfer was completed successfully, either by approval of the losing registrar or by time-out (which by default automatically approves the transfer; this behaviour is configurable). The ʺpendingTransferʺ EPP status value is removed from the domain. The domain is assigned to the gaining registrar and removed from the losing registrarʹs portfolio. ʺdomain:trnDataʺ poll messages are placed in the message queues of both gaining and losing registrar. The domain returns to status (B). A successful transfer starts the domainʹs ʺTransfer Grace Periodʺ (TGP) which lasts 5 days; during the TGP (which is indicated by the ʺtransferPeriodʺ GP status), the domain may be deleted by the gaining registrar for a full refund of the transfer fee.

(T) The transfer was unsuccessful, i.e. it was rejected by the losing registrar or cancelled by the gaining registrar. The EPP status ʺpendingTransferʺ is removed from the domain. ʺdomain:trnDataʺ poll messages are placed in the message queues of both gaining and losing registrar. The domain returns to status (B). The transfer fee previously charged to the gaining registrar is refunded.


7. EPP and Grace Period Status Values

As described above, the .lacaixa domain life cycle involves various EPP Domain and Grace Period status values and uses them in compliance with RFCs 5730-5733 and 3915 (note that RFC 5910 does not specify any status values). This section provides an overview of the status values and describes whether and how they are used in the life cycle.

In general, status values starting with ʺclientʺ may only be set or removed by the registrar, while all other status values (including those starting with ʺserverʺ) may only be set or removed by the registry, either automatically or manually by registry staff.


7.1 EPP Domain Status Values (from RFC 5731)

* clientDeleteProhibited: Indicates that the domain cannot be deleted by a ʺdomain:deleteʺ command.
* clientHold: Indicates that the domain is not published in the .lacaixa zone.
* clientRenewProhibited: Indicates that the domain cannot be renewed by an explicit ʺdomain:renewʺ command; the status does not prevent automatic renewal.
* clientTransferProhibited: Indicates that the domain cannot be transferred.
* clientUpdateProhibited: Indicates that the domain cannot be modified.
* inactive: The domain has no delegation information, i.e. no name servers are associated. The domain is not published in the .lacaixa zone.
* ok: The domain is active, i.e. it resolves, has no pending operations or prohibitions, and carries no other status values.
* pendingCreate: Indicates that the domainʹs creation is pending, i.e. that an asynchronous process is in progress to finish the domainʹs creation. This status is supported, e.g. for use during launch phases such as Sunrise and Landrush (to indicate that a domain applicationʹs asynchronous review is pending); please refer to the answer to question 29 (Rights Protection Mechanisms) for more information about the special life cycle support offered by the CORE Registration System for launch phases.
* pendingDelete: Indicates that the domain is being deleted; depending on its RGP status (see below), it may be restorable or not.
* pendingRenew: Indicates that the domain is pending a renewal. While supported by the CORE Registration System, this status not used in the designated .lacaixa domain life cycle.
* pendingTransfer: Indicates that the domain is in the process of being transferred from one registrar to another registrar.
* pendingUpdate: Indicates that an update to the domain is pending, i.e. that an asynchronous process is in progress to finish the domainʹs modification. While supported by the CORE Registration System, this status not used in the designated .lacaixa domain life cycle.
* serverDeleteProhibited: Indicates that the domain cannot be deleted.
* serverHold: Indicates that the domain is not published in the .lacaixa zone.
* serverRenewProhibited: Indicates that the domain cannot be renewed by an explicit ʺdomain:renewʺ command; the status does not prevent auto-renewal.
* serverTransferProhibited: Indicates that the domain cannot be transferred. This status is automatically set and maintained for 60 days by the SRS after a domain is first created, as well as after each successful registrar transfer.
* serverUpdateProhibited: Indicates that the domain cannot be modified.


7.2 EPP Grace Period Status Values (from RFC 3915)

* addPeriod: Indicates that the domain is in the Add Grace Period.
* autoRenewPeriod: Indicates that the domain is in the Auto Renew Grace Period.
* renewPeriod: Indicates that the domain is in the Renew Grace Period.
* transferPeriod: Indicates that the domain is in the Transfer Grace Period.
* pendingDelete: Indicates that a deleted domain is scheduled for release, i.e. it can no longer be restored by the registrar.
* pendingRestore: Indicates that a request to restore a deleted domain has been received, and that the registry awaits the restore report from the registrar.
* redemptionPeriod: Indicates that a deleted domain is in its Redemption Grace Period, i.e. it may be restored by the registrar.


8. Consistence with Commitments to Registrants

The registration life cycle described above is consistent with the registryʹs commitments to registrants, as laid out in the answer to Question 30a. In particular, the handling of auto-renewals and the Redemption Grace Period ensures the ʺProtection of Investmentʺ part of that commitment, since it protects the domain from vanishing unintendedly.


9. Resourcing Plans

The CORE Registration System already supports the life cycle described above at the time of writing. Since the system is highly configurable, the adjustment of any variables and flags defining the process (such as name validity policies, or the durations of involved grace periods and time-outs) merely requires changing the respective settings within the system configuration. No coding is required for this, which means that no special developing resources will be needed. However, the staff on duty at CORE Internet Council of Registrars will need to define the related policies and set up the system to support and maintain the desired registration life cycle.

For the initial setup, the following resources are allotted:

* Registry Policy Officer: finalising policies, creating documentation: 3 man days
* System Administrator: configuring system for policies: 4 man hours
* First Level Support: training: 3 man hours per person

For the ongoing maintenance, the following resources are allotted:

* System Administrator: 4 man hours per month

Employees already working for CORE Internet Council of Registrars will be handling these tasks. The numbers above were determined by averaging the effort required for comparable tasks conducted by CORE in the past over the course of 12 months.