27 Registration Life Cycle

Prototypical answer:

gTLDFull Legal NameE-mail suffixDetail
.medHEXAP SAShexap.comView

1. Overview

The registration life cycle for .MED Domain Name Registry is etched on the
life cycle of an open brand TLD.

However a stricter registration policy will be applied: at all times the
registration of a domain name will be subject to validation by at least one
Clearinghouse. During sunrises A and B, the Trademark Clearinghouse will be
consulted. Outside sunrise A, a specific .MED Clearinghouse (Medical
Clearinghouse) will be used. Also the request to update the registrant
handle (change of ownership) will be passed to the Medical Clearinghouse .

The following sections give an overview of the different actions that the
Registrar can perform to influence the state of a domain name. Some might
just change the state of the domain name. Others might alter the domain
nameʹs information such as name servers, contacts, DNSSEC keys and client
flags.

Some actions also involve interaction from the domain name Registry
Operator.

The domain name Registry Operator will never allow free domain name
registrations: all requests to register a domain name will need validation
by a clearinghouse. Hence the Domain Name Registry will be operating in a
permanent sunrise regime.

2. REGISTRATION LIFECYCLE

The time line of a domain name is schematically provided in Figure 1.

(View attachment for Figure 1: Domain Timeline)

The following paragraphs provide more detail on the different steps in the
time line.

2.1 REGISTRATION (UNDER SUNRISE REGIME)

- The Domain Name Registry Operator receives the domain create command

- The domain name goes into state pendingCreate

- The clearinghouse does validation of the domain name for the registrant

- The domain name is registered if properly validated, or canceled
otherwise.

2.2 UPDATE

- Add, remove or change of tech, admin, billing contact handle possible

- Add, remove or change of name servers possible

- Add, remove or change of DNSSEC keys possible

- Update registrant handle will put the domain name in the pendingUpdate
state. The change of ownership has to be validated by the Medical
Clearinghouse. The update proceeds if the validation is successful, or it
will be canceled otherwise. A successful update of the registrant handle
will result in the extension of the registration period with one year.
Regardless the outcome of the validation by the clearinghouse, the
operation will be billed to the registrar.

2.3. TRANSFER

- Transfer: change of Registrar

- Transfer command secured by authentication code

- Losing Registrar notified to accept or reject the transfer (after
consulting registrant and⁄or admin contact)

- A successful transfer extends the registration period with one year (up to
a maximum of ten years)

2.4. RENEW

Registrars use the Renew Domain command to extend the registration period of
a domain name. A Registrar can only renew domain names for which it is the
sponsoring registrar. The Renew Domain command can be specified with a
registration period, from one to ten years. The resulting expiry date must
not lay further than 10 years in the future.

- No auto renew by the Domain Name Registry on expiration of the domain
name.

- Explicit renewal of period needed in advance of the expiry date
(registration period can be extended up to 10 years)

2.5. DELETE

- Deletion puts domain name in redemption status

- Deleted from zone file instantly (serverHold)

2.6. REDEMPTION

- Domain name is no longer available in zone file (serverHold)

- Domain name can be restored before the end of the redemption grace period
(RGP)

- The domain name will be purged after the pendingDelete interval

2.7 AVAILABLE

Domain name comes back in the pool of available domain names.

3. RFC5731-COMPLIANT DOMAIN NAME STATUS CODES

The status information on a domain name 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
domain name will be rejected.

- clientHold, serverHold: DNS delegation information is not published for
the domain name.

- clientRenewProhibited, serverRenewProhibited: Requests to renew the domain
name are rejected.

- clientTransferProhibited, serverTransferProhibited: Requests to transfer
the domain name are rejected.

- clientUpdateProhibited, serverUpdateProhibited: Requests to update the
domain name, other than to remove this status, are rejected.

- inactive: Delegation information has not been associated with the domain
name. This is the default status when a domain name 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 a domain name 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 domain name has been received and
is being processed or evaluated.

- pendingDelete: Request to delete an existing domain name has been received
and is being processed or evaluated.

- pendingRenew: Request to renew an existing domain name has been received
and is being processed or evaluated.

- pendingTransfer: Request to transfer an existing domain name has been
received and is being processed or evaluated.

- pendingUpdate: Request to update an existing domain name 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
domain name Registry Operator.

The Domain Name Registry will implement the above statuses in full.

4. RFC3915-COMPLIANT DOMAIN NAME STATUS CODE

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 (RFC3915).

- addPeriod: This ʺadd 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 domain name registry provides a credit
to the registrar for the cost of the registration.

- autoRenewPeriod: This ʺauto-renew 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 ʺrenew 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 ʺtransfer 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. This status must be combined with the pendingDelete
status in the EPP domain mapping.

- pendingRestore: This status value is used to describe a domain that is in
the process of being restored after being in the redemptionPeriod state.
This status must be combined with the pendingDelete status in the EPP
domain mapping.

- pendingDelete: This status value is used to describe a domain that has
entered the purge processing state after completing the redemptionPeriod
state without succesful restoration. This status must be combined with the
pendingDelete status in the EPP domain mapping.

The Domain Name Registry will partially implement the above RGP statuses:
the statuses concerning the redemption of the domain name (redemptionPeriod,
pendingRestore, pendingDelete).

The following statuses will not be implemented:

- addPeriod: since all registrations pass through a permanent sunrise using
a Clearinghouse, no domain name tasting is implemented;

- autoRenewPeriod: because the domain name registry does not automatically
renew domain names;

- renewPeriod: because the registrar has explicitly and successfully issued
the renew command, no refund is granted;

- transferPeriod: because the registrar has explicitly and successfully
issued the transfer command, no refund is granted.

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

* pendingCreate

* pendingTransfer

* pendingDelete

* pendingUpdate

* 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)

6.3. REGISTRATION STATE DIAGRAM

The Registration state diagram shows all possible states and transactions
between those states.

The domain name life cycle can be found in the attached flow chart.

(View attachment for Figure 2: Registration State Diagram)

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)

9. RESOURCING PLAN

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: (0)

gTLDFull Legal NameE-mail suffixzDetail