Back

27 Registration Life Cycle

gTLDFull Legal NameE-mail suffixDetail
.chromeCharleston Road Registry Inc.google.comView
Charleston Road Registry (CRR) sets forth below a description of the various stages and states of a second-level domain (SLD) in its proposed registry system. Please see “Q27_Registry Life Cycle Diagram” for a graphical depiction of the domain registration lifecycle.

27.1. Life Cycle States

The following registration life cycle states are described in the sections below:

- Reserved
- Available
- Add Grace Period
- Registered
- Renew Grace Period
- Auto-Renew Grace Period
- Pending Restore
- Redemption Grace Period
- Pending Delete
- Pending Transfer
- Transfer Grace Period

State changes provide specific use cases to the DNS (Domain Name System) architecture explained in responses for Question 31 (Technical Overview), Question 32 (Architecture) and Question 35 (DNS Service). Note that this response makes references to EPP (Extensible Provisioning Protocol) functionality which is fully described in Question 25. Additionally, state changes may change the information retrievable via Registration Data Directory Services (RDDS, a combination of WHOIS and Web-based WHOIS) as described in Question 26.

27.2. Reserved

Reserved domains are not generally available to register. For example, such restrictions may result from agreements with ICANN⁄IANA for operational⁄technical reasons or with governments for geographic names. See response to Question 22 (Protection of Geographic Names) for further details. The registry will maintain a schedule of reserved words as per Specification 5 of the Registry Agreement. For a reserved domain, an EPP 〈check〉 query would return a value of avail=ʺ0ʺ, and there would be no entry in the zone file or RDDS associated with the domain name. EPP 〈create〉 requests will result in a rejection, except those that have prior approval from CRR. The registry foresees two cases as envisioned by Specification 5 of the New gTLD Agreement, particularly applicable to geographic names: 1) CRR releases an SLD for use by the applicable government or country-code manager. In this case, at the end of the registration, the SLD would return to the Reserved state. 2) CRR works with the affected government(s) or country-code manager(s) to permanently make available SLD(s). In this case, at the end of a reservation the string would revert to the Available state.

In addition to an explicit Reserved state, CRR will also support a functional equivalent to reserving through registration. This approach follows the practices of the .info registry. That is, CRR will reserve certain names by registering them for the registry, pursuant to Section 2.6 of the gTLD registry agreement. Names reserved using this approach follow the life cycle described below. Generally, CRR will use the state machine to control reservations but leaves open the possibility of using reservation by registration when more appropriate.

27.3. Available

If a second level domain (SLD) is not reserved, it is considered available if either of the following holds true:
- The SLD has not existed previously.
- The SLD has passed through the Pending Delete state.

Domains that are available do not exist in the zone file or RDDS. The Shared Registry System - Back End (SRS-BE) would return a value of avail=ʺ1ʺ when responding to the EPP 〈check〉 query for domain in the Available state.

All other states would return a value of avail=ʺ0ʺ.

27.4. Add Grace Period (AGP)

Names that are selected for registration are entered into the zone file at the start of this five-day add-grace period (〈addPeriod〉). Registrars are charged for submitting 〈create〉 requests to the registry.

The Google SRS-Backend (GSRS-BE) manages the 5-day grace period countdown, including the transition of the state to Registered. During the Add Grace Period, registrars can cancel the registration and receive a credit for the cost of the original registration (with domain names becoming immediately Available or Reserved, as appropriate), subject to ICANNʹs AGP Limits Policy. GSRS-BE will set the status of the Domain Name to 〈addPeriod〉 while making the zone file and RDDS updates, and then reset it when grace period ends.

27.5. Registered

Owners of domain names can register them for a period of one to ten years. The registrar may renew the SLD for no less than one and no more than ten years from the current day using the EPP 〈renew〉 command. GSRS-BE will manage state changes based on expiration date of domains, including updates to the zone file and RDDS. By default, status of the object is “ok”. Subsequent EPP 〈transform〉 commands or actions by SRS-BE may change that value to indicate restrictions present or transformations pending.

