Back

27 Registration Life Cycle

gTLDFull Legal NameE-mail suffixDetail
.اتصالاتEmirates Telecommunications Corporation (trading as Etisalat)centralnic.comView
Except where specified this answer refers to the operations of the Applicantʹs outsource Registry Service Provider, CentralNic.

The lifecycle of a domain in the registry is described in Figure 27.1, and closely follows that of domain names in existing gTLD registries. The lifecycle is described below.


27.1. Available

The domain is not registered. No delegation (or any other records) exist in the DNS, and the whois system will return a ʺNOT FOUNDʺ response to queries. An EPP “check” command will return an ʺavailʺ status of 1.


27.2. Registered

A registar submits an EPP “create” command or registers the domain name via the Registrar Console. The registration fee is deducted from the registrarʹs balance. The initial registration period may be any whole number of years between one (1) and ten (10).

For five (5) calendar days after the registration of the domain, the registrar can delete the domain and receive a credit for the registration fee (subject to the Add Grace Period Limits Policy).

While the domain is registered, it is delegated to the specified name servers and will resolve normally. During this time, the registrar may update the domain nameʹs DNS settings, lock statuses and contact associations, and may extend the registration period (subject to a maximum of ten (10) years) by submitting a “renew” EPP command or using the Registrar Console.

The domain may also be transferred to a different sponsoring registrar. Upon such transfer the domain name is automatically renewed for one year.


27.3. Expired

When the expiry date is reached, the domain name is automatically renewed for a period of one year, and the renewal fee is deducted from the registrarʹs account.

For forty-five (45) days after the auto-renewal (Auto-Renew Grace Period), the registrar can delete the domain and receive a credit for the renewal fee.


27.4. Redemption Grace Period

Should the registrar delete the domain, the domain enters the Redemption Grace Period. During this period, the domain name will no longer resolve as all delegation information is removed from the TLD zone.

For the first thirty (30) days after receipt of the delete request, the domain is in the ʺPending Delete Restorableʺ state. During this time, the registrar may submit an RGP restore request via EPP or the Registrar Console. The domain is then placed into the ʺPending Restoreʺ state.

The registrar must then submit an RGP Restore Report detailing the reason why the restore request has been submitted. If the Restore Report is received within five (5) calendar days of the original restore request, then the domain is restored. However, if the Restore Report is not received within this period, then the domain falls back into the ʺPending Delete Restorableʺ state.


27.5. Redemption Period State Diagram

Figure 27.2 describes the state diagram for domain names in the Redemption Grace Period. This diagram is taken from RFC 3915.


27.6. Pending Delete

Forty (40) days after the receipt of the delete request, the domain leaves the ʺPending Delete Restorableʺ and enters the ʺPending Deleteʺ status. The registrar cannot submit a Restore Request during this period.


27.7. Released

Five (5) days after the domain enters the ʺPending Deleteʺ status the domain name is purged from the database and is once again available for registration.


27.8. Other Grace Periods

The registry also implements the following grace periods. In general, these grace periods allow registrars to delete domain names following billable transactions and receive a refund.


27.8.1. Add Grace Period

As described above, the Add Grace Period (AGP) is the five (5) calendar days following the initial registration of the domain.


27.8.2. Auto-renew Grace Period

As described above, the Auto-renew Grace Period is the forty five (45) calendar days following the auto-renewal of the domain.


27.8.3. Renew Grace Period

The Renew Grace Period is the five (5) calendar days following the renewal of the domain via an EPP “renew” command, or via the Registrar Console.


27.8.4. Transfer Grace Period

The Transfer Grace Period is the five (5) calendar days following the successful completion of an inter-registrar transfer.


27.9. Hold Periods

The registry implements the following hold periods:


27.9.1. Registration Hold Period

The Registration Hold Period forbids inter-registrar transfers of domain names within sixty (60) days of initial registration.


27.9.2. Transfer Hold Period

The Transfer Hold Period forbids transfers of domain names within sixty (60) days of a previous inter-registrar transfer. This Hold Period does not affect disputed transfers that are undone by the registry following the outcome of a Transfer Dispute Resolution process.


27.10. Lock Statuses

The registry system permits the following lock statuses for domain names:


27.10.1. clientHold

