Back

25 Extensible Provisioning Protocol (EPP)

gTLDFull Legal NameE-mail suffixDetail
.chromeCharleston Road Registry Inc.google.comView
The primary purpose of Google EPP will be to provide for a provisioning interface to the Google Registry using the standardized EPP protocol.

Google has no initial plans to provide a software development kit, since there already are a variety of open- and closed-source EPP client implementations available on the web today.

Google’s EPP service will act as a connector between EPP clients and Google’s backend systems, which will handle business logic for registry operations.

25.1. RFC Compliance

Google’s EPP interface will handle the follow tasks:

- Listen for EPP connections over port 700.
- Support and maintain the EPP session through the life of the connection.
- Translate EPP requests and responses between equivalent requests and responses exposed by the Google SRS Backend private API.
- Terminate the Transport Security Layer (TLS) connection as defined by RFC 5734. TLS client certificates will be self-certified and transmitted to Google via the registrar application process. The credentials in the certificate will be matched against the account identified by the EPP username and password.

Google EPP will support a well-defined set of EPP RFCs with no additional EPP extensions.

25.1.1. Core Protocol - RFC 5730 (http:⁄⁄tools.ietf.org⁄html⁄rfc5730)

RFC 5730 defines EPP, a simple object provisioning XML protocol. The base protocol itself is agnostic to the type of objects being provisioned and allows for extensions to the protocol.

Upon connection, a session is established with a 〈greeting〉 message from the server as defined by the RFC. From there, the client will login with a 〈login〉 command, then entertain a series of request and response cycles, and then finally ends the session with a 〈logout〉 command.

All EPP commands will be supported according to the RFC in their standard command and response formats.

As part of the 〈greeting〉, a 〈dcp〉 element is presented indicating Google’s data-collection-policy for the Registry. In general, the 〈dcp〉 element will attempt to mirror (as far as the protocol can mirror) Google’s Privacy Policy as stated in http:⁄⁄www.google.com⁄policies⁄privacy⁄. A copy of our full Privacy Policy as of March 1, 2012, is also included in Question 31 as an attachment.

For all commands, only objects defined by RFCs 5731 (domains), 5732 (hosts), and 5733 (contacts) will be supported. No other extensions will be used.

For the 〈login〉 command, the following policy specifics will be implemented:
- A maximum of three failed login attempts per connection
- On the 12th failed login attempt, the account will be locked out and require support to reactivate.
- Changing the EPP password with the optional 〈newPW〉 element will not be supported. Password changes will instead be handled through the password change interface on the Google SRS Front End. Error code 2501, ʺAuthentication error; server closing connectionʺ will always be returned if this command is used.
- The 〈version〉 element must be set to 1.0.
- The 〈lang〉 element must be set to “en”.

For all other EPP commands there will be no implementation policy specifics.

Standard behavior as defined by the RFC for each command is expected:
- 〈check〉: Determine if an object can be provisioned within the registry
- 〈info〉: Retrieve information associated with a given object
- 〈poll〉: Discover and retrieve service messages by a server for individual clients
- 〈create〉: Create an instance of an object
- 〈delete〉: Remove an instance of an existing object
- 〈renew〉: Extend the validity of an existing object
- 〈transfer〉: Determine real-time status of pending and completed transfer requests
- 〈transfer op=”request”〉: Request that an object be transferred
- 〈transfer op=”approve”〉: Approve a transfer request
- 〈transfer op=”reject”〉: Reject a transfer request
- 〈transfer op=”cancel”〉: Cancel a transfer request
- 〈update〉: Update the information in an existing object

25.1.2. Domain Objects - RFC 5731 (http:⁄⁄tools.ietf.org⁄html⁄rfc5731)

RFC 5731 defines support for domain objects over the EPP protocol.

Since RFC 5732 will be supported as well, domain objects will not be able to specify attributes to describe a name server host machine, but rather must reference the relevant host with 〈domain:hostObj〉 references.

When 〈domain:authInfo〉 is used, a 〈domain:pw〉 must be passed within to denote the password for the domain (or registrant using the “roid” attribute to denote this), or a 〈domain:null〉 to null it out.

For EPP commands dealing with domain object validity, domains will be by default valid indefinitely unless otherwise specified.

A 2305 error response code will be issued if there are dependent children subordinate to the domain, which still exist in the repository if a 〈delete〉 command is issued.

For all domains which require additional vetting of the registrant because of gTLD registration policy reasons, offline review of the domain may occur for transformation EPP commands. Otherwise, no offline review will occur in general.

25.1.3. Host Objects - RFC 5732 (http:⁄⁄tools.ietf.org⁄html⁄rfc5732)

RFC 5732 provides EPP mappings for host objects. This RFC will be supported in its entirety. There are no special considerations needed for the Google Registry.

