Internet-Draft serverValidation July 2026
Gould, et al. Expires 20 January 2027 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-gould-regext-epp-server-validation-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
J.G. Gould
VeriSign, Inc.
S.G. Gould
VeriSign, Inc.
T.S. Sutan-Tanon
VeriSign, Inc.

Server Validation Extension for the Extensible Provisioning Protocol (EPP)

Abstract

This document describes an Extensible Provisioning Protocol (EPP) extension for providing the status of server validations. Server validations can be done for an extensible set of types, with examples including validating the DNS resolution with the type "dns" and validating the DNSSEC with the type "dnssec". The validations can be performed synchronously that will include the extension in the response or asynchronously that will include the validation in a poll message. If validations are performed on a schedule, a change in the status of a typed-validation will be included in a poll message.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 20 January 2027.

1. Introduction

This document describes an extension mapping for version 1.0 of the Extensible Provisioning Protocol (EPP) [RFC5730]. This mapping, an extension to EPP object mappings like the EPP domain name mapping [RFC5731], is used to provide the status of server validations that can be performed synchronously or asynchronously. The result of synchronous validations is included in the EPP response. The result of asynchronous validations is included in a poll message. Scheduled validations that change the status of a typed-validation are included in a poll message. The extension extends the EPP <poll> response in [RFC5730] and does not extend the EPP <poll> command. Please refer to [RFC5730] for information and examples of the EPP <poll> command.

1.1. Conventions Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

XML is case sensitive. Unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented in order to develop a conforming implementation.

In examples, "C:" represents lines sent by a protocol client and "S:" represents lines returned by a protocol server. Indentation and white space in examples are provided only to illustrate element relationships and are not a REQUIRED feature of this protocol.

The XML namespace prefix "serverVal" is used for the namespace "urn:ietf:params:xml:ns:epp:serverValidation-0.1", but implementations MUST NOT depend on it and instead employ a proper namespace-aware XML parser and serializer to interpret and output the XML documents.

2. Object Attributes

This extension adds additional elements to EPP object mappings like the EPP domain name mapping [RFC5731]. Only those new elements are described here.

2.1. <serverVal:validationData> element

The <serverVal:validationData> element is returned in the transform command response for synchronous server validation, in the <info> response, and in the poll message for asynchronous server validation. The <serverVal:validationData> element includes a list of one or more <serverVal:validation> elements with the following child elements:

<serverVal:type>:
Type of server validation that is up to server policy. Example values include "dns" for 2026202 validation of DNS resolution and "dnssec" for validation of DNSSEC.
<serverVal:status>:
Status of the server validation with the values of "success" to reflect that the last validation was successful and "failed" to reflect that the last validation failed.
<serverVal:date>:
OPTIONAL date and time when the server validation was executed.
<serverVal:operation>:
OPTIONAL transform operation executed on the object as defined in Section 2.2 that triggered the validation. This element is not included if the server validation was performed asynchronously without a triggering transform operation.
<serverVal:lastSuccess>:
OPTIONAL date and time when the server validation was last successful. This element should only be returned when the <serverVal:status> element has the value of "failed" and there was a prior successful validation.
<serverVal:firstFailed>:
OPTIONAL date and time when the server validation first failed. This element should only be returned when the <serverVal:status> element has the value of "failed".
<serverVal:lastFailed>:
OPTIONAL date and time when the server validation last failed. This element should only be returned when the <serverVal:status> element has the value of "success" and there was a prior failed validation.
<serverVal:reason>:
OPTIONAL list of server validation failure reasons when the <serverVal:status> element has the value of "failed". If present, this element contains the server-specific text to help explain the reason for the failure. An OPTIONAL "lang" attribute MAY be present to identify the language if the negotiated value is something other than the default value of "en" (English).

Example <serverVal:validationData> element for a successful "dnssec" server validation that was performed asynchronously without a triggering transform command:

...
<serverVal:validationData
  xmlns:serverVal="urn:ietf:params:xml:ns:epp:serverValidation-0.1">
  <serverVal:validation>
    <serverVal:status>success</serverVal:status>
    <serverVal:type>dnssec</serverVal:type>
    <serverVal:date>2026-01-01T12:22:53.0Z</serverVal:date>
  </serverVal:validation>