27.6 Renew Grace Period (RGP)

Upon receipt of a 〈renew〉 EPP command, SRS-BE will transition the domain name to the state of Renew Grace Period (〈renewPeriod〉). The renew grace period allows registrars to correct the mistaken renewal of an SLD. The Renew Grace Period lasts for five (5) days during which the receipt of a 〈delete〉 EPP command will result in the crediting back to the registrar the cost of the renewal. After this grace period ends, the domain name will revert to the Registered state. Domains in the RGP may transition to the following states: Redemption Grace Period (by meaning of a delete) or Pending Transfer (by means of a transfer) as described in sections 27.8 and 27.11, respectively.

27.7. Auto-Renew Grace Period (ARGP)

GSRS-BE will automatically renew a registration once it has expired and charge the registrar the current renewal fee. By default, CRR will extend the registration for one year. The ARGP is intended to allow registrars to delete a registration which has been auto-renewed and to receive a refund for the renewal fee. For the first 45 days after an automatic renewal, the domain is in state of the Auto-Renew Grace Period (〈autoRenewPeriod〉). During this 45-day grace period, GSRS-BE will accept requests from the EPP for the existing owner to update, renew, transfer and delete the registration provided there is not a corresponding status that prohibits the transformation. The registrar will then be charged the cost of this new transaction. If the registry happens to receive a 〈delete〉 EPP command during the ARGP, CRR will credit the cost of a renewal to the registrar. Without intervention, SRS-BE will then update the domain’s state to Registered.

27.8. Redemption Grace Period (RdGP)

SLDs that are deleted, such as when a registrar uses the 〈delete〉 EPP command, then enter the Redemption Grace Period (RdGP) (〈redemptionPeriod〉), with the exception of those deleted during the Add Grace Period (see above). The RdGP permits registrars to restore domains that were mistakenly deleted. The RdGP lasts for thirty (30) days. SRS-BE will first check for a clientDeleteProhibited or a serverDeleteProhibited prohibition before making the transition, and will not make the transition if those prohibitions exist.

Domains which enter this state become non-operational and are removed from the zone file and RDDS. The SRS-BE will accomplish this change by updating the DNS service. GSRS-BE will also set the status to “pendingDelete”.

During the RdGP, the SRS-BE will reject all EPP requests other than 〈restore〉. Registrars have 30 days to submit a 〈restore〉 request in order for the transaction to be accepted and the transaction cost credited back to the registrar. Registrars must provide a 〈report〉 that provides, among other things, a reason (〈resReason〉) and supporting information (〈statement〉) within 5 days (during which time the status will be Pending Restore or 〈pendingRestore〉). CRR will not process a 〈restore〉 without a 〈report〉. If a 〈restore〉 request is not received or if a 〈report〉 is not received on time, GSRS-BE transitions the domain name to the Pending Delete state. Should a registrar reactivate the domain, SRS-BE will update the DNS zone file and RDDS. When complete, SRS-BE will update the state to Registered.

27.9. Pending Delete

This state is the final stage of the lifecycle prior to the domain again being made available. It lasts for 5 days. During this period, registrars shall not have the ability to reactivate the domain, but would have to wait to make a new request once the domain becomes available. During the Pending Delete phase, the SRS-BE will reject all requests to transform a domain name received through the EPP interface. The status of the domain name will be 〈pendingDelete〉. After this stage, the domain shall be removed from the registry’s database and once again made available for registration.

27.10. Released⁄Available

As noted above, at the conclusion of the Pending Delete state, GSRS-BE removes the domain name entirely from its database. It is now available for registrars. See 27.3 above for further details of “Available” state. The exception would be those domain names on the reserved list, which will instead return to the Reserved state after they are released.

27.11. Transfers