There will be no offline review before provisioning of any host.

25.1.4. Contact Objects - RFC 5733 (http:⁄⁄tools.ietf.org⁄html⁄rfc5733)

This RFC provides EPP mapping for contact objects. This RFC will be supported in its entirety.

As specified by the RFC, unless prohibited by the server’s stated data collection policy, per-field disclosure policies will be supported via the 〈contact:disclose〉 element when provisioning contacts.

There will be no offline review before provisioning of any contact.

25.1.5. EPP Transport over TCP - RFC 5734 (http:⁄⁄tools.ietf.org⁄html⁄rfc5734)

RFC 5734 defines connection handling procedures regarding the EPP mechanism.

The following policy is adopted from suggestions from this RFC:
-There will be no more than ten concurrent TCP connections from a single source destination IP without first contacting Google to establish an alternate upper limit.
- If a well-formed EPP request is not received at least every 30 seconds, the TCP⁄IP connection may be severed.
- TLS is mandatory to connect to Google EPP.
- A single TLS client certificate will be required for each EPP user and password pair. Multiple user⁄password pairs will not be permitted for a single TLS client certificate.
- A Certificate Name (CN) and subject AltName:dnsName will be set to the hostname of GEPP to be validated against by the client.

25.1.6. DS records - RFC 5910 (http:⁄⁄tools.ietf.org⁄html⁄rfc5910)

RFC 5910 governs the additions to the EPP domain mapping RFC for provisioning DS records for a particular domain. Of the two possible supported mechanisms by the RFC, Google EPP will support the ʺDS Data Interfaceʺ, where the client is responsible for the creation of the DS information and is required to pass DS information when performing adds and removes.

Other particular implementation specifics include:
- The optional 〈secDNS:maxSigLife〉 element will not be initially supported, and a 2102 error code will be returned.
- 〈secDNS:update〉 with an attribute of urgent will not be initially supported, and a 2102 error code will be returned if present.

25.1.7. Grace periods - RFC 3915 (http:⁄⁄tools.ietf.org⁄html⁄rfc3915)

RFC 3915 extends the EPP RFCs to account for grace period functionality. Grace periods allow for actions to be reversed or revoked within a specified period of time. In particular, this RFC governs four grace periods: add grace period, auto renew grace period, renew grace period and transfer grace period. Google will comply with this RFC in its entirety.

25.1.8. IDN RFCs

In addition to RFCs directly related to EPP, RFCs defining internationalized domain names (IDN) (5890, 5891, 5892, and 5893) and how they are specified will be implemented for Google EPP. In particular, IDNs will be specified using punycode and in the subset of unicode character code points dictated by the IDN tables attached to this gTLD application.

25.2. EPP Extensions

Beyond RFC 5910 which extends EPP to support DNSSEC DS records, no additional EPP extensions will be implemented or supported.

25.3. Google EPP Testing

Google will develop Google EPP using a software methodology, which ensures correct functionality by concurrently developing unit and large functional tests alongside the production code itself. Standard XML parsing libraries will be used depending on the implementation language. Implementation will also include monitoring rules that test EPP workflows in production on an ongoing basis. Before deploying to production, Google will create staging environments during development for internal manual and automated testing.

25.4. Operational Testing and Evaluation for Registrars

All ICANN-accredited registrars must first complete operational testing and evaluation (OT&E) before submitting EPP commands through the production Google EPP environment. The aim of this testing is to ensure that registrars are functioning properly.

OT&E instructions will be presented to the registrar after it has created a registrar account with the Google Registry. In general, these instructions will include a series of ordered EPP commands the registrar must perform along with test account credentials.

The registrar, once the registrar is ready for certification, it will request a Google Registry Front End evaluation. The test environment will reset to a nominal state, and at this point, the registrar must execute the series of ordered EPP commands within a specified amount of time. If registrar fails OT&E, the registrar will be notified of the failure, and can try again at a later date. If the registrar passes OT&E, the registrar will be notified, and be given production EPP credentials.

25.5. Resourcing Plans

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.

25.5.1. Registry Team

The Registry Team will be responsible for designing and implementing the shared registration system (SRS), EPP, and WHOIS systems, including IDNs. They will also be responsible for creating tests and monitoring for these systems.

During initial implementation, this team will consist of at least four to seven 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 six to nine 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.

25.6. Summary and Key Insights

Google can design, build and run EPP interface that meets the requirements of a gTLD registry because of:
- A thorough understanding of the requirements for the systems.
- A reuse of existing industry, standard EPP XML schemas to de-risk system implementation.
- A proven software development methodology that will verify implementation against requirements.
- Operational procedures that facilitate the ongoing maintenance of the platform and the support of onboarding of new registrars.
gTLDFull Legal NameE-mail suffixDetail
.youtubeCharleston Road Registry Inc.google.comView
The primary purpose of Google EPP will be to provide for a provisioning interface to the Google Registry using the standardized EPP protocol.