</serverVal:validationData>
...

Example <serverVal:validationData> element for a failed "dnssec" server validation that was performed asynchronously without a triggering transform command:

...
<serverVal:validationData
  xmlns:serverVal="urn:ietf:params:xml:ns:epp:serverValidation-0.1">
  <serverVal:validation>
    <serverVal:type>dnssec</serverVal:type>
    <serverVal:status>failed</serverVal:status>
    <serverVal:date>2026-01-03T07:21:33Z</serverVal:date>
    <serverVal:firstFailed>2025-12-12T08:19:44Z
    </serverVal:firstFailed>
    <serverVal:reason>Matching DNSKEY not found for DS keyTag 12345
    </serverVal:reason>
  </serverVal:validation>
</serverVal:validationData>
...

Example <serverVal:validationData> element for a successful synchronous "dns" and "dnssec" server validation returned in a create response:

...
<serverVal:validationData
  xmlns:serverVal="urn:ietf:params:xml:ns:epp:serverValidation-0.1">
  <serverVal:validation>
    <serverVal:type>dns</serverVal:type>
    <serverVal:status>success</serverVal:status>
    <serverVal:date>2026-01-01T12:22:45.0Z</serverVal:date>
    <serverVal:operation>create</serverVal:operation>
  </serverVal:validation>
  <serverVal:validation>
    <serverVal:type>dnssec</serverVal:type>
    <serverVal:status>success</serverVal:status>
    <serverVal:date>2026-01-01T12:22:53.0Z</serverVal:date>
    <serverVal:operation>create</serverVal:operation>
  </serverVal:validation>
</serverVal:validationData>
...

2.2. Operation

An operation consists of any transform operation that triggered the server validation. The <serverVal:operation> element defines the operation. The OPTIONAL "op" attribute is an identifier, represented in the 7-bit US-ASCII character set defined in [RFC0020], that is used to define a sub-operation or the name of a "custom" operation. A server validation can only be performed prior to object being purged. The enumerated list of <serverVal:operation> values is:

"create":
Create operation as defined in [RFC5730].
"delete":
Delete operation as defined in [RFC5730] if the delete operation does not result in an immediate purge of the object.
"renew":
Renew operation as defined in [RFC5730].
"transfer":
Transfer operation as defined in [RFC5730] that MUST set the "op" attribute with one of the possible transfer type values that include "request", "approve", "cancel", or "reject".
"update":
Update operation as defined in [RFC5730].
"restore":
Restore operation as defined in [RFC3915] that MUST set the "op" attribute with one of the possible restore type values that include "request" or "report".
"autoRenew":
Auto renew operation executed by the server.
"autoDelete":
Auto delete operation executed by the server if the auto delete operation does not result in an immediate purge of the object.
"custom":
Custom operation that MUST set the "op" attribute with the custom operation name. The custom operations supported is up to server policy.

2.3. Dates and Times

Date and time attribute values MUST be represented in Universal Coordinated Time (UTC) using the Gregorian calendar. The extended date-time form using upper case "T" and "Z" characters defined in http://www.w3.org/TR/2004/REC-xmlschema-2-20041028 MUST be used to represent date-time values, as XML Schema does not support truncated date-time forms or lower case "T" and "Z" characters.

2.4. Server Validation Poll Message

The EPP <poll> command and response are defined in section 2.9.2.3 of [RFC5730]. When a server validation is initially performed asynchronously and when the scheduled server validation status changes, an <info> response with the validation data in Section 2.1 is inserted into the poll queue.

Example <poll> command:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C:  <command>
C:  <poll op="req"/>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

Example <poll> response for a successful "dns" and "dnssec" server validation triggered from a <create> command:

S:<?xml version="1.0" encoding="UTF-8"?>
S:<epp
S:  xmlns="urn:ietf:params:xml:ns:epp-1.0">
S:  <response>
S:    <result code="1301">
S:      <msg lang="en-US">
S:         Command completed successfully; ack to dequeue</msg>
S:    </result>
S:    <msgQ id="200" count="1">
S:      <qDate>2026-01-01T12:22:45Z</qDate>
S:      <msg>domain.example successful create validations</msg>
S:    </msgQ>
S:    <resData>
S:      <domain:infData
S:        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S:        <domain:name>domain.example</domain:name>
S:        <domain:roid>EXAMPLE1-REP</domain:roid>
S:        <domain:clID>ClientX</domain:clID>
S:        <domain:crDate>2015-10-15T09:19:55.0Z</domain:crDate>
S:        <domain:upID>ClientY</domain:upID>
S:        <domain:upDate>2026-01-01T14:25:57.0Z</domain:upDate>
S:      </domain:infData>
S:    </resData>
S:    <extension>
S:      <serverVal:validationData
S:        xmlns:serverVal=
S:        "urn:ietf:params:xml:ns:epp:serverValidation-0.1">
S:        <serverVal:validation>
S:          <serverVal:type>dns</serverVal:type>
S:          <serverVal:status>success</serverVal:status>
S:          <serverVal:date>2026-01-01T12:22:45.0Z</serverVal:date>
S:          <serverVal:operation>create</serverVal:operation>
S:        </serverVal:validation>
S:       <serverVal:validation>
S:          <serverVal:type>dnssec</serverVal:type>
S:          <serverVal:status>success</serverVal:status>
S:          <serverVal:date>2026-01-01T12:22:53.0Z</serverVal:date>
S:          <serverVal:operation>create</serverVal:operation>
S:        </serverVal:validation>
S:      </serverVal:validationData>
S:    </extension>
S:    <trID>
S:      <clTRID>ABC-12345</clTRID>
S:      <svTRID>54321-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>

Example <poll> response for mixed scheduled server validations, with a "dns" success and a "dnssec" failed validation:

S:<?xml version="1.0" encoding="UTF-8"?>
S:<epp
S:  xmlns="urn:ietf:params:xml:ns:epp-1.0">
S:  <response>
S:    <result code="1301">
S:      <msg lang="en-US">
S:         Command completed successfully; ack to dequeue</msg>
S:    </result>
S:    <msgQ id="200" count="1">
S:      <qDate>2026-01-01T12:22:45Z</qDate>
S:      <msg>domain.example mixed server validations</msg>
S:    </msgQ>
S:    <resData>
S:      <domain:infData
S:        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S:        <domain:name>domain.example</domain:name>
S:        <domain:roid>EXAMPLE1-REP</domain:roid>
S:        <domain:clID>ClientX</domain:clID>
S:        <domain:crDate>2015-10-15T09:19:55.0Z</domain:crDate>
S:        <domain:upID>ClientY</domain:upID>
S:        <domain:upDate>2026-01-01T14:25:57.0Z</domain:upDate>
S:      </domain:infData>
S:    </resData>
S:    <extension>
S:      <serverVal:validationData
S:        xmlns:serverVal=
S:        "urn:ietf:params:xml:ns:epp:serverValidation-0.1">
S:        <serverVal:validation>
S:          <serverVal:type>dns</serverVal:type>
S:          <serverVal:status>success</serverVal:status>
S:          <serverVal:date>2026-01-01T12:22:45Z</serverVal:date>
S:          <serverVal:lastFailed>2025-12-30T11:11:34Z
S:          </serverVal:lastFailed>
S:        </serverVal:validation>
S:        <serverVal:validation>
S:          <serverVal:type>dnssec</serverVal:type>
S:          <serverVal:status>failed</serverVal:status>
S:          <serverVal:date>2026-01-01T12:22:53Z</serverVal:date>
S:          <serverVal:reason lang="en">
S:            Matching DNSKEY not found for DS keyTag 12345
S:          </serverVal:reason>
S:          <serverVal:reason lang="en">
S:            Insecure DNSKEY algorithm for DS keyTag 54321
S:          </serverVal:reason>
S:        </serverVal:validation>
S:      </serverVal:validationData>
S:    </extension>
S:    <trID>
S:      <clTRID>ABC-12345</clTRID>
S:      <svTRID>54321-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>

3. EPP Command Mapping

A detailed description of the EPP syntax and semantics can be found in the EPP core protocol specification [RFC5730].

3.1. EPP Query Commands

EPP provides three commands to retrieve object information: <check> to determine if an object is known to the server, <info> to retrieve detailed information associated with an object, and <transfer> to retrieve object transfer status information.

3.1.1. EPP <check> Command

This extension does not add any elements to the EPP <check> command or <check> response described in the [RFC5730].

3.1.2. EPP <info> Command

This extension defines additional elements to extend the EPP <info> command and response to be used in conjunction with [RFC5730].

The EPP <info> command is extended with an empty <serverVal:validationInfo> element to indicate the desire for the server validation information to be included in the extension to the <info> response.

Example <info> domain command with the <serverVal:validationInfo> extension to retrieve the server validation information.:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C:  <command>
C:    <info>
C:      <domain:info
C:        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>domain.example</domain:name>
C:      </domain:info>
C:    </info>
C:    <extension>
C:        <serverVal:validationInfo
C:        xmlns:serverVal=
C:        "urn:ietf:params:xml:ns:epp:serverValidation-0.1"/>
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

If the query was successful, the server replies with the <serverVal:validationData> element, defined in Section 2.1, along with the regular EPP <resData>.

Example <info> domain response using the <serverVal:validationInfo> extension with a successful "dnssec" server validation:

S:<?xml version="1.0" encoding="UTF-8"?>
S:<epp
S:  xmlns="urn:ietf:params:xml:ns:epp-1.0">
S:  <response>
S:    <result code="1000">
S:      <msg>Command completed successfully</msg>
S:    </result>
S:    <resData>
S:      <domain:infData
S:        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S:        <domain:name>domain.example</domain:name>
S:        <domain:roid>EXAMPLE1-REP</domain:roid>
S:        <domain:clID>ClientX</domain:clID>
S:        <domain:crDate>2015-10-15T09:19:55.0Z</domain:crDate>
S:        <domain:upID>ClientY</domain:upID>
S:        <domain:upDate>2026-01-01T14:25:57.0Z</domain:upDate>
S:      </domain:infData>
S:    </resData>
S:    <extension>
S:      <serverVal:validationData
S:        xmlns:serverVal=
S:        "urn:ietf:params:xml:ns:epp:serverValidation-0.1">
S:        <serverVal:validation>
S:          <serverVal:type>dnssec</serverVal:type>
S:          <serverVal:status>success</serverVal:status>
S:          <serverVal:date>2026-01-01T12:22:53.0Z</serverVal:date>
S:        </serverVal:validation>
S:      </serverVal:validationData>
S:    </extension>
S:   <trID>
S:      <clTRID>ABC-12345</clTRID>
S:      <svTRID>54321-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>

Example <info> domain response using the <serverVal:validationInfo> extension with a failed "dnssec" server validation:

S:<?xml version="1.0" encoding="UTF-8"?>
S:<epp
S:  xmlns="urn:ietf:params:xml:ns:epp-1.0">
S:  <response>
S:    <result code="1000">
S:      <msg>Command completed successfully</msg>
S:    </result>
S:    <resData>
S:      <domain:infData
S:        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S:        <domain:name>domain.example</domain:name>
S:        <domain:roid>EXAMPLE1-REP</domain:roid>
S:        <domain:clID>ClientX</domain:clID>
S:        <domain:crDate>2015-10-15T09:19:55Z</domain:crDate>
S:        <domain:upID>ClientY</domain:upID>
S:        <domain:upDate>2026-01-01T14:25:57Z</domain:upDate>
S:      </domain:infData>
S:    </resData>
S:    <extension>
S:      <serverVal:validationData
S:        xmlns:serverVal=
S:        "urn:ietf:params:xml:ns:epp:serverValidation-0.1">
S:        <serverVal:validation>
S:          <serverVal:type>dnssec</serverVal:type>
S:          <serverVal:status>failed</serverVal:status>
S:          <serverVal:date>2026-01-03T07:21:33Z</serverVal:date>
S:          <serverVal:lastSuccess>2025-12-11T07:20:00Z
S:          </serverVal:lastSuccess>
S:          <serverVal:firstFailed>2025-12-12T08:19:44Z
S:          </serverVal:firstFailed>
S:          <serverVal:reason>
S:            Matching DNSKEY not found for DS keyTag 12345
S:          </serverVal:reason>
S:        </serverVal:validation>
S:      </serverVal:validationData>
S:    </extension>
S:    <trID>
S:      <clTRID>ABC-12345</clTRID>
S:      <svTRID>54321-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>

3.1.3. EPP <transfer> Command

This extension does not add any elements to the EPP <transfer> query command or <transfer> response described in the [RFC5730].

3.2. EPP Transform Commands

EPP provides five commands to transform objects: <create> to create an instance of an object, <delete> to delete an instance of an object, <renew> to extend the validity period of an object, <transfer> to manage object sponsorship changes, and <update> to change information associated with an object.

3.2.1. EPP <create> Command

This extension does not add any elements to the EPP <create> command.

This extension does define additional elements to the EPP <create> response with the <serverVal:validationData> element (Section 2.1) when the server validation is executed synchronously in the EPP <create> command.

3.2.2. EPP <delete> Command

This extension does not add any elements to the EPP <delete> command.

This extension does define additional elements to the EPP <delete> response with the <serverVal:validationData> element (Section 2.1) when the server validation is executed synchronously in the EPP <delete> command.

3.2.3. EPP <renew> Command

This extension does not add any elements to the EPP <renew> command.

This extension does define additional elements to the EPP <renew> response with the <serverVal:validationData> element (Section 2.1) when the server validation is executed synchronously in the EPP <renew> command.

3.2.4. EPP <transfer> Command

This extension does not add any elements to the EPP <transfer> command.

This extension does define additional elements to the EPP <transfer> response with the <serverVal:validationData> element (Section 2.1) when the server validation is executed synchronously in the EPP <transfer> command.

3.2.5. EPP <update> Command

This extension does not add any elements to the EPP <update> command.

This extension does define additional elements to the EPP <update> response with the <serverVal:validationData> element (Section 2.1) when the server validation is executed synchronously in the EPP <update> command.

4. Formal Syntax

One schema is presented here that is the EPP Server Validation Extension schema.

The formal syntax presented here is a complete schema representation of the object mapping suitable for automated validation of EPP XML instances. The BEGIN and END tags are not part of the schema; they are used to note the beginning and ending of the schema for URI registration purposes.

4.1. Server Validation Extension Schema 

BEGIN
<?xml version="1.0" encoding="UTF-8"?>
 <schema targetNamespace=
            "urn:ietf:params:xml:ns:epp:serverValidation-0.1"
         xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
         xmlns:epp="urn:ietf:params:xml:ns:epp-1.0"
         xmlns:serverValidation=
            "urn:ietf:params:xml:ns:epp:serverValidation-0.1"
         xmlns="http://www.w3.org/2001/XMLSchema"
         elementFormDefault="qualified">

  <!--
  Import common element types.
  -->
  <import namespace="urn:ietf:params:xml:ns:eppcom-1.0"/>
  <import namespace="urn:ietf:params:xml:ns:epp-1.0"/>


   <annotation>
     <documentation>
       Extensible Provisioning Protocol v1.0
       Server Validation Mapping Schema.
     </documentation>
   </annotation>

   <!--
    validationInfo element as a marker for
    returning the validation information.
   -->
   <element name="validationInfo"/>

   <!--
    validationData element containing list of validation elements
   -->
   <element name="validationData"
      type="serverValidation:validationDataType"/>

  <!--
    Attributes associated with the validationDataType.
   -->
   <complexType name="validationDataType">
      <sequence>
         <element name="validation"
            type="serverValidation:validationType"
            maxOccurs="unbounded"/>
      </sequence>
   </complexType>

   <!--
    Attributes associated with the validation status
    by validation type
   -->
   <complexType name="validationType">
     <sequence>
       <!-- Validation type -->
       <element name="type" type="token"/>
       <!-- Status of the validation? -->
       <element name="status"
          type="serverValidation:statusEnum"/>
       <!-- Date and time of last validation -->
       <element name="date" type="dateTime"
          minOccurs="0"/>
       <!-- Operation of last validation -->
       <element name="operation"
          type="serverValidation:operationType"
          minOccurs="0"/>
       <!-- Date and time of the last successful validation -->
       <element name="lastSuccess" type="dateTime"
          minOccurs="0"/>
       <!-- Date and time of the first failed validation -->
       <element name="firstFailed" type="dateTime"
          minOccurs="0"/>
       <!-- Date and time of last failed validation -->
       <element name="lastFailed" type="dateTime"
          minOccurs="0"/>
        <!-- Optional list of failure reasons -->
      <element name="reason"
         type="serverValidation:reasonType"
         minOccurs="0" maxOccurs="unbounded"/>
     </sequence>
   </complexType>

   <!--
    Enumerated list of operations, with extensibility via "custom".
   -->
   <simpleType name="operationEnum">
     <restriction base="token">
       <enumeration value="create"/>
       <enumeration value="delete"/>
       <enumeration value="renew"/>
       <enumeration value="transfer"/>
       <enumeration value="update"/>
       <enumeration value="restore"/>
       <enumeration value="autoRenew"/>
       <enumeration value="autoDelete"/>
       <enumeration value="autoPurge"/>
       <enumeration value="custom"/>
     </restriction>
   </simpleType>

   <!--
    Transform operation type
   -->
  <complexType name="operationType">
    <simpleContent>
      <extension base="serverValidation:operationEnum">
        <attribute name="op" type="token"/>
      </extension>
    </simpleContent>
  </complexType>

  <!--
    Enumerated list of statuses
   -->
   <simpleType name="statusEnum">
     <restriction base="token">
       <enumeration value="success"/>
       <enumeration value="failed"/>
      </restriction>
   </simpleType>

  <!--
    reason element with support for "lang" attribute
   -->
  <complexType name="reasonType">
    <simpleContent>
      <extension base="token">
        <attribute name="lang" type="language"/>
      </extension>
    </simpleContent>
  </complexType>

 <!--
 End of schema.
 -->
 </schema>
END

5. IANA Considerations

5.1. XML Namespace

This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688]. The following URI assignment is requested of IANA:

Registration request for the serverValidation namespace:

  • URI: urn:ietf:params:xml:ns:epp:serverValidation-0.1

  • Registrant Contact: IESG

  • XML: None. Namespace URIs do not represent an XML specification.

Registration request for the serverValidation XML schema:

  • URI: urn:ietf:params:xml:schema:epp:serverValidation-0.1

  • Registrant Contact: IESG

  • XML: See the "Formal Syntax" section of this document.

5.2. EPP Extension Registry

The EPP extension described in this document should be registered by the IANA in the EPP Extension Registry described in [RFC7451]. The details of the registration are as follows:

Name of Extension: "Server Validation Extension for the Extensible Provisioning Protocol (EPP)"

Document status: Standards Track

Reference: (insert reference to RFC version of this document)

Registrant Name and Email Address: IESG, <iesg@ietf.org>

TLDs: Any

IPR Disclosure: None

Status: Active

Notes: None

6. Security Considerations

The mapping extensions described in this document do not provide any security services beyond those described by EPP [RFC5730] and protocol layers used by EPP. This document provides validation information that may be related to security, such as validating DNSSEC with the DNSSEC chain, algorithms, and signatures. What validation information to provide to the sponsoring and non-sponsoring client is a consideration that is up to server policy, where a server may only provide the validation failure reasons to the sponsoring client.

7. References

7.1. Normative References

[RFC0020]
Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC20, , <https://www.rfc-editor.org/info/rfc20>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC3688]
Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, , <https://www.rfc-editor.org/info/rfc3688>.
[RFC3915]
Hollenbeck, S., "Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)", RFC 3915, DOI 10.17487/RFC3915, , <https://www.rfc-editor.org/info/rfc3915>.
[RFC5730]
Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, , <https://www.rfc-editor.org/info/rfc5730>.
[RFC5731]
Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", STD 69, RFC 5731, DOI 10.17487/RFC5731, , <https://www.rfc-editor.org/info/rfc5731>.

7.2. Informative References

[RFC7451]
Hollenbeck, S., "Extension Registry for the Extensible Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, , <https://www.rfc-editor.org/info/rfc7451>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.

Authors' Addresses

James Gould
VeriSign, Inc.
12061 Bluemont Way
Reston, VA 20190
United States of America
URI: http://www.verisign.com
Sandra Gould
VeriSign, Inc.
12061 Bluemont Way
Reston, VA 20190
United States of America
URI: http://www.verisign.com
Tanya Sutan-Tanon
VeriSign, Inc.
12061 Bluemont Way
Reston, VA 20190
United States of America
URI: http://www.verisign.com