CRR and Google will adhere to the 15 March 2009 ICANN Policy on Transfer of Registrations (as well as its successor scheduled to take effect on 1 June 2012). Therefore, registrars are allowed to transfer domains between each other, provided that the states and status allow for it.

Transfer requires the following conditions:
- The domain must be in one of the following states: Add Grace Period, Registered, Renew Grace Period, Transfer Grace Period, or Auto Renew Grace Period.
- Neither a clientTransferProhibited nor a serverTransferProhibited status must be present.

Provided those two conditions are met, GSRS-BE will set the status to 〈pendingTransfer〉 while it performs its activities (during this period, the domain is considered to be in the Pending Transfer state). First, the registry will notify both registrars of the pending transfer. The registry will complete the transfer if it receives an 〈ACK〉 response from the Registrar of Record if received within the first five (5) days. If after five (5) days and the registry has not received any message, the transfer will be automatically completed. If a 〈NACK〉 response is received from the Registrar of Record, the transfer will be rejected. A rejected transfer would result in the SRS-BE setting the state back to its previous value.

Upon completion of the transfer, CRR will update the zone file and RDDS and send another notification to both registrars. When a transfer is complete, the registration period for the SLD is extended by a year (but not to exceed ten (10) years from the date of the transfer) and the gaining registrar will be charged for submitting a 〈transfer〉 EPP request.

27.11.1. Transfer Grace Period (TGP)

The registry places the domain name into the Transfer Grace Period (〈transferPeriod〉) for the first 5 days after the completion of the 〈transfer〉 request. During this time, the Gaining registrar will receive a credit for the cost of the transfer if a 〈delete〉 EPP transaction is received. Provided the domain is not deleted, at the end of the 5 day period the domain will return to the Registered state. A transfer received during TGP would result in the domain moving to 〈pendingTransfer〉 as described above.

27.12. Resourcing

Google Inc. will implement these technical requirements using the teams and resources discussed below.

The cost of these services will generally be set at reasonable market rates per agreement between Charleston Road Registry and Google. The expected costs are discussed in Questions 46 and 47.

27.12.1. Registry Team

The Registry Team will be responsible for designing and implementing the SRS, EPP, and WHOIS systems, including details related to domain name lifecycle. They will also be responsible for creating tests and monitoring for these systems.

During initial implementation, this team will consist of at least 4-7 software engineers responsible for implementing the project. Additionally, Google plans to staff one software engineer who is responsible for engineering testing and monitoring for the registry, and one software engineer who is responsible for backup, restoration and escrow. In total, Google plans to implement the registry with a team of 6-9 software engineers.

After the registry is complete, Google expects to staff a team to support the ongoing operation of the registry. This team will consist of at least four engineers who will participate in on-call rotation, respond to alerts, provide support to ICANN and registrars for emergency escalations, and maintain responsibility for bug fixes and improvements. This team will continue maintenance throughout the life of the registry.

This team’s responsibilities will generally be limited to registry-specific components. The Registry Team will work closely with other relevant teams, including the Authoritative DNS support team, Storage Site Reliability Engineering team, network engineering and operations, and customer support teams. These other teams are described in more detail in Question 31 (Section 31.16), as well as the relevant sections throughout this application.

27.12.2. Customer Services Team

The Google Customer Services Team will be responsible for supporting customers and partners, including life cycle requests. Google has a very large existing customer service team of both internal staff as well as staff contracted through third parties, with many hundreds of dedicated staff members already in place. Since these teams and their management are already in place, no standalone implementation resources are needed.

To continue ongoing maintenance of CRR support needs, Google plans to add additional resources for capacity as needed. Google expects to add a total of approximately fifteen additional personnel (including both Google employees and outside vendors) to support all of CRR’s customers and partners. The individual staffing allocation to each TLD is described in Question 47.

27.13. Summary and Key Insights