Google has no initial plans to provide a software development kit, since there already are a variety of open- and closed-source EPP client implementations available on the web today.

Google’s EPP service will act as a connector between EPP clients and Google’s backend systems, which will handle business logic for registry operations.

25.1. RFC Compliance

Google’s EPP interface will handle the follow tasks:

- Listen for EPP connections over port 700.
- Support and maintain the EPP session through the life of the connection.
- Translate EPP requests and responses between equivalent requests and responses exposed by the Google SRS Backend private API.
- Terminate the Transport Security Layer (TLS) connection as defined by RFC 5734. TLS client certificates will be self-certified and transmitted to Google via the registrar application process. The credentials in the certificate will be matched against the account identified by the EPP username and password.

Google EPP will support a well-defined set of EPP RFCs with no additional EPP extensions.

25.1.1. Core Protocol - RFC 5730 (http:⁄⁄tools.ietf.org⁄html⁄rfc5730)

RFC 5730 defines EPP, a simple object provisioning XML protocol. The base protocol itself is agnostic to the type of objects being provisioned and allows for extensions to the protocol.

Upon connection, a session is established with a 〈greeting〉 message from the server as defined by the RFC. From there, the client will login with a 〈login〉 command, then entertain a series of request and response cycles, and then finally ends the session with a 〈logout〉 command.

All EPP commands will be supported according to the RFC in their standard command and response formats.

As part of the 〈greeting〉, a 〈dcp〉 element is presented indicating Google’s data-collection-policy for the Registry. In general, the 〈dcp〉 element will attempt to mirror (as far as the protocol can mirror) Google’s Privacy Policy as stated in http:⁄⁄www.google.com⁄policies⁄privacy⁄. A copy of our full Privacy Policy as of March 1, 2012, is also included in Question 31 as an attachment.

For all commands, only objects defined by RFCs 5731 (domains), 5732 (hosts), and 5733 (contacts) will be supported. No other extensions will be used.

For the 〈login〉 command, the following policy specifics will be implemented:
- A maximum of three failed login attempts per connection
- On the 12th failed login attempt, the account will be locked out and require support to reactivate.
- Changing the EPP password with the optional 〈newPW〉 element will not be supported. Password changes will instead be handled through the password change interface on the Google SRS Front End. Error code 2501, ʺAuthentication error; server closing connectionʺ will always be returned if this command is used.
- The 〈version〉 element must be set to 1.0.
- The 〈lang〉 element must be set to “en”.

For all other EPP commands there will be no implementation policy specifics.

Standard behavior as defined by the RFC for each command is expected:
- 〈check〉: Determine if an object can be provisioned within the registry
- 〈info〉: Retrieve information associated with a given object
- 〈poll〉: Discover and retrieve service messages by a server for individual clients
- 〈create〉: Create an instance of an object
- 〈delete〉: Remove an instance of an existing object
- 〈renew〉: Extend the validity of an existing object
- 〈transfer〉: Determine real-time status of pending and completed transfer requests
- 〈transfer op=”request”〉: Request that an object be transferred
- 〈transfer op=”approve”〉: Approve a transfer request
- 〈transfer op=”reject”〉: Reject a transfer request
- 〈transfer op=”cancel”〉: Cancel a transfer request
- 〈update〉: Update the information in an existing object

25.1.2. Domain Objects - RFC 5731 (http:⁄⁄tools.ietf.org⁄html⁄rfc5731)

RFC 5731 defines support for domain objects over the EPP protocol.

Since RFC 5732 will be supported as well, domain objects will not be able to specify attributes to describe a name server host machine, but rather must reference the relevant host with 〈domain:hostObj〉 references.

When 〈domain:authInfo〉 is used, a 〈domain:pw〉 must be passed within to denote the password for the domain (or registrant using the “roid” attribute to denote this), or a 〈domain:null〉 to null it out.

For EPP commands dealing with domain object validity, domains will be by default valid indefinitely unless otherwise specified.

A 2305 error response code will be issued if there are dependent children subordinate to the domain, which still exist in the repository if a 〈delete〉 command is issued.

For all domains which require additional vetting of the registrant because of gTLD registration policy reasons, offline review of the domain may occur for transformation EPP commands. Otherwise, no offline review will occur in general.

25.1.3. Host Objects - RFC 5732 (http:⁄⁄tools.ietf.org⁄html⁄rfc5732)

RFC 5732 provides EPP mappings for host objects. This RFC will be supported in its entirety. There are no special considerations needed for the Google Registry.

There will be no offline review before provisioning of any host.

25.1.4. Contact Objects - RFC 5733 (http:⁄⁄tools.ietf.org⁄html⁄rfc5733)

This RFC provides EPP mapping for contact objects. This RFC will be supported in its entirety.

As specified by the RFC, unless prohibited by the server’s stated data collection policy, per-field disclosure policies will be supported via the 〈contact:disclose〉 element when provisioning contacts.

There will be no offline review before provisioning of any contact.

25.1.5. EPP Transport over TCP - RFC 5734 (http:⁄⁄tools.ietf.org⁄html⁄rfc5734)

RFC 5734 defines connection handling procedures regarding the EPP mechanism.

The following policy is adopted from suggestions from this RFC:
-There will be no more than ten concurrent TCP connections from a single source destination IP without first contacting Google to establish an alternate upper limit.
- If a well-formed EPP request is not received at least every 30 seconds, the TCP⁄IP connection may be severed.
- TLS is mandatory to connect to Google EPP.
- A single TLS client certificate will be required for each EPP user and password pair. Multiple user⁄password pairs will not be permitted for a single TLS client certificate.
- A Certificate Name (CN) and subject AltName:dnsName will be set to the hostname of GEPP to be validated against by the client.

25.1.6. DS records - RFC 5910 (http:⁄⁄tools.ietf.org⁄html⁄rfc5910)

RFC 5910 governs the additions to the EPP domain mapping RFC for provisioning DS records for a particular domain. Of the two possible supported mechanisms by the RFC, Google EPP will support the ʺDS Data Interfaceʺ, where the client is responsible for the creation of the DS information and is required to pass DS information when performing adds and removes.

Other particular implementation specifics include:
- The optional 〈secDNS:maxSigLife〉 element will not be initially supported, and a 2102 error code will be returned.
- 〈secDNS:update〉 with an attribute of urgent will not be initially supported, and a 2102 error code will be returned if present.

25.1.7. Grace periods - RFC 3915 (http:⁄⁄tools.ietf.org⁄html⁄rfc3915)

RFC 3915 extends the EPP RFCs to account for grace period functionality. Grace periods allow for actions to be reversed or revoked within a specified period of time. In particular, this RFC governs four grace periods: add grace period, auto renew grace period, renew grace period and transfer grace period. Google will comply with this RFC in its entirety.

25.1.8. IDN RFCs

In addition to RFCs directly related to EPP, RFCs defining internationalized domain names (IDN) (5890, 5891, 5892, and 5893) and how they are specified will be implemented for Google EPP. In particular, IDNs will be specified using punycode and in the subset of unicode character code points dictated by the IDN tables attached to this gTLD application.

25.2. EPP Extensions

Beyond RFC 5910 which extends EPP to support DNSSEC DS records, this gTLD will also include special EPP extensions for account ownership. This extension is described in detail in the attachment “Q25_Account Ownership EPP Extension”.

25.3. Google EPP Testing

Google will develop Google EPP using a software methodology, which ensures correct functionality by concurrently developing unit and large functional tests alongside the production code itself. Standard XML parsing libraries will be used depending on the implementation language. Implementation will also include monitoring rules that test EPP workflows in production on an ongoing basis. Before deploying to production, Google will create staging environments during development for internal manual and automated testing.

25.4. Operational Testing and Evaluation for Registrars

All ICANN-accredited registrars must first complete operational testing and evaluation (OT&E) before submitting EPP commands through the production Google EPP environment. The aim of this testing is to ensure that registrars are functioning properly.

OT&E instructions will be presented to the registrar after it has created a registrar account with the Google Registry. In general, these instructions will include a series of ordered EPP commands the registrar must perform along with test account credentials.

The registrar, once the registrar is ready for certification, it will request a Google Registry Front End evaluation. The test environment will reset to a nominal state, and at this point, the registrar must execute the series of ordered EPP commands within a specified amount of time. If registrar fails OT&E, the registrar will be notified of the failure, and can try again at a later date. If the registrar passes OT&E, the registrar will be notified, and be given production EPP credentials.

25.5. Resourcing Plans

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.

25.5.1. Registry Team

The Registry Team will be responsible for designing and implementing the shared registration system (SRS), EPP, and WHOIS systems, including IDNs. They will also be responsible for creating tests and monitoring for these systems.

During initial implementation, this team will consist of at least four to seven 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 six to nine 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.

25.6. Summary and Key Insights

Google can design, build and run EPP interface that meets the requirements of a gTLD registry because of:
- A thorough understanding of the requirements for the systems.
- A reuse of existing industry, standard EPP XML schemas to de-risk system implementation.
- A proven software development methodology that will verify implementation against requirements.
- Operational procedures that facilitate the ongoing maintenance of the platform and the support of onboarding of new registrars.