Back

27 Registration Life Cycle

gTLDFull Legal NameE-mail suffixDetail
.immodotimmobilie GmbHdotimmobilie.deView
Introduction

The domain registration lifecycle of .IMMO follows ICANNs “Life Cycle of a Typical gTLD Domain Name” (http:⁄⁄www.icann.org⁄en⁄registrars⁄gtld-lifecycle.htm). By using this standard model lifecycle, Registrars have only minimal effort in order to become familiar with the registration procedures under the proposed TLD. Figure Q27-01 shows the lifecycle of a domain with the various states. The description below lists EPP status values, DNS status, and typical allowed transactions for each of the domain states. It also describes whether Whois information is available and what information is provided in a finger request (note: for reasons of clarity the transfer process is shown in a separate figure).

Since the registry system supports the Redemption Grace Period (RGP) extensions as specified in RFC 3915, the domain states ‘REDEMPTION’ and ‘PENDING DELETE’ refer to the respective RGP states.


Typical Lifecycle of a Registration

A typical domain lifecycle is initiated by a create domain EPP command for an AVAILABLE name. The domain is now in a ‘REGISTERED’ state. Whilst in this state the information associated with a domain may be updated by the respective registrar (using the update domain command). A domain may also be transferred to another registrar (domain transfer, see detailed state diagram below). A domain is always registered for a specific period (maximum 10 years). At any time Registrars can manually renew domains (given that the maximum registration period is not exceeded). The registry system is also supporting an auto-renew option. The auto-renew option can be deactivated on the request of a Registrar (on a per-Registrar basis), but is enabled by default to ensure that domains do not expire unintentionally.

When a domain is deleted by either the ‘delete domain’ command, or alternatively expires (not manually renewed and auto-renew disabled for the registrar), the domain first enters the ‘REDEMPTION’ state. Whilst in this state, a registrar is allowed to restore domains for the respective domain holder in case the non-renewal was unintentional. When the domain is successfully restored while in the REDEMPTION state (a restore report via EPP is required), the domain enters the ‘REGISTERED’ state again. Domains which are not restored after 30 days in the ‘REDEMPTION’ state enter the ‘PENDING DELETE’ state. Whilst in this state, a domain cannot be restored and will become AVAILABLE for re-registration after a period of 5 days.

Note that domains do not enter the ‘REDEMPTION’ state when they are deleted within the add grace period. Instead, such a domain is immediately deleted and AVAILABLE for re-registration.

Furthermore, additional EPP status values set on a domain may affect the allowed transactions (operations), e.g. status values of serverUpdateProhibited or clientUpdateProhibited, serverTransferProhibited or clientTransferProhibited, serverDeleteProhibited or clientDeleteProhibited and serverRenewProhibited or clientRenewProhibited will prohibit the respective transaction. Such server states are for example used when a domain is LOCKED.

To discourage and to address problems with abusive registrations, the proposed registry will follow policies described in response to question 28.
For domains under dispute, the registry will use the LOCKED status, and will also set appropriate status values on the associated host and contact objects, as required by the specific dispute scenario (e.g. URS).

Domain States and Properties

This section describes the individual Domain States, as outlined in figure Q27-01. For each of these states, it is described what the trigger points to reach the status are, whether the domain is included in DNS, which transactions are allowed on the object, whether WHOIS information is available, and what the boolean response for the lightweight RDDS interface (finger) is. Furthermore the EPP (base and RGP) status values set on the domain are listed.

Note that in addition to the commands listed below “check domain” is always possible and the commands “info domain” and “transfer query” are always allowed on existing domain objects, regardless of their status.

Also note that in addition to the EPP status values listed below, the value “inactive” is set for domains without associated host objects.

AVAILABLE:

Trigger points: Initial status of “new” domains, final deletion of a “PENDING DELETE” domain, deletion of a domain during Add Grace Period.
in DNS: No
Allowed Transactions: create domain
in WHOIS: No
Finger results: “available”
EPP status values: n⁄a

REGISTERED:

Trigger points: “create domain” command, Restore Report received, disputes resolved
in DNS: Yes(*)
Allowed Transactions: update domain, transfer domain (request), delete domain, renew domain
in WHOIS: Yes
Finger results: “unavailable”
EPP status values: serverTransferProhibited (during first 60 days), ok (after the first 60 days if not inactive and no other status value is set)

REDEMPTION:

Trigger points: “delete domain” command, domain expiration, disputes resolved, restore report not received.
in DNS: No
Allowed transactions: restore domain
in WHOIS: Yes
Finger result: “unavailable”
EPP Status values: pendingDelete, serverUpdateProhibited, serverHold, serverTransferProhibited, serverRenewProhibited, rgp:redemptionPeriod

PENDING DELETE:

Trigger points: domain not restored, delete locked domain
in DNS: no
Allowed Transactions: none
in WHOIS: Yes
Finger result: “unavailable”
EPP Status values: pendingDelete, serverUpdateProhibited, serverHold, serverTransferProhibited, serverRenewProhibited, rgp:pendingDelete

PENDING RESTORE:

Trigger points: “restore domain” command, dispute resolved
in DNS: Yes(*)
Allowed transactions: update domain (including delivery of the restore report), delete domain, renew domain.
in WHOIS: Yes
Finger result: “unavailable”
EPP status values: pendingDelete, serverTransferProhibited, rgp:pendingRestore

LOCKED:

Trigger points: Opening of a dispute over the domain name
in DNS: Yes(**)
Allowed transactions: renew domain
in WHOIS: Yes
Finger result: “unavailable”
EPP status values: serverUpdateProhibited, serverDeleteProhibited, serverTransferProhibited, (serverHold**)

(*)Note: Domain is only included in the DNS if the domain object is linked to host object(s), and neither serverHold nor clientHold are set on the domain object.
(**)Note: Depending on the individual dispute case, the Registry may be instructed to set the serverHold flag on the domain, and subsequently, the name would be excluded from the DNS.

The EPP status values pendingCreate, pendingRenew and pendingUpdate are never set on domain objects since there is no human review or third-party action necessary to complete these actions.

Transfers

The transfer lifecycle of the proposed gTLDs complies with ICANNs “Policy on Transfer of Registrations between Registrars” (http:⁄⁄www.icann.org⁄en⁄transfers⁄policy-12jul04.htm), specifically to its Section 6 (Registry Requirements). The lifecycle is illustrated in Figure Q27-02.

A transfer request must have valid ‘authInfo’ in order to be successful. Note that only one transfer request for a domain can be pending at any one time. Transfer requests for a domain name object that is already in the “pending Transfer” state are hence rejected.

Additionally, only domains that have been registered for more than 60 days (counted from the date of the initial registration) can be transferred.

Pending transfers can be either approved or rejected by the currently sponsoring Registrar. After a period of 5 days, any un-actioned requests are auto-approved by the Registry. Pending transfers may also be cancelled by the requesting registrar.

In the “pending Transfer” state, the following transactions on a domain name are not allowed:

transfer (op=request)
delete

(update, renew, and all other transfer sub-commands are allowed). All EPP commands are specified in RFC 5731.

A successful transfer extends the validity period of the transferred domain. The default validity period extension is 1 year but clients may request longer periods in the “transfer op=request” command), between one and 10 years (whole years only; as always, the maximum registration period is capped at 10 years).

Host Objects

The lifecycle of host objects is contained in the response to this question because internal host objects can be affected by transactions on their respective superordinate domain (parent domain). They “follow” the status of their parent domain in order to avoid issues with stale glue records.

Figure Q27-03 shows the lifecycle of internal host objects (comprised of a domain name in the .TLD namespace), and Figure Q27-04 shows the simpler lifecycle of an external host object (comprised of a domain name outside the of .TLD namespace). In Figure Q27-03, bold solid lines indicate states and transactions created by transactions on the host object itself, while dotted lines indicate effects on the internal host object that are created indirectly by transactions⁄states on the superordinate domain of the host object.

Internal host objects can only be created when the superordinate domain exists.
When the superordinate domain is deleted within the create grace period, the internal subordinate host is also immediately released.

The description of the individual states of the Host objects is as follows:

AVAILABLE: The host object does not exist in the Registry, and can be created using the “create host” EPP command.
REGISTERED: The host object exists, and can be used in domain names in order to refer to the domain name’s nameserver.

Internal hosts additionally follow the states of their respective superordinate domain as follows (Status values in the list below refer to the status of that domain):

REGISTERED (PENDING TRANSFER): The host object will be transferred together with the superordinate domain (in case the transfer is completed successfully).
REDEMPTION: For the redemption period of the superordinate domain, the host object glue will continue to be included in the TLD, even if the superordinate domain is not included in the zone anymore.
PENDING DELETE: The glue record will not be included in the DNS anymore. On final deletion of the host object, all references to this host object will be removed too.

More information regarding this process in order to avoid stale glue records is included in response to Question 28 (Abuse Prevention and Mitigation).

Grace Periods

The following grace periods are supported for domains:

add grace period: the add grace period lasts 5 calendar days from the date of initial registration. When a domain is deleted in this period, it is immediately deleted and available for re-registration. The registrar is credited for an amount corresponding to the registration fee (unless the registrar is already over its monthly allowance of add grace transactions). A ‘renew’ command ends the add grace period. Note that it is impossible to perform a domain transfer in the add grace period (in fact, the first transfer is only allowed after 60 days of registration). To prevent misuse and domain tasting in particular, a policy applies as to the number of delete requests per month that are refunded during the add grace period (see below). Deletions in the add grace period exceeding this limit are not refunded.
transfer grace period: the transfer grace period is currently 5 calendar days following a successfully completed domain transfer. If a domain is deleted in this timeframe, the sponsoring registrar is credited for the amount billed during the domain transfer. The transfer grace period is terminated when a restore, renew or subsequent domain transfer is performed.
renew grace period: after each renew command, a 5 calendar day long renew grace period starts. When the domain is deleted in this timeframe, the registrar is credited for the corresponding fee and the domain enters REDEMPTION. A deletion, restoration or approved transfer of a domain immediately ends the renew grace period.
auto-renew grace period: every auto-renew is followed by an auto-renew grace period (45 calendar days). If a domain is deleted or transferred within this period the fee for the renewal is refunded to the registrar. However, when a renew command is performed there is no grace period credit any more.

Refunds for deleting domains during an add grace period will follow ICANN’s Add Grace Period Limits Policy, available at: http:⁄⁄www.icann.org⁄en⁄tlds⁄agp-policy-17dec08-en.htm (including implementation notes).

The registry system supports the following pending periods in which certain operations are not allowed:

Redemption Grace Period: consisting of
** Redemption Period: Whilst in this 30 day period, a domain can be restored after a deletion action (only if domain is not within the add grace period)
** Pending Restore: in order to successfully restore a domain in the redemption period, a restore report is required. This report has to be submitted within 7 days of this pending restore period. If no restore report is submitted, a new 30 day long redemption period begins.
** Pending Delete: If a domain is deleted and not restored, it is placed into the pending delete period following the redemption period. After 5 days in this period, the domain is finally available for re-registration.
Pending Transfer Period: lasts for a maximum of 5 days after the initial transfer request command. The losing registrar has 5 days to approve or reject the request. The requestor may also cancel the transfer within this period. If no action is taken by the losing or gaining registrar, the registry auto-approves the transfer.

This registration lifecycle matches the business model of the proposed gTLD. The proposed registry software fully supports this lifecycle and the technical resources needed to run a registry based on the lifecycle as described are readily available.

Resourcing

Three staff members of TLD-Box (the Registry Back-End Operator of the proposed gTLD) are experts in domain name life cycle, and have designed life cycles for the “.at”, “.bh” TLD, as well as consulted some other TLDs on their domain life cycle.
All other technical staff members as well as support staff are trained on the operational aspects of the Domain Name Lifecycle.

There are only minor staff and⁄or infrastructure resources needed for the day to day operations in relation to the domain lifecycle itself (since once developed, the resources to run the lifecycle come from resources operating the EPP servers). In terms of ongoing maintenance, it is expected that about 5 person days per year are required in order to clarify details, corner cases and relations to other business processes of the registry. Those 5 person days are budgeted for in the general maintenance time & resource budget of the registry.

gTLDFull Legal NameE-mail suffixDetail
.vlaanderenDNS.be vzwdns.beView
Response to Question 27 (Registration Life Cycle)

1. Registration Life Cycle
--------------------------

The domain registration life cycle of .vlaanderen follows ICANNs “Life Cycle of a Typical gTLD Domain Name” (http:⁄⁄www.icann.org⁄en⁄registrars⁄gtld-lifecycle.htm). By using this standard model life cycle, Registrars have only minimal effort in order to become familiar with the registration procedures under the proposed TLD. Figure Q27-01 (see attachment) shows the life cycle of a domain with the various states. The description below lists EPP status values, DNS status, and typical allowed transactions for each of the domain states. It also describes whether Whois information is available and what information is provided in a finger request (note: for reasons of clarity the transfer process is shown in a separate figure).

Since the registry system supports the Redemption Grace Period (RGP) extensions as specified in RFC 3915, the domain states ‘REDEMPTION’ and ‘PENDING DELETE’ refer to the respective RGP states.

1.1 Typical Life cycle of a Registration

A typical domain life cycle is initiated by a create domain EPP command for an AVAILABLE name. The domain is now in a ‘REGISTERED’ state. Whilst in this state the information associated with a domain may be updated by the respective registrar (using the update domain command). A domain may also be transferred to another registrar (domain transfer, see detailed state diagram below). A domain is always registered for a specific period (maximum 10 years). At any time Registrars can manually renew domains (given that the maximum registration period is not exceeded). The registry system is also supporting an auto-renew option. The auto-renew option can be deactivated on the request of a Registrar (on a per-Registrar basis), but is enabled by default to ensure that domains do not expire unintentionally.

When a domain is deleted by either the ‘delete domain’ command, or alternatively expires (not manually renewed and auto-renew disabled for the registrar), the domain first enters the ‘REDEMPTION’ state. Whilst in this state, a registrar is allowed to restore domains for the respective domain holder in case the non-renewal was unintentional. When the domain is successfully restored while in the REDEMPTION state (a restore report via EPP is required), the domain enters the ‘REGISTERED’ state again. Domains which are not restored after 30 days in the ‘REDEMPTION’ state enter the ‘PENDING DELETE’ state. Whilst in this state, a domain cannot be restored and will become AVAILABLE for re-registration after a period of 5 days.

Note that domains do not enter the ‘REDEMPTION’ state when they are deleted within the add grace period. Instead, such a domain is immediately deleted and AVAILABLE for re-registration.

Furthermore, additional EPP status values set on a domain may affect the allowed transactions (operations), e.g. status values of serverUpdateProhibited or clientUpdateProhibited, serverTransferProhibited or clientTransferProhibited, serverDeleteProhibited or clientDeleteProhibited and serverRenewProhibited or clientRenewProhibited will prohibit the respective transaction. Such server states are for example used when a domain is LOCKED.

To discourage and to address problems with abusive registrations, the proposed registry will follow policies described in response to question 28.
For domains under dispute, the registry will use the LOCKED status, and will also set appropriate status values on the associated host and contact objects, as required by the specific dispute scenario (e.g. URS).

1.2 Domain States and Properties

This section describes the individual Domain States, as outlined in figure Q27-01 (see attachment). For each of these states, it is described what the trigger points to reach the status are, whether the domain is included in DNS, which transactions are allowed on the object, whether WHOIS information is available, and what the boolean response for the lightweight RDDS interface (finger) is. Furthermore the EPP (base and RGP) status values set on the domain are listed.

Note that in addition to the commands listed below “check domain” is always possible and the commands “info domain” and “transfer query” are always allowed on existing domain objects, regardless of their status.

Also note that in addition to the EPP status values listed below, the value “inactive” is set for domains without associated host objects.

* AVAILABLE:
* Trigger points: Initial status of “new” domains, final deletion of a “PENDING DELETE” domain, deletion of a domain during Add Grace Period.
* in DNS: No
* Allowed Transactions: create domain
* in WHOIS: No
* Finger results: “available”
* EPP status values: n⁄a
* REGISTERED:
* Trigger points: “create domain” command, Restore Report received, disputes resolved
* in DNS: Yes*
* Allowed Transactions: update domain, transfer domain (request), delete domain, renew domain
* in WHOIS: Yes
* Finger results: “unavailable”
* EPP status values: serverTransferProhibited (during first 60 days), ok (after the first 60 days if not inactive and no other status value is set)
* REDEMPTION:
* Trigger points: “delete domain” command, domain expiration, disputes resolved, restore report not received.
* in DNS: No
* Allowed transactions: restore domain
* in WHOIS: Yes
* Finger result: “unavailable”
* EPP Status values: pendingDelete, serverUpdateProhibited, serverHold, serverTransferProhibited, serverRenewProhibited, rgp:redemptionPeriod
* PENDING DELETE:
* Trigger points: domain not restored, delete locked domain
* in DNS: no
* Allowed Transactions: none
* in WHOIS: Yes
* Finger result: “unavailable”
* EPP Status values: pendingDelete, serverUpdateProhibited, serverHold, serverTransferProhibited, serverRenewProhibited, rgp:pendingDelete
* PENDING RESTORE:
* Trigger points: “restore domain” command, dispute resolved
* in DNS: Yes*
* Allowed transactions: update domain (including delivery of the restore report), delete domain, renew domain.
* in WHOIS: Yes
* Finger result: “unavailable”
* EPP status values: pendingDelete, serverTransferProhibited, rgp:pendingRestore
* LOCKED:
* Trigger points: Opening of a dispute over the domain name
* in DNS: Yes**
* Allowed transactions: renew domain
* in WHOIS: Yes
* Finger result: “unavailable”
* EPP status values: serverUpdateProhibited, serverDeleteProhibited, serverTransferProhibited, (serverHold**)

*Note: Domain is only included in the DNS if the domain object is linked to host object(s), and neither serverHold nor clientHold are set on the domain object.
**Note: Depending on the individual dispute case, the Registry may be instructed to set the serverHold flag on the domain, and subsequently, the name would be excluded from the DNS.

The EPP status values pendingCreate, pendingRenew and pendingUpdate are never set on domain objects since there is no human review or third-party action necessary to complete these actions. However, we will screen all new registrations after they are registered and became active. More information about this procedure can be found in the answer to question 18b.

1.3 Transfers

The transfer life cycle of the proposed gTLDs complies with ICANNs “Policy on Transfer of Registrations between Registrars” (http:⁄⁄www.icann.org⁄en⁄transfers⁄policy-12jul04.htm), specifically to its Section 6 (Registry Requirements). The life cycle is illustrated in Figure Q27-02 (see attachment).

A transfer request must have valid ‘authInfo’ in order to be successful. Note that only one transfer request for a domain can be pending at any one time. Transfer requests for a domain name object that is already in the “pending Transfer” state are hence rejected.

Additionally, only domains that have been registered for more than 60 days (counted from the date of the initial registration) can be transferred.
Pending transfers can be either approved or rejected by the currently sponsoring Registrar. After a period of 5 days, any un-actioned requests are auto-approved by the Registry. Pending transfers may also be cancelled by the requesting registrar.

In the “pending Transfer” state, the following transactions on a domain name are not allowed:
* transfer (op=request)
* delete
(update, renew, and all other transfer sub-commands are allowed). All EPP commands are specified in RFC 5731.

A successful transfer extends the validity period of the transferred domain. The default validity period extension is 1 year but clients may request longer periods in the “transfer op=request” command), between one and 10 years (whole years only; as always, the maximum registration period is capped at 10 years).

1.4 Host Objects

The life cycle of host objects is contained in the response to this question because internal host objects can be affected by transactions on their respective superordinate domain (parent domain). They “follow” the status of their parent domain in order to avoid issues with stale glue records.

Figure Q27-03 (see attachment) shows the life cycle of internal host objects (comprised of a domain name in the .TLD namespace), and Figure Q27-04 (see attachment) shows the simpler life cycle of an external host object (comprised of a domain name outside the of .TLD namespace). In Figure Q27-03 (see attachment), bold solid lines indicate states and transactions created by transactions on the host object itself, while dotted lines indicate effects on the internal host object that are created indirectly by transactions⁄states on the superordinate domain of the host object.

Internal host objects can only be created when the superordinate domain exists.
When the superordinate domain is deleted within the create grace period, the internal subordinate host is also immediately released.

The description of the individual states of the Host objects is as follows:
* AVAILABLE: The host object does not exist in the Registry, and can be created using the “create host” EPP command.
* REGISTERED: The host object exists, and can be used in domain names in order to refer to the domain name’s name server.

Internal hosts additionally follow the states of their respective superordinate domain as follows (Status values in the list below refer to the status of that domain):

* REGISTERED (PENDING TRANSFER): The host object will be transferred together with the superordinate domain (in case the transfer is completed successfully).
* REDEMPTION: For the redemption period of the superordinate domain, the host object glue will continue to be included in the TLD, even if the superordinate domain is not included in the zone anymore.
* PENDING DELETE: The glue record will not be included in the DNS anymore. On final deletion of the host object, all references to this host object will be removed too.

More information regarding this process in order to avoid stale glue records is included in response to Question 28 (Abuse Prevention and Mitigation).

1.5 Grace Periods

The following grace periods are supported for domains:
* add grace period: the add grace period lasts 5 calendar days from the date of initial registration. When a domain is deleted in this period, it is immediately deleted and available for re-registration. The registrar is credited for an amount corresponding to the registration fee (unless the registrar is already over its monthly allowance of add grace transactions). A ‘renew’ command ends the add grace period. Note that it is impossible to perform a domain transfer in the add grace period (in fact, the first transfer is only allowed after 60 days of registration). To prevent misuse and domain tasting in particular, a policy applies as to the number of delete requests per month that are refunded during the add grace period (see below). Deletions in the add grace period exceeding this limit are not refunded.
* transfer grace period: the transfer grace period is currently 5 calendar days following a successfully completed domain transfer. If a domain is deleted in this timeframe, the sponsoring registrar is credited for the amount billed during the domain transfer. The transfer grace period is terminated when a restore, renew or subsequent domain transfer is performed.
* renew grace period: after each renew command, a 5 calendar day long renew grace period starts. When the domain is deleted in this timeframe, the registrar is credited for the corresponding fee and the domain enters REDEMPTION. A deletion, restoration or approved transfer of a domain immediately ends the renew grace period.
* auto-renew grace period: every auto-renew is followed by an auto-renew grace period (45 calendar days). If a domain is deleted or transferred within this period the fee for the renewal is refunded to the registrar. However, when a renew command is performed there is no grace period credit any more.

Refunds for deleting domains during an add grace period will follow ICANN’s Add Grace Period Limits Policy, available at: http:⁄⁄www.icann.org⁄en⁄tlds⁄agp-policy-17dec08-en.htm (including implementation notes).

The registry system supports the following pending periods in which certain operations are not allowed:
* Redemption Grace Period: consisting of
* Redemption Period: Whilst in this 30 day period, a domain can be restored after a deletion action (only if domain is not within the add grace period)
* Pending Restore: in order to successfully restore a domain in the redemption period, a restore report is required. This report has to be submitted within 7 days of this pending restore period. If no restore report is submitted, a new 30 day long redemption period begins.
* Pending Delete: If a domain is deleted and not restored, it is placed into the pending delete period following the redemption period. After 5 days in this period, the domain is finally available for re-registration.
* Pending Transfer Period: lasts for a maximum of 5 days after the initial transfer request command. The losing registrar has 5 days to approve or reject the request. The requestor may also cancel the transfer within this period. If no action is taken by the losing or gaining registrar, the registry auto-approves the transfer.

This registration life cycle matches the business model of the proposed gTLD. The proposed registry software fully supports this life cycle and the technical resources needed to run a registry based on the life cycle as described are readily available.

1.6 Resourcing

Three staff members of TLD-Box (the “Back-End Registry Operator” of the proposed gTLD) are experts in domain name life cycle, and have designed life cycles for the “.at”, “.bh” TLD, as well as consulted some other TLDs on their domain life cycle.
All other technical staff members as well as support staff (both at the ʺBack-End Registry Operatorʺ as with the ʺRegistry Operatorʺ) are trained on the operational aspects of the Domain Name Life Cycle.

There are only minor staff and⁄or infrastructure resources needed for the day to day operations in relation to the domain life cycle itself (since once developed, the resources to run the life cycle come from resources operating the EPP servers). In terms of on-going maintenance, it is expected that about 5 person days per year are required in order to clarify details, corner cases and relations to other business processes of the registry. Those 5 person days are budgeted for in the general maintenance time & resource budget of the registry.