- The registry will support a full registration lifecycle consistent with that offered by other major gTLDs. State changes are triggered by registrar commands via the EPP interface or by the SRS-BE, which manages changes triggered by the passage of time.
gTLDFull Legal NameE-mail suffixDetail
.gmbhCharleston Road Registry Inc.google.comView
Charleston Road Registry (CRR) sets forth below a description of the various stages and states of a second-level domain (SLD) in its proposed registry system. Please see “Q27_Registry Life Cycle Diagram” for a graphical depiction of the domain registration lifecycle.

27.1. Life Cycle States

The following registration life cycle states are described in the sections below:

- Reserved
- Available
- Add Grace Period
- Registered
- Renew Grace Period
- Auto-Renew Grace Period
- Pending Restore
- Redemption Grace Period
- Pending Delete
- Pending Transfer
- Transfer Grace Period

State changes provide specific use cases to the DNS (Domain Name System) architecture explained in responses for Question 31 (Technical Overview), Question 32 (Architecture) and Question 35 (DNS Service). Note that this response makes references to EPP (Extensible Provisioning Protocol) functionality which is fully described in Question 25. Additionally, state changes may change the information retrievable via Registration Data Directory Services (RDDS, a combination of WHOIS and Web-based WHOIS) as described in Question 26.

27.2. Reserved

Reserved domains are not generally available to register. For example, such restrictions may result from agreements with ICANN⁄IANA for operational⁄technical reasons or with governments for geographic names. See response to Question 22 (Protection of Geographic Names) for further details. The registry will maintain a schedule of reserved words as per Specification 5 of the Registry Agreement. For a reserved domain, an EPP 〈check〉 query would return a value of avail=ʺ0ʺ, and there would be no entry in the zone file or RDDS associated with the domain name. EPP 〈create〉 requests will result in a rejection, except those that have prior approval from CRR. The registry foresees two cases as envisioned by Specification 5 of the New gTLD Agreement, particularly applicable to geographic names: 1) CRR releases an SLD for use by the applicable government or country-code manager. In this case, at the end of the registration, the SLD would return to the Reserved state. 2) CRR works with the affected government(s) or country-code manager(s) to permanently make available SLD(s). In this case, at the end of a reservation the string would revert to the Available state.

In addition to an explicit Reserved state, CRR will also support a functional equivalent to reserving through registration. This approach follows the practices of the .info registry. That is, CRR will reserve certain names by registering them for the registry, pursuant to Section 2.6 of the gTLD registry agreement. Names reserved using this approach follow the life cycle described below. Generally, CRR will use the state machine to control reservations but leaves open the possibility of using reservation by registration when more appropriate.

27.3. Available

If a second level domain (SLD) is not reserved, it is considered available if either of the following holds true:
- The SLD has not existed previously.
- The SLD has passed through the Pending Delete state.

Domains that are available do not exist in the zone file or RDDS. The Shared Registry System - Back End (SRS-BE) would return a value of avail=ʺ1ʺ when responding to the EPP 〈check〉 query for domain in the Available state.

All other states would return a value of avail=ʺ0ʺ.

27.4. Add Grace Period (AGP)

Names that are selected for registration are entered into the zone file at the start of this five-day add-grace period (〈addPeriod〉). Registrars are charged for submitting 〈create〉 requests to the registry.

The Google SRS-Backend (GSRS-BE) manages the 5-day grace period countdown, including the transition of the state to Registered. During the Add Grace Period, registrars can cancel the registration and receive a credit for the cost of the original registration (with domain names becoming immediately Available or Reserved, as appropriate), subject to ICANNʹs AGP Limits Policy. GSRS-BE will set the status of the Domain Name to 〈addPeriod〉 while making the zone file and RDDS updates, and then reset it when grace period ends.

27.5. Registered

Owners of domain names can register them for a period of one to ten years. The registrar may renew the SLD for no less than one and no more than ten years from the current day using the EPP 〈renew〉 command. GSRS-BE will manage state changes based on expiration date of domains, including updates to the zone file and RDDS. By default, status of the object is “ok”. Subsequent EPP 〈transform〉 commands or actions by SRS-BE may change that value to indicate restrictions present or transformations pending.

