REGEXT Working Group                                            G. Brown
Internet-Draft                                                     ICANN
Intended status: Standards Track                             3 July 2026
Expires: 4 January 2027


 Delegation Maintenance Automation Status Extension for the Extensible
                      Provisioning Protocol (EPP)
           draft-brown-epp-delegation-automation-extension-00

Abstract

   This document specifies an extension to the Domain Mapping for the
   Extensible Provisioning Protocol (EPP) which allows EPP clients to
   enable and disable automatic delegation maintenance carried out by
   the server.  It also describes how the maintenance automation state
   of a domain can be included in RDAP responses.

   The source for this draft, and an issue tracker, may can be found at
   https://github.com/gbxyz/epp-ds-automation-extension.

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 4 January 2027.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components



Brown                    Expires 4 January 2027                 [Page 1]

Internet-Draft  EPP Delegation Maintenance Automation Ex       July 2026


   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Conventions Used in This Document . . . . . . . . . . . .   3
   2.  EPP Extension Elements  . . . . . . . . . . . . . . . . . . .   4
   3.  EPP Command Mapping . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  EPP Query Commands  . . . . . . . . . . . . . . . . . . .   5
       3.1.1.  EPP <info> Command  . . . . . . . . . . . . . . . . .   5
     3.2.  EPP Transform Commands  . . . . . . . . . . . . . . . . .   6
       3.2.1.  EPP <create> Command  . . . . . . . . . . . . . . . .   6
       3.2.2.  EPP <update> Command  . . . . . . . . . . . . . . . .   8
   4.  RDAP Status Mapping . . . . . . . . . . . . . . . . . . . . .   9
   5.  Formal Syntax (XML) . . . . . . . . . . . . . . . . . . . . .   9
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     6.1.  XML Namespace . . . . . . . . . . . . . . . . . . . . . .  11
     6.2.  EPP Extension Registry  . . . . . . . . . . . . . . . . .  11
     6.3.  RDAP JSON Values  . . . . . . . . . . . . . . . . . . . .  12
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   8.  Operational Considerations  . . . . . . . . . . . . . . . . .  13
   9.  Change Log  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     9.1.  v01 . . . . . . . . . . . . . . . . . . . . . . . . . . .  14
     9.2.  v00 . . . . . . . . . . . . . . . . . . . . . . . . . . .  14
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  14
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  14
     11.2.  Informative References . . . . . . . . . . . . . . . . .  16
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   [RFC7477] automates the maintenance of delegation information
   records, typically NS records and any associated glue records (see
   Section 7 of [RFC9499]) through the publication of CSYNC records in
   the child zone which indicate the delegation's desired delegation
   information ("NS automation").

   Similarly, [RFC7344], [RFC8078], and [RFC9615] automate DNSSEC
   ([RFC9364]) trust maintenance by having the child publish Child DS
   (CDS) and/or Child DNSKEY (CDNSKEY) records which indicate the
   delegation's desired DNSSEC parameters ("DS automation").
   [I-D.ietf-dnsop-ds-automation] provides operational recommendations
   for parent operators wishing to deploy DS automation.





Brown                    Expires 4 January 2027                 [Page 2]

Internet-Draft  EPP Delegation Maintenance Automation Ex       July 2026


   Section 6.1 of [I-D.ietf-dnsop-ds-automation] states that parent zone
   operators running under the registrant-registrar-registry (RRR) model
   and using the Extensible Provisioning Protocol (EPP, [STD69]) *MUST
   NOT* suspend DS automation solely on the basis of the presence of the
   serverUpdateProhibited status code (defined in Section 2.3 of
   RFC5731).  This status code causes any request to modify the domain
   name (including DNSSEC information as per [RFC5910]) to be rejected
   by the EPP server.

   The most common use of the serverUpdateProhibited status is as part
   of a "registry lock" (see [CENTR-REGISTRY-LOCK]), a security measure
   designed to mitigate the risk of (a) a compromised customer account
   at the sponsoring registrar (see Section 9 of [RFC9499]), or (b) a
   compromised or malicious registrar.

   For domains which have a registry lock, it is not always the case
   that the registrant of the domain will want either DS automation or
   NS automation to take place.

   This document specifies an extension to the Domain Mapping for EPP
   RFC5731 which allows the sponsoring client of a domain object to
   specify whether or not DS automation and/or NS automation
   ("delegation automation") should be carried out by the server.

   It also describes how the delegation automation state of domain
   objects should be represented in Registration Data Access Protocol
   (RDAP, [STD95]) responses.

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
   [BCP14] RFC2119 RFC8174 when, and only when, they appear in all
   capitals, as shown here.

   The term "delegation automation" refers to either or both of "DS
   automation" and "NS automation", as described above.  An EPP server
   may choose to implement either or both of these protocols, in
   accordance with its own policy.

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





Brown                    Expires 4 January 2027                 [Page 3]

Internet-Draft  EPP Delegation Maintenance Automation Ex       July 2026


   A protocol client that is authorized to manage an existing object is
   described as a "sponsoring" client throughout this document.

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

   EPP uses XML namespaces to provide an extensible object management
   framework and to identify schemas required for XML instance parsing
   and validation.  These namespaces and schema definitions are used to
   identify both the base protocol schema and the schemas for managed
   objects.

   The XML namespace prefixes used in these examples (such as the string
   automation in automation:ds-automation) are solely for illustrative
   purposes.  A conforming implementation *MUST NOT* require the use of
   these or any other specific namespace prefixes.

   In accordance with Section 3.2.2.1 of XML Schema Part 2: Datatypes
   [XSD-DATATYPES], the allowable lexical representations for the
   xs:boolean datatype are the strings "0" and "false" for the concept
   'false' and the strings "1" and "true" for the concept 'true'.
   Implementations *MUST* support both styles of lexical representation.

2.  EPP Extension Elements

   This specification adds two new elements, <automation:nsAutomation>
   and <automation:dsAutomation>, to the domain name mapping (RFC5731).
   These elements both have a single boolean "enabled" attribute.

   1.  If the value of the "enabled" attribute of the
       <automation:dsAutomation> element is "true" or "1", then the
       server *MAY* perform DS automation for the domain.

   2.  If the value of the "enabled" attribute of the
       <automation:dsAutomation> element is "false" or "0", then the
       server *MUST NOT* perform DS automation for the domain.

   Similarly:

   1.  If the value of the "enabled" attribute of the <automation:ns-
       automation> element is "true" or "1", then the server *MAY*
       perform NS automation for the domain.

   2.  If the value of the "enabled" attribute of the <automation:ns-
       automation> element is "false" or "0", then the server *MUST NOT*
       perform NS automation for the domain.



Brown                    Expires 4 January 2027                 [Page 4]

Internet-Draft  EPP Delegation Maintenance Automation Ex       July 2026


   The <automation:nsAutomation> is only used when the EPP server
   supports NS automation, and the <automation:dsAutomation> element iso
   nly used when the EPP server supports NS automation.

3.  EPP Command Mapping

3.1.  EPP Query Commands

3.1.1.  EPP <info> Command

   This extension does not add any elements to the EPP <info> command
   described in the EPP domain mapping (RFC5731).  However, additional
   elements are defined for the <info> response.

   When an <info> command has been processed successfully, the EPP
   <resData> element *MUST* contain child elements as described in the
   EPP domain mapping (RFC5731).  In addition, the EPP <extension>
   element *MUST* contain a child <automation:infData> element that
   identifies the extension namespace.

   The <automation:infData> element *MUST* contain at least one of the
   following child elements:

   1.  a <automation:nsAutomation> element, if the server supports NS
       automation.

   2.  a <automation:dsAutomation> element, if the server supports DS
       automation.

   Example domain <info> response:





















Brown                    Expires 4 January 2027                 [Page 5]

Internet-Draft  EPP Delegation Maintenance Automation Ex       July 2026


S: <?xml version="1.0"?>
S: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S:   <response>
S:     <result code="1000">
S:       <msg>OK</msg>
S:     </result>
S:     <resData>
S:       <domain:infData
S:         xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S:         <domain:name>example.com</domain:name>
S:         <domain:roid>EXAMPLE1-REP</domain:roid>
S:         <domain:status s="ok"/>
S:         <domain:ns>
S:           <domain:hostObj>ns1.example.net</domain:hostObj>
S:           <domain:hostObj>ns2.example.org</domain:hostObj>
S:         </domain:ns>
S:         <domain:clID>ClientX</domain:clID>
S:       </domain:infData>
S:     </resData>
S:     <extension>
S:       <automation:create
S:         xmlns:automation="urn:ietf:params:xml:ns:epp:delegation-maintenance-automation-1.0">
S:         <automation:nsAutomation enabled="false"/>
S:         <automation:dsAutomation enabled="true"/>
S:       </automation:create>
S:     </extension>
S:     <trID>
S:       <svTRID>54322-XYZ</svTRID>
S:     </trID>
S:   </response>
S: </epp>

3.2.  EPP Transform Commands

3.2.1.  EPP <create> Command

   This extension defines additional elements for the EPP <create>
   command described in the EPP domain mapping RFC5731.  No additional
   elements are defined for the EPP <create> response.

   The EPP <create> command provides a transform operation that allows a
   client to create a domain object.  In addition to the EPP command
   elements described in the EPP domain mapping (RFC5731), the command
   *MUST* contain an <extension> element, and the <extension> element
   *MUST* contain a child <automation:create> element that identifies
   the extension namespace if the client wants to associate data defined
   in this extension to the domain object.




Brown                    Expires 4 January 2027                 [Page 6]

Internet-Draft  EPP Delegation Maintenance Automation Ex       July 2026


   The <automation:create> element *MUST* contain at least one of the
   following child elements:

   1.  a <automation:nsAutomation> element, if the server supports NS
       automation.  If the server does not support NS automation, then a
       <create> command containing this element *MUST* be rejected with
       a 2102 ("Unimplemented option") response.  If omitted, the
       default NS automation policy (if applicable) *MUST* be configured
       for the domain.

   2.  a <automation:dsAutomation> element, if the server supports DS
       automation.  If the server does not support DS automation, then a
       <create> command containing this element *MUST* be rejected with
       a 2102 ("Unimplemented option") response.  If omitted, the
       default DS automation policy (if applicable) *MUST* be configured
       for the domain.

   Example domain <create> 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:     <create>
C:       <domain:create
C:         xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:         <domain:name>example.com</domain:name>
C:         <domain:period unit="y">1</domain:period>
C:         <domain:ns>
C:           <domain:hostObj>ns1.example.net</domain:hostObj>
C:           <domain:hostObj>ns2.example.org</domain:hostObj>
C:         </domain:ns>
C:         <domain:authInfo>
C:           <domain:pw/>
C:         </domain:authInfo>
C:       </domain:create>
C:     </create>
C:     <extension>
C:       <automation:create
C:         xmlns:automation="urn:ietf:params:xml:ns:epp:delegation-maintenance-automation-1.0">
C:         <automation:nsAutomation enabled="false"/>
C:         <automation:dsAutomation enabled="true"/>
C:       </automation:create>
C:     </extension>
C:   </command>
C: </epp>






Brown                    Expires 4 January 2027                 [Page 7]

Internet-Draft  EPP Delegation Maintenance Automation Ex       July 2026


3.2.2.  EPP <update> Command

   This extension defines additional elements for the EPP <update>
   command described in the EPP domain mapping RFC5731.  No additional
   elements are defined for the EPP <update> response.

   The EPP <update> command provides a transform operation that allows a
   client to modify the attributes of a domain object.  In addition to
   the EPP command elements described in the EPP domain mapping, the
   command *MUST* contain an <extension> element, and the <extension>
   element *MUST* contain a child <automation:update> element that
   identifies the extension namespace if the client wants to update the
   domain object with data defined in this extension.

   The <automation:update> element *MUST* contain at least one of the
   following child elements:

   1.  a <automation:nsAutomation> element, if the server supports NS
       automation.  If the server does not support NS automation, then
       an <update> command containing this element *MUST* be rejected
       with a 2102 ("Unimplemented option") response.

   2.  a <automation:dsAutomation> element, if the server supports DS
       automation.  If the server does not support DS automation, then
       an <update> command containing this element *MUST* be rejected
       with a 2102 ("Unimplemented option") response.

   Example domain <update> 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:     <update>
C:       <domain:update
C:         xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:         <domain:name>example.com</domain:name>
C:       </domain:update>
C:     </update>
C:     <extension>
C:       <automation:create
C:         xmlns:automation="urn:ietf:params:xml:ns:epp:delegation-maintenance-automation-1.0">
C:         <automation:nsAutomation enabled="true"/>
C:         <automation:dsAutomation enabled="false"/>
C:       </automation:create>
C:     </extension>
C:   </command>
C: </epp>




Brown                    Expires 4 January 2027                 [Page 8]

Internet-Draft  EPP Delegation Maintenance Automation Ex       July 2026


4.  RDAP Status Mapping

   Operators of EPP servers who also operate an RDAP server can include
   an entry in the "status" member of domain responses to allow
   interested parties to determine whether delegation automation is
   enabled or disabled for a given domain name.

   1.  A domain for which NS automation is enabled *MUST* have the "NS
       automation enabled" value in its "status" member.

   2.  A domain for which NS automation is disabled *MUST* have the "NS
       automation disabled" value in its "status" member.

   3.  A domain for which DS automation is enabled *MUST* have the "DS
       automation enabled" value in its "status" member.

   4.  A domain for which DS automation is disabled *MUST* have the "DS
       automation disabled" value in its "status" member.

   These two status values will be registered in [RDAP-JSON-VALUES] (see
   Section 6.3).

   The DS automation enabled and DS automation disabled values *MUST
   NOT* both be present at the same time.  Similarly, NS automation
   enabled and NS automation disabled *MUST NOT* both be present at the
   same time.

5.  Formal Syntax (XML)

   An EPP object mapping is specified in XML Schema notation.  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.

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

  <annotation>
    <documentation>
     DS Automation Status Extension for the
     Extensible Provisioning Protocol (EPP)



Brown                    Expires 4 January 2027                 [Page 9]

Internet-Draft  EPP Delegation Maintenance Automation Ex       July 2026


   </documentation>
  </annotation>

  <!--
  Child elements found in EPP commands.
  -->
  <element name="infData" type="automation:infDataType"/>
  <element name="create" type="automation:createType"/>
  <element name="update" type="automation:updateType"/>

  <complexType name="automationType">
    <attribute name="enabled"
      type="boolean"
      use="required"/>
  </complexType>

  <complexType name="infDataType">
    <sequence>
      <element name="nsAutomation"
        type="automation:automationType"
        minOccurs="0"/>
      <element name="dsAutomation"
        type="automation:automationType"
        minOccurs="0"/>
    </sequence>
  </complexType>

  <complexType name="createType">
    <sequence>
      <element name="nsAutomation"
        type="automation:automationType"
        minOccurs="0"/>
      <element name="dsAutomation"
        type="automation:automationType"
        minOccurs="0"/>
    </sequence>
  </complexType>

  <complexType name="updateType">
    <sequence>
      <element name="nsAutomation"
        type="automation:automationType"
        minOccurs="0"/>
      <element name="dsAutomation"
        type="automation:automationType"
        minOccurs="0"/>
    </sequence>
  </complexType>



Brown                    Expires 4 January 2027                [Page 10]

Internet-Draft  EPP Delegation Maintenance Automation Ex       July 2026


</schema>
END

6.  IANA Considerations

6.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 assignments are requested of IANA:

   Registration for the TTL namespace:

   URI: urn:ietf:params:xml:ns:epp:delegation-maintenance-automation-1.0

   Registrant Contact: IESG

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

   Registration for the TTL XML schema:

   URI: urn:ietf:params:xml:schema:epp:delegation-maintenance-
   automation-1.0

   Registrant Contact: IESG

   XML: See Section 5 of this document.

6.2.  EPP Extension Registry

   IANA is requested to register the EPP extension described in this
   document in [EPP-EXTENSIONS], described in [RFC7451].  The details of
   the registration are as follows:

   Name of Extension: DS Automation Status Extension for the Extensible
   Provisioning Protocol (EPP)

   Document Status: Standards Track

   Reference: this document

   Registrant: IESG

   TLDs: Any

   IPR Disclosure: None

   Status: Active



Brown                    Expires 4 January 2027                [Page 11]

Internet-Draft  EPP Delegation Maintenance Automation Ex       July 2026


   Notes: None

6.3.  RDAP JSON Values

   IANA is requested to list this document as a reference for
   [RDAP-JSON-VALUES] and register the following values:

   Value: NS automation enabled

   Type: status

   Description: The server MAY perform NS automation for this domain.

   Registrant: IETF

   Contact Information: iesg@ietf.org

   Value: NS automation disabled

   Type: status

   Description: The server MUST NOT perform NS automation for this
   domain.

   Registrant: IETF

   Contact Information: iesg@ietf.org

   Reference: this document

   Value: DS automation enabled

   Type: status

   Description: The server MAY perform DS automation for this domain.

   Registrant: IETF

   Contact Information: iesg@ietf.org

   Value: DS automation disabled

   Type: status

   Description: The server MUST NOT perform DS automation for this
   domain.

   Registrant: IETF



Brown                    Expires 4 January 2027                [Page 12]

Internet-Draft  EPP Delegation Maintenance Automation Ex       July 2026


   Contact Information: iesg@ietf.org

   Reference: this document

7.  Security Considerations

   The mapping extensions described in this document do not provide any
   security services beyond those described by EPP (RFC5730), the EPP
   domain name mapping (RFC5731), and protocol layers used by EPP.  The
   security considerations described in these other specifications apply
   to this specification as well.

   As with other domain object transforms, the EPP transform operations
   described in this document *MUST* be restricted to the sponsoring
   client as authenticated using the mechanisms described in Sections
   2.9.1.1 and 7 of RFC5730.  Any attempt to perform a transform
   operation on a domain object by any client other than the sponsoring
   client *MUST* be rejected with an appropriate EPP authorization
   error.

   The provisioning service described in this document involves the
   exchange of information that can have an operational impact on the
   DNS.  A trust relationship *MUST* exist between the EPP client and
   server using a strong authentication mechanism.

8.  Operational Considerations

   Server operators *MUST* obey the value for the "enabled" attribute of
   <automation:nsAutomation> and <automation:dsAutomation> elements,
   irrespective of the presence (or absence) of EPP status codes such as
   serverUpdateProhibited.

   When the "enabled" attribute is "false" or "0", the sponsoring client
   *MAY* perform NS/DS automation itself, and submit any necessary
   changes to the DNSSEC configuration of the domain using an <update>
   command (extended by [RFC5910] as needed).

   When the "enabled" attribute is "true" or "1", the sponsoring client
   *SHOULD NOT* perform NS.DS automation, for the reasons outlined in
   Section 7.2.3 of [I-D.ietf-dnsop-ds-automation].

   EPP clients may use the presence or absence of these elements in
   <info> responses to determine whether NS/DS automation are supported
   by the server, but server operators *SHOULD* document their
   operational policy and provide this to client operators during
   onboarding.





Brown                    Expires 4 January 2027                [Page 13]

Internet-Draft  EPP Delegation Maintenance Automation Ex       July 2026


   It is impractical for EPP clients with large portfolios of domain
   names that wish to deploy (or decommission) delegation automation
   themselves to submit <update> commands to enable or disable
   delegation automation for all domains under their sponsorship.  It is
   *RECOMMENDED* that server operators provide an out-of-band method for
   clients to enable or disable delegation automation for all domains
   under their sponsorship in a single operation.

9.  Change Log

   This section is to be removed before publishing as an RFC.

9.1.  v01

   *  Made the extension elements optional according to server policy.

   *  Removed the default attribute value is it may be misleading
      (implying an expected default policy).

   *  Updated to cover NS automation as well as DS automation (thanks
      Peter Thomassen).  This includes a namespace URI update.

9.2.  v00

   *  Initial version based on conversations within ICANN GDS Technical
      Services, and Peter Thomassen.

10.  Acknowledgements

   The author wishes to thank the following for their constructive
   feedback and advice during the development of this document:

   Andy Newton, Gustavo Lozano, Francisco Arias, Peter Thomassen.

11.  References

11.1.  Normative References

   [BCP14]    Best Current Practice 14,
              <https://www.rfc-editor.org/info/bcp14>.
              At the time of writing, this BCP comprises the following:

              Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.





Brown                    Expires 4 January 2027                [Page 14]

Internet-Draft  EPP Delegation Maintenance Automation Ex       July 2026


              Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [EPP-EXTENSIONS]
              "Extensions for the Extensible Provisioning Protocol
              (EPP)", n.d., <https://www.iana.org/assignments/epp-
              extensions/epp-extensions.xhtml>.

   [I-D.ietf-dnsop-ds-automation]
              Sheng, S. and P. Thomassen, "Operational Recommendations
              for DNSSEC Delegation Signer (DS) Automation", Work in
              Progress, Internet-Draft, draft-ietf-dnsop-ds-automation-
              09, 22 May 2026, <https://datatracker.ietf.org/doc/html/
              draft-ietf-dnsop-ds-automation-09>.

   [RDAP-JSON-VALUES]
              "RDAP JSON Values", n.d.,
              <https://www.iana.org/assignments/rdap-json-values/rdap-
              json-values.xhtml>.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              DOI 10.17487/RFC3688, January 2004,
              <https://www.rfc-editor.org/rfc/rfc3688>.

   [RFC7451]  Hollenbeck, S., "Extension Registry for the Extensible
              Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451,
              February 2015, <https://www.rfc-editor.org/rfc/rfc7451>.

   [STD69]    Internet Standard 69,
              <https://www.rfc-editor.org/info/std69>.
              At the time of writing, this STD comprises the following:

              Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
              STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
              <https://www.rfc-editor.org/info/rfc5730>.

              Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
              Domain Name Mapping", STD 69, RFC 5731,
              DOI 10.17487/RFC5731, August 2009,
              <https://www.rfc-editor.org/info/rfc5731>.

              Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
              Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732,
              August 2009, <https://www.rfc-editor.org/info/rfc5732>.






Brown                    Expires 4 January 2027                [Page 15]

Internet-Draft  EPP Delegation Maintenance Automation Ex       July 2026


              Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
              Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733,
              August 2009, <https://www.rfc-editor.org/info/rfc5733>.

              Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
              Transport over TCP", STD 69, RFC 5734,
              DOI 10.17487/RFC5734, August 2009,
              <https://www.rfc-editor.org/info/rfc5734>.

   [STD95]    Internet Standard 95,
              <https://www.rfc-editor.org/info/std95>.
              At the time of writing, this STD comprises the following:

              Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
              Registration Data Access Protocol (RDAP)", STD 95,
              RFC 7480, DOI 10.17487/RFC7480, March 2015,
              <https://www.rfc-editor.org/info/rfc7480>.

              Hollenbeck, S. and N. Kong, "Security Services for the
              Registration Data Access Protocol (RDAP)", STD 95,
              RFC 7481, DOI 10.17487/RFC7481, March 2015,
              <https://www.rfc-editor.org/info/rfc7481>.

              Hollenbeck, S. and A. Newton, "Registration Data Access
              Protocol (RDAP) Query Format", STD 95, RFC 9082,
              DOI 10.17487/RFC9082, June 2021,
              <https://www.rfc-editor.org/info/rfc9082>.

              Hollenbeck, S. and A. Newton, "JSON Responses for the
              Registration Data Access Protocol (RDAP)", STD 95,
              RFC 9083, DOI 10.17487/RFC9083, June 2021,
              <https://www.rfc-editor.org/info/rfc9083>.

              Blanchet, M., "Finding the Authoritative Registration Data
              Access Protocol (RDAP) Service", STD 95, RFC 9224,
              DOI 10.17487/RFC9224, March 2022,
              <https://www.rfc-editor.org/info/rfc9224>.

   [XSD-DATATYPES]
              Biron, P. V. and A. Malhotra, "XML Schema Part 2:
              Datatypes Second Edition", W3C Recommendation, October
              2004,
              <https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/>.

11.2.  Informative References






Brown                    Expires 4 January 2027                [Page 16]

Internet-Draft  EPP Delegation Maintenance Automation Ex       July 2026


   [CENTR-REGISTRY-LOCK]
              "Models of registry lock for top-level domain registries",
              CENTR, August 2020, <https://centr.org/library/library/
              download/9799/6192/41.html>.

   [RFC5910]  Gould, J. and S. Hollenbeck, "Domain Name System (DNS)
              Security Extensions Mapping for the Extensible
              Provisioning Protocol (EPP)", RFC 5910,
              DOI 10.17487/RFC5910, May 2010,
              <https://www.rfc-editor.org/rfc/rfc5910>.

   [RFC7344]  Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
              DNSSEC Delegation Trust Maintenance", RFC 7344,
              DOI 10.17487/RFC7344, September 2014,
              <https://www.rfc-editor.org/rfc/rfc7344>.

   [RFC7477]  Hardaker, W., "Child-to-Parent Synchronization in DNS",
              RFC 7477, DOI 10.17487/RFC7477, March 2015,
              <https://www.rfc-editor.org/rfc/rfc7477>.

   [RFC8078]  Gudmundsson, O. and P. Wouters, "Managing DS Records from
              the Parent via CDS/CDNSKEY", RFC 8078,
              DOI 10.17487/RFC8078, March 2017,
              <https://www.rfc-editor.org/rfc/rfc8078>.

   [RFC9364]  Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
              RFC 9364, DOI 10.17487/RFC9364, February 2023,
              <https://www.rfc-editor.org/rfc/rfc9364>.

   [RFC9499]  Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
              RFC 9499, DOI 10.17487/RFC9499, March 2024,
              <https://www.rfc-editor.org/rfc/rfc9499>.

   [RFC9615]  Thomassen, P. and N. Wisiol, "Automatic DNSSEC
              Bootstrapping Using Authenticated Signals from the Zone's
              Operator", RFC 9615, DOI 10.17487/RFC9615, July 2024,
              <https://www.rfc-editor.org/rfc/rfc9615>.

Author's Address

   Gavin Brown
   ICANN
   Email: gavin.brown@icann.org








Brown                    Expires 4 January 2027                [Page 17]