This status may be set by registrars using an EPP “update” command, or via the Registrar Console. Domains with this status are removed from the DNS and will not resolve.


27.10.2. clientDeleteProhibited

This status may be set by registrars using an EPP “update” command, or via the Registrar Console. When set, all attempts by the registrar to delete the domain using an EPP “delete” command will be refused with EPP response code 2304 (Status Prohibits Operation). Registrars must remove the code using an EPP “update” command before they can delete the domain.


27.10.3. clientRenewProhibited

This status may be set by registrars using an EPP “update” command, or via the Registrar Console. When set, all attempts by the registrar to renew the domain using an EPP “renew” command will be refused with EPP response code 2304 (Status Prohibits Operation). Registrars must remove the code using an EPP “update” command before they can renew the domain.


27.10.4. clientUpdateProhibited

This status may be set by registrars using an EPP “update” command, or via the Registrar Console. When set, all attempts by the registrar to update the domain using an EPP “update” command will be refused with EPP response code 2304 (Status Prohibits Operation), unless the “update” request frame includes a “rem” element to remove this status. Once the status has been removed, subsequent “update” commands will succeed.


27.10.5. clientTransferProhibited

This status may be set by registrars using an EPP “update” command, or via the Registrar Console. When set, all attempts by other registrars to submit a transfer request for the the domain using an EPP “transfer” command, or via the Registrar Console, will be refused with EPP response code 2304 (Status Prohibits Operation). The sponsoring registrar must remove this status before any other registrar can submit a transfer request.


27.10.6. serverHold

This status is set by the registry in accordance with policy. It cannot be removed by registrars. Domains with this status are removed from the DNS and will not resolve.


27.10.7. serverDeleteProhibited

This status is set by the registry in accordance with policy. It cannot be removed by registrars. When set, all attempts by the registrar to delete the domain using an EPP “delete” command will be refused with EPP response code 2304 (Status Prohibits Operation).


27.10.8. serverUpdateProhibited

This status is set by the registry in accordance with policy. It cannot be removed by registrars. When set, all attempts by the registrar to update the domain using an EPP “update” command will be refused with EPP response code 2304 (Status Prohibits Operation).


27.10.9. serverRenewProhibited

This status is set by the registry in accordance with policy. It cannot be removed by registrars. When set, all attempts by the registrar to renew the domain using an EPP “renew” command will be refused with EPP response code 2304 (Status Prohibits Operation).


27.10.10. serverTransferProhibited

This status is set by the registry in accordance with policy. It cannot be removed by registrars. When set, all attempts by the registrar to transfer the domain using an EPP “transfer” command will be refused with EPP response code 2304 (Status Prohibits Operation).


27.11. Lifecycle Processing

Domain names move through the lifecycle in one of two ways: in real-time as a result of registrar activity, or during daily billing runs.

Billing runs take place once per day. The billing run performs the following batch jobs:

auto-renewal of expired domains
processing of registration and renewal fees for domains that move outside their grace periods
processing of domains in the RGP state (from restorable to not restorable, checking for missing restore reports, etc)
purging of domains scheduled for deletion
The billing runs also perform registrar account management functions such as generation of invoices, sending balance warnings, and generation of internal reports.


27.12. Inter-Registrar Transfer Period

When a transfer request is received, the action date of the transfer is set to five (5) calendar days from the moment of the original request. Successful transfers are approved at the end of this period.


27.13. pendingCreate Status

The Registry system supports the ʺpendingCreateʺ status for domain names, as described in RFC 5731, §3.3. Domains in this state are fully registered in the database (subsequent “create” commands would fail with an Object Exists error) but are not present in the DNS.

This status is used when a particular TLD implements a policy whereby registration requests are verified by a third party such as a Sponsoring Organisation or Validation Agent. Following out-of-band review of the request, the registration may be approved or denied.

If a request is denied, then the domain is immediately purged from the registry system, and the registrar notified via email and the EPP message queue. The registrar also receives a credit for the registration fee. If approved, then the pendingCreate status is removed from the domain which begins to resolve.


27.14. Resourcing

The domain registration lifecycle is managed through automated backend processes that generally require no human intervention, and real-time business logic implemented in Shared Registry System application code. Operations personnel will be responsible for maintaining and developing the computing infrastructure which supports the lifecycle processing systems. Backend systems are hosted on a flexible virtual infrastructure hosted at the primary operations centre at the Goswell Road Data Centre in London.

