27 Registration Life Cycle

Prototypical answer:

1. Overview
The registration life cycle for a private brand domain name Registry is completely different than for an open brand domain. Many of the requirements for open TLDs are not relevant for domain names which have a limited number of names under management and which will, most likely, use a very limited number of Registrars (most likely just one).

It is also likely that the domain names registration will not be traded, sold on the secondary market and transferred from one Registrar to another. In addition, it is likely that the names will be “registered” for very long life cycles (max. 10 years) within the life of the domain name registry itself.

This makes quarantine handling unnecessary.
• All transactions via a limited number of Registrars;
• Create Registrant, technical and billing contact;
• Register domain;
• Add or edit name servers, ns-groups;
• Transfer⁄trade (including execution date) not necessary‏;
• Delete (including deletion date)⁄undelete provided but probably not used;
• Transfer from quarantine not provided;
The following pages give an overview of the different processes that can be used by the Registrar to influence the state of a domain name. Some might change the state of the domain name. Others might just alter the domain nameʹs information such as name servers, contacts and others. Some processes also involve interactive tasks on the domain name Registryʹs side. There are two distinct phases in the TLD history which lead to different behavior. The first phase does not allow free registration. It typically consists of a number of sunrise periods where different parties under different circumstances are allowed to register certain domain names. The second phase is what is often referred to as general availability. It could start with a so called ʹland rushʹ period that allows the domain name registry to identify popular names.
 
2. Registration Lifecycle
(View attachment for Figure 1: Domain Timeline)
2.1. Registration (or Sunrise)
• Use EPP⁄web - first come-first served ⁄ validation via Trademark clearing house (TMCH)
• Create or reuse existing billing contact
• Create or reuse (at least 1) technical contact
• Create or reuse (at least 1) administrative contact
• Create or reuse Registrant contact
• Register domain (apply in case of sunrise)
• Confirm domain name through IPClaims service
• Domain is active (possibly after approval via TMCH)
2.2. Update
• Update tech, admin, billing contacts
• Update name servers, ns-groups
• Update Registrants
• Special policies possible e.g. only update Registrant ʹnameʹ (private) or ʹcompanyʹ (company)
• Additional : monitor transaction if needed?

2.3. Transfer
• Transfer: changing Registrar, same Registrant
• Registrar notified to acceptance or rejection of transfer or trade
• Extends registration period if possible
• Different scenarios are possible, including
• Request by Registrar using authorization code
 
2.4. Renew
Registrars use the Renew Domain command to extend the registration period of a domain object. A Registrar can only renew domain names for which it is the sponsoring registrar. The Renew Domain command must be specified with a registration period, from one to ten years. The resulting expiry date must not be more than 10 years in the future.
• Domain name is renewed automatically
• Domain name is renewed on a yearly basis
• Accepted transfer is paying
• Explicit renewal of period possible (period can be extended up to 10 years)
2.5. Delete
• Deletion can be canceled before effective execution date (RGP)
• Deleted from zone-file instantly
• Deleted domain can be restored (redemption period)?
2.6. Redemption
• Domain name is no longer available in DNS (serverHold)
• Can be restored
2.7. Available
• Domain comes back in the pool of available domain names
• First come - first served
• The time between release of the domain name and putting it back in the pool of available domain names, is fully configurable.
 
3. RFC5731-Compliant Domain Name Status Codes
The status information on a domain name object is in line with the flags described in RFC5731, section-2.2 and section 2.3. It is a combination of the following Status Value Descriptions:
• clientDeleteProhibited, serverDeleteProhibited: Requests to delete the object will be rejected.
• clientHold, serverHold: DNS delegation information is not published for the object.
• clientRenewProhibited, serverRenewProhibited: Requests to renew the object are rejected.
• clientTransferProhibited, serverTransferProhibited: Requests to transfer the object are rejected.
• clientUpdateProhibited, serverUpdateProhibited: Requests to update the object, other than to remove this status, are rejected.
• Inactive: Delegation information has not been associated with the object. This is the default status when a domain object is first created and there are no associated host objects or attributes for the DNS delegation. This status can also be set by the server when all host-object associations are removed.
• Ok: This is the normal status value for an object that has no pending operations or prohibitions. This value is set and removed by the server as other status values are added or removed.
• PendingCreate: Request to create a new object has been received and is being processed or evaluated.
• pendingDelete: Request to delete an existing object has been received and is being processed or evaluated.
• pendingRenew: Request to renew an existing object has been received and is being processed or evaluated.
• pendingTransfer: Request to transfer an existing object has been received and is being processed or evaluated.
• pendingUpdate: Request to update an existing object has been received and is being processed or evaluated.
Following combinations are excluded :
• ok cannot be combined with any other status
• pendingDelete status cannot be combined with ʺclientDeleteProhibitedʺ or ʺserverDeleteProhibitedʺ status
• ʺpendingRenewʺ cannot be combined with ʺclientRenewProhibitedʺ or ʺserverRenewProhibitedʺ status
• ʺpendingTransferʺ status cannot be combined with ʺclientTransferProhibitedʺ or ʺserverTransferProhibitedʺ status
• ʺpendingUpdateʺ status cannot be combined with ʺclientUpdateProhibitedʺ or ʺserverUpdateProhibitedʺ status
• pendingCreate, pendingDelete, pendingRenew, pendingTransfer and pendingUpdate cannot be combined
The status flags starting with the word ʹclientʹ can be changed and updated by the Registrar. The status flags starting with ʹserverʹ are handled by the Applicant.
 
4. RFC3915-Compliant Domain name status code
RFC3915 defines extra flags on the domain name that can be set or referenced by EPP. These flags are add to provide the following functionality
• An ʺadd grace periodʺ after the initial registration of a domain name. If the domain name is deleted by the Registrar during this period, the registry provides a credit to the Registrar for the cost of the registration.
• An ʺauto-renew grace periodʺ after a domain name registration period expires and is extended (renewed) automatically by the registry. If the domain name is deleted by the Registrar during this period, the registry provides a credit to the Registrar for the cost of the renewal.
• A ʺrenew grace periodʺ after a domain name registration period is explicitly extended (renewed) by the Registrar. If the domain name is deleted by the Registrar during this period, the registry provides a credit to the Registrar for the cost of the renewal.
• A ʺtransfer grace periodʺ after the successful transfer of domain name registration sponsorship from one Registrar to another Registrar. If the domain name is deleted by the new sponsoring Registrar during this period, the registry provides a credit to the Registrar for the cost of the transfer.
These flags are referred to as the RGP flags (Registry Grace Period). The following flags are defined and can be found in a separately available EPP extension called the rgp extension.
• addPeriod: This grace period is provided after the initial registration of a domain name. If the domain name is deleted by the Registrar during this period, the registry provides a credit to the Registrar for the cost of the registration.
• autoRenewPeriod: This grace period is provided after a domain name registration period expires and is extended (renewed) automatically by the registry. If the domain name is deleted by the Registrar during this period, the registry provides a credit to the Registrar for the cost of the renewal.
• renewPeriod: This grace period is provided after a domain name registration period is explicitly extended (renewed) by the Registrar. If the domain name is deleted by the Registrar during this period, the registry provides a credit to the Registrar for the cost of the renewal.
• transferPeriod: This grace period is provided after the successful transfer of domain name registration sponsorship from one Registrar to another Registrar. If the domain name is deleted by the new sponsoring Registrar during this period, the registry provides a credit to the Registrar for the cost of the transfer.
• redemptionPeriod: This status value is used to describe a domain for which a 〈delete〉 command has been received, but the domain has not yet been purged because an opportunity exists to restore the domain and abort the deletion process.
• pendingRestore: This status value is used to describe a domain that is in the process of being restored after being in the redemptionPeriod state.
pendingDelete: This status value is used to describe a domain that has entered the purge processing state after completing the redemptionPeriod state. A domain in this status MUST also be in the pendingDelete status described in the EPP domain mapping.  
5. Status code matrix
There are two types of status values. These may change as a result of the Client initiating a transform command referring to the commands referenced in the ʹClientʹ column or by the domain name Registry referring to the ʹServerʹ column. The last column referred to as ʹGeneralʹ contains flags that transitional status values.
(View attachment for Table 1: Status Code Matrix)
The Prohibited flags have no influence on the status of the domain object. They prevent the denoted command from being executed on the domain name object. As such when set, they prevent the transform command from being executed and hence block the specified domain name life cycle transition. They have no influence on state of the domain name object.
 
6. Status transitions
6.1. Global status transitions
The following domain name states can be determined
• The domain name status is defined as ʹavailable for registrationʹ (in short ʹavailableʹ) if the domain name is conform to the registration policy and the domain name object does not exist.
• The domain name is registered (no pending actions).
• The domain name has a pending action. This can be one of the following
o pendingCreate
o pendingTransfer
o pendingDelete
o pendingUpdate
o pendingRenew
(View attachment for Table 2: Exhaustive list of transitions)
Some transitions might be influenced by the registration policy. For instance
• The create has to be verified by the domain name Registry to see if no conflicts or infringements are detected.
• The name servers added to the domain name object have to comply with certain rules set forth in the policy.
• Change of ownership has to be verified.
• Domain name matches predefined rule set needing registry acceptance.
This is a non-exhaustive list which should reflect domain name registration policy regulations.
6.2. Registry grace period status transitions
The following domain name states are added to the domain name object when it has the EPP pendingDelete status:
• redemptionPeriod
• pendingRestore
• pendingDelete
(View attachment for Table 3: Exhaustive list of 3c pendingDelete state transitions)
 
7. Transition commands
The following domain object commands can be used to trigger status transitions:
(View attachment for Table 4: Transition commands)
 
8. Registry transitions
The following domain object commands can be used to trigger status transitions:
(View attachment for Table 5: Registry status transitions)
A number of these status flags and settings are irrelevant to the Applicant’s model.
As a single-Registrar Registry, transfer of domain names is not provided, nor is a quarantine registration state applicable. Therefore all flags linked to transfer can be ignored and the handling of domain names in quarantine is greatly simplified. The domain name life cycle can be found in the attached flow chart.
(View attachment for Figure 2: Registration State Diagram)

 
9. Resourcing Plan
9.1. Personnel
With regards to resourcing, reference is made to the global resourcing scheme as part of response to Question 31 (Technical Overview of the Proposed Registry). Implementation and maintenance of the Registration Lifecycle in the Registry Platform is under the authority of the Software Developer, under control of the Operations Manager.

Similar gTLD applications: (3)