27.6 Renew Grace Period (RGP)

Upon receipt of a 〈renew〉 EPP command, SRS-BE will transition the domain name to the state of Renew Grace Period (〈renewPeriod〉). The renew grace period allows registrars to correct the mistaken renewal of an SLD. The Renew Grace Period lasts for five (5) days during which the receipt of a 〈delete〉 EPP command will result in the crediting back to the registrar the cost of the renewal. After this grace period ends, the domain name will revert to the Registered state. Domains in the RGP may transition to the following states: Redemption Grace Period (by meaning of a delete) or Pending Transfer (by means of a transfer) as described in sections 27.8 and 27.11, respectively.

27.7. Auto-Renew Grace Period (ARGP)

GSRS-BE will automatically renew a registration once it has expired and charge the registrar the current renewal fee. By default, CRR will extend the registration for one year. The ARGP is intended to allow registrars to delete a registration which has been auto-renewed and to receive a refund for the renewal fee. For the first 45 days after an automatic renewal, the domain is in state of the Auto-Renew Grace Period (〈autoRenewPeriod〉). During this 45-day grace period, GSRS-BE will accept requests from the EPP for the existing owner to update, renew, transfer and delete the registration provided there is not a corresponding status that prohibits the transformation. The registrar will then be charged the cost of this new transaction. If the registry happens to receive a 〈delete〉 EPP command during the ARGP, CRR will credit the cost of a renewal to the registrar. Without intervention, SRS-BE will then update the domain’s state to Registered.

27.8. Redemption Grace Period (RdGP)

SLDs that are deleted, such as when a registrar uses the 〈delete〉 EPP command, then enter the Redemption Grace Period (RdGP) (〈redemptionPeriod〉), with the exception of those deleted during the Add Grace Period (see above). The RdGP permits registrars to restore domains that were mistakenly deleted. The RdGP lasts for thirty (30) days. SRS-BE will first check for a clientDeleteProhibited or a serverDeleteProhibited prohibition before making the transition, and will not make the transition if those prohibitions exist.

Domains which enter this state become non-operational and are removed from the zone file and RDDS. The SRS-BE will accomplish this change by updating the DNS service. GSRS-BE will also set the status to “pendingDelete”.

During the RdGP, the SRS-BE will reject all EPP requests other than 〈restore〉. Registrars have 30 days to submit a 〈restore〉 request in order for the transaction to be accepted and the transaction cost credited back to the registrar. Registrars must provide a 〈report〉 that provides, among other things, a reason (〈resReason〉) and supporting information (〈statement〉) within 5 days (during which time the status will be Pending Restore or 〈pendingRestore〉). CRR will not process a 〈restore〉 without a 〈report〉. If a 〈restore〉 request is not received or if a 〈report〉 is not received on time, GSRS-BE transitions the domain name to the Pending Delete state. Should a registrar reactivate the domain, SRS-BE will update the DNS zone file and RDDS. When complete, SRS-BE will update the state to Registered.

27.9. Pending Delete

This state is the final stage of the lifecycle prior to the domain again being made available. It lasts for 5 days. During this period, registrars shall not have the ability to reactivate the domain, but would have to wait to make a new request once the domain becomes available. During the Pending Delete phase, the SRS-BE will reject all requests to transform a domain name received through the EPP interface. The status of the domain name will be 〈pendingDelete〉. After this stage, the domain shall be removed from the registry’s database and once again made available for registration.

27.10. Released⁄Available

As noted above, at the conclusion of the Pending Delete state, GSRS-BE removes the domain name entirely from its database. It is now available for registrars. See 27.3 above for further details of “Available” state. The exception would be those domain names on the reserved list, which will instead return to the Reserved state after they are released.

27.11. Transfers

CRR and Google will adhere to the 15 March 2009 ICANN Policy on Transfer of Registrations (as well as its successor scheduled to take effect on 1 June 2012). Therefore, registrars are allowed to transfer domains between each other, provided that the states and status allow for it.

Transfer requires the following conditions:
- The domain must be in one of the following states: Add Grace Period, Registered, Renew Grace Period, Transfer Grace Period, or Auto Renew Grace Period.
- Neither a clientTransferProhibited nor a serverTransferProhibited status must be present.

Provided those two conditions are met, GSRS-BE will set the status to 〈pendingTransfer〉 while it performs its activities (during this period, the domain is considered to be in the Pending Transfer state). First, the registry will notify both registrars of the pending transfer. The registry will complete the transfer if it receives an 〈ACK〉 response from the Registrar of Record if received within the first five (5) days. If after five (5) days and the registry has not received any message, the transfer will be automatically completed. If a 〈NACK〉 response is received from the Registrar of Record, the transfer will be rejected. A rejected transfer would result in the SRS-BE setting the state back to its previous value.

Upon completion of the transfer, CRR will update the zone file and RDDS and send another notification to both registrars. When a transfer is complete, the registration period for the SLD is extended by a year (but not to exceed ten (10) years from the date of the transfer) and the gaining registrar will be charged for submitting a 〈transfer〉 EPP request.

27.11.1. Transfer Grace Period (TGP)

The registry places the domain name into the Transfer Grace Period (〈transferPeriod〉) for the first 5 days after the completion of the 〈transfer〉 request. During this time, the Gaining registrar will receive a credit for the cost of the transfer if a 〈delete〉 EPP transaction is received. Provided the domain is not deleted, at the end of the 5 day period the domain will return to the Registered state. A transfer received during TGP would result in the domain moving to 〈pendingTransfer〉 as described above.

27.12. Resourcing

Google Inc. will implement these technical requirements using the teams and resources discussed below.

The cost of these services will generally be set at reasonable market rates per agreement between Charleston Road Registry and Google. The expected costs are discussed in Questions 46 and 47.

27.12.1. Registry Team

The Registry Team will be responsible for designing and implementing the SRS, EPP, and WHOIS systems, including details related to domain name lifecycle. They will also be responsible for creating tests and monitoring for these systems.

During initial implementation, this team will consist of at least 4-7 software engineers responsible for implementing the project. Additionally, Google plans to staff one software engineer who is responsible for engineering testing and monitoring for the registry, and one software engineer who is responsible for backup, restoration and escrow. In total, Google plans to implement the registry with a team of 6-9 software engineers.

After the registry is complete, Google expects to staff a team to support the ongoing operation of the registry. This team will consist of at least four engineers who will participate in on-call rotation, respond to alerts, provide support to ICANN and registrars for emergency escalations, and maintain responsibility for bug fixes and improvements. This team will continue maintenance throughout the life of the registry.

This team’s responsibilities will generally be limited to registry-specific components. The Registry Team will work closely with other relevant teams, including the Authoritative DNS support team, Storage Site Reliability Engineering team, network engineering and operations, and customer support teams. These other teams are described in more detail in Question 31 (Section 31.16), as well as the relevant sections throughout this application.

27.12.2. Customer Services Team

The Google Customer Services Team will be responsible for supporting customers and partners, including life cycle requests. Google has a very large existing customer service team of both internal staff as well as staff contracted through third parties, with many hundreds of dedicated staff members already in place. Since these teams and their management are already in place, no standalone implementation resources are needed.

To continue ongoing maintenance of CRR support needs, Google plans to add additional resources for capacity as needed. Google expects to add a total of approximately fifteen additional personnel (including both Google employees and outside vendors) to support all of CRR’s customers and partners. The individual staffing allocation to each TLD is described in Question 47.

27.13. Summary and Key Insights

- The registry will support a full registration lifecycle consistent with that offered by other major gTLDs. State changes are triggered by registrar commands via the EPP interface or by the SRS-BE, which manages changes triggered by the passage of time.