The domain registration lifecycle does have customer and registrar support requirements, so a proportion of the time of the Operations Manager, Support Manager and Support Agent has been dedicated to this area. This time primarily relates to dealing with questions and comments from registrars and registrants about the status of their domain names.

As can be seen in the Resourcing Matrix found in Appendix 23.2, CentralNic will maintain a team of full-time developers and engineers which will contribute to the development and maintenance of this aspect of the registry system. These developers and engineers will not work on specific subsystems full-time, but a certain percentage of their time will be dedicated to each area. The total HR resource dedicated to this area is equivalent to 30% of a full time person. Because of the maturity and stability of this system (which has been in use for more than 16 years), only 5% of time of a technical developer has been allocated to this area.

CentralNic operates a shared registry environment where multiple registry zones (such as CentralNicʹs domains, the .LA ccTLD, this TLD and other gTLDs) share a common infrastructure and resources. Since the TLD will be operated in an identical manner to these other registries, and on the same infrastructure, then the TLD will benefit from an economy of scale with regards to access to CentralNicʹs resources.

CentralNicʹs resourcing model assumes that the ʺdedicatedʺ resourcing required for the TLD (ie, that required to deal with issues related specifically to the TLD and not to general issues with the system as a whole) will be equal to the proportion of the overall registry system that the TLD will use. After three years of operation, the optimistic projection for the TLD states that there will be 1000 domains in the zone. CentralNic has calculated that, if all its TLD clients are successful in their applications, and all meet their optimistic projections after three years, its registry system will be required to support up to 4.5 million domain names. Therefore the TLD will require 0.1% of the total resources available for this area of the registry system.

In the event that registration volumes exceed this figure, CentralNic will proactively increase the size of the Technical Operations, Technical Development and support teams to ensure that the needs of the TLD are fully met. Revenues from the additional registration volumes will fund the salaries of these new hires. Nevertheless, CentralNic is confident that the staffing outlined above is sufficient to meet the needs of the TLD for at least the first 18 months of operation.
gTLDFull Legal NameE-mail suffixDetail
.VIVASaudi Telecom Companycentralnic.comView
Except where specified this answer refers to the operations of the Applicantʹs outsource Registry Service Provider, CentralNic.

The lifecycle of a domain in the registry is described in Figure 27.1, and closely follows that of domain names in existing gTLD registries. The lifecycle is described below.

27.1. Available

The domain is not registered. No delegation (or any other records) exist in the DNS, and the whois system will return a ʺNOT FOUNDʺ response to queries. An EPP “check” command will return an ʺavailʺ status of 1.

27.2. Registered

A registar submits an EPP “create” command or registers the domain name via the Registrar Console. The registration fee is deducted from the registrarʹs balance. The initial registration period may be any whole number of years between one (1) and ten (10).

For five (5) calendar days after the registration of the domain, the registrar can delete the domain and receive a credit for the registration fee (subject to the Add Grace Period Limits Policy).

While the domain is registered, it is delegated to the specified name servers and will resolve normally. During this time, the registrar may update the domain nameʹs DNS settings, lock statuses and contact associations, and may extend the registration period (subject to a maximum of ten (10) years) by submitting a “renew” EPP command or using the Registrar Console.

The domain may also be transferred to a different sponsoring registrar. Upon such transfer the domain name is automatically renewed for one year.

27.3. Expired

When the expiry date is reached, the domain name is automatically renewed for a period of one year, and the renewal fee is deducted from the registrarʹs account.

For forty-five (45) days after the auto-renewal (Auto-Renew Grace Period), the registrar can delete the domain and receive a credit for the renewal fee.

27.4. Redemption Grace Period

Should the registrar delete the domain, the domain enters the Redemption Grace Period. During this period, the domain name will no longer resolve as all delegation information is removed from the TLD zone.

For the first thirty (30) days after receipt of the delete request, the domain is in the ʺPending Delete Restorableʺ state. During this time, the registrar may submit an RGP restore request via EPP or the Registrar Console. The domain is then placed into the ʺPending Restoreʺ state.

The registrar must then submit an RGP Restore Report detailing the reason why the restore request has been submitted. If the Restore Report is received within five (5) calendar days of the original restore request, then the domain is restored. However, if the Restore Report is not received within this period, then the domain falls back into the ʺPending Delete Restorableʺ state.

27.5. Redemption Period State Diagram

Figure 27.2 describes the state diagram for domain names in the Redemption Grace Period. This diagram is taken from RFC 3915.

27.6. Pending Delete

Forty (40) days after the receipt of the delete request, the domain leaves the ʺPending Delete Restorableʺ and enters the ʺPending Deleteʺ status. The registrar cannot submit a Restore Request during this period.

27.7. Released

Five (5) days after the domain enters the ʺPending Deleteʺ status the domain name is purged from the database and is once again available for registration.

27.8. Other Grace Periods

The registry also implements the following grace periods. In general, these grace periods allow registrars to delete domain names following billable transactions and receive a refund.

27.8.1. Add Grace Period

As described above, the Add Grace Period (AGP) is the five (5) calendar days following the initial registration of the domain.

27.8.2. Auto-renew Grace Period

As described above, the Auto-renew Grace Period is the forty five (45) calendar days following the auto-renewal of the domain.

27.8.3. Renew Grace Period

The Renew Grace Period is the five (5) calendar days following the renewal of the domain via an EPP “renew” command, or via the Registrar Console.

27.8.4. Transfer Grace Period

The Transfer Grace Period is the five (5) calendar days following the successful completion of an inter-registrar transfer.

27.9. Hold Periods

The registry implements the following hold periods:

27.9.1. Registration Hold Period

The Registration Hold Period forbids inter-registrar transfers of domain names within sixty (60) days of initial registration.

27.9.2. Transfer Hold Period

The Transfer Hold Period forbids transfers of domain names within sixty (60) days of a previous inter-registrar transfer. This Hold Period does not affect disputed transfers that are undone by the registry following the outcome of a Transfer Dispute Resolution process.

27.10. Lock Statuses

The registry system permits the following lock statuses for domain names:

27.10.1. clientHold

This status may be set by registrars using an EPP “update” command, or via the Registrar Console. Domains with this status are removed from the DNS and will not resolve.

27.10.2. clientDeleteProhibited

This status may be set by registrars using an EPP “update” command, or via the Registrar Console. When set, all attempts by the registrar to delete the domain using an EPP “delete” command will be refused with EPP response code 2304 (Status Prohibits Operation). Registrars must remove the code using an EPP “update” command before they can delete the domain.

27.10.3. clientRenewProhibited

This status may be set by registrars using an EPP “update” command, or via the Registrar Console. When set, all attempts by the registrar to renew the domain using an EPP “renew” command will be refused with EPP response code 2304 (Status Prohibits Operation). Registrars must remove the code using an EPP “update” command before they can renew the domain.

27.10.4. clientUpdateProhibited

This status may be set by registrars using an EPP “update” command, or via the Registrar Console. When set, all attempts by the registrar to update the domain using an EPP “update” command will be refused with EPP response code 2304 (Status Prohibits Operation), unless the “update” request frame includes a “rem” element to remove this status. Once the status has been removed, subsequent “update” commands will succeed.

27.10.5. clientTransferProhibited

This status may be set by registrars using an EPP “update” command, or via the Registrar Console. When set, all attempts by other registrars to submit a transfer request for the the domain using an EPP “transfer” command, or via the Registrar Console, will be refused with EPP response code 2304 (Status Prohibits Operation). The sponsoring registrar must remove this status before any other registrar can submit a transfer request.

27.10.6. serverHold

This status is set by the registry in accordance with policy. It cannot be removed by registrars. Domains with this status are removed from the DNS and will not resolve.

27.10.7. serverDeleteProhibited

This status is set by the registry in accordance with policy. It cannot be removed by registrars. When set, all attempts by the registrar to delete the domain using an EPP “delete” command will be refused with EPP response code 2304 (Status Prohibits Operation).

27.10.8. serverUpdateProhibited

This status is set by the registry in accordance with policy. It cannot be removed by registrars. When set, all attempts by the registrar to update the domain using an EPP “update” command will be refused with EPP response code 2304 (Status Prohibits Operation).

27.10.9. serverRenewProhibited

This status is set by the registry in accordance with policy. It cannot be removed by registrars. When set, all attempts by the registrar to renew the domain using an EPP “renew” command will be refused with EPP response code 2304 (Status Prohibits Operation).

27.10.10. serverTransferProhibited

This status is set by the registry in accordance with policy. It cannot be removed by registrars. When set, all attempts by the registrar to transfer the domain using an EPP “transfer” command will be refused with EPP response code 2304 (Status Prohibits Operation).

27.11. Lifecycle Processing

Domain names move through the lifecycle in one of two ways: in real-time as a result of registrar activity, or during daily billing runs.

Billing runs take place once per day. The billing run performs the following batch jobs:
• auto-renewal of expired domains
• processing of registration and renewal fees for domains that move outside their grace periods
• processing of domains in the RGP state (from restorable to not restorable, checking for missing restore reports, etc)
• purging of domains scheduled for deletion

The billing runs also perform registrar account management functions such as generation of invoices, sending balance warnings, and generation of internal reports.

27.12. Inter-Registrar Transfer Period

When a transfer request is received, the action date of the transfer is set to five (5) calendar days from the moment of the original request. Successful transfers are approved at the end of this period.

27.13. pendingCreate Status

The Registry system supports the ʺpendingCreateʺ status for domain names, as described in RFC 5731, §3.3. Domains in this state are fully registered in the database (subsequent “create” commands would fail with an Object Exists error) but are not present in the DNS.

This status is used when a particular TLD implements a policy whereby registration requests are verified by a third party such as a Sponsoring Organisation or Validation Agent. Following out-of-band review of the request, the registration may be approved or denied.

If a request is denied, then the domain is immediately purged from the registry system, and the registrar notified via email and the EPP message queue. The registrar also receives a credit for the registration fee. If approved, then the pendingCreate status is removed from the domain which begins to resolve.

27.14. Resourcing

The domain registration lifecycle is managed through automated backend processes that generally require no human intervention, and real-time business logic implemented in Shared Registry System application code. Operations personnel will be responsible for maintaining and developing the computing infrastructure which supports the lifecycle processing systems. Backend systems are hosted on a flexible virtual infrastructure hosted at the primary operations centre at the Goswell Road Data Centre in London.

The domain registration lifecycle does have customer and registrar support requirements, so a proportion of the time of the Operations Manager, Support Manager and Support Agent has been dedicated to this area. This time primarily relates to dealing with questions and comments from registrars and registrants about the status of their domain names.

As can be seen in the Resourcing Matrix found in Appendix 23.2, CentralNic will maintain a team of full-time developers and engineers which will contribute to the development and maintenance of this aspect of the registry system. These developers and engineers will not work on specific subsystems full-time, but a certain percentage of their time will be dedicated to each area. The total HR resource dedicated to this area is equivalent to 30% of a full time person. Because of the maturity and stability of this system (which has been in use for more than 16 years), only 5% of time of a technical developer has been allocated to this area.

CentralNic operates a shared registry environment where multiple registry zones (such as CentralNicʹs domains, the .LA ccTLD, this TLD and other gTLDs) share a common infrastructure and resources. Since the TLD will be operated in an identical manner to these other registries, and on the same infrastructure, then the TLD will benefit from an economy of scale with regards to access to CentralNicʹs resources.

CentralNicʹs resourcing model assumes that the ʺdedicatedʺ resourcing required for the TLD (ie, that required to deal with issues related specifically to the TLD and not to general issues with the system as a whole) will be equal to the proportion of the overall registry system that the TLD will use. After three years of operation, the optimistic projection for the TLD states that there will be 1000 domains in the zone. CentralNic has calculated that, if all its TLD clients are successful in their applications, and all meet their optimistic projections after three years, its registry system will be required to support up to 4.5 million domain names. Therefore the TLD will require less than 0.1% of the total resources available for this area of the registry system.

In the event that registration volumes exceed this figure, CentralNic will proactively increase the size of the Technical Operations, Technical Development and support teams to ensure that the needs of the TLD are fully met. Revenues from the additional registration volumes will fund the salaries of these new hires. Nevertheless, CentralNic is confident that the staffing outlined above is sufficient to meet the needs of the TLD for at least the first 18 months of operation.