Registration Extensions (REGEXT)                                G. Brown
Internet-Draft                                                P. Hoffman
Intended status: Informational                                     ICANN
Expires: 29 July 2024                                    26 January 2024


    Extensible Provisioning Protocol (EPP) mapping for DELEG records
                        draft-brown-epp-deleg-00

Abstract

   This document describes an extension to the Extensible Provisioning
   Protocol ([STD69]) which allows clients to provision DELEG records
   for domain names.

About this draft

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

   The source for this draft, and an issue tracker, may can be found at
   https://github.com/gbxyz/epp-deleg-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 29 July 2024.

Copyright Notice

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








Brown & Hoffman           Expires 29 July 2024                  [Page 1]

Internet-Draft             EPP DELEG Extension              January 2024


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions used in this document . . . . . . . . . . . . . .   3
   3.  Extension elements  . . . . . . . . . . . . . . . . . . . . .   3
   4.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  EPP command mapping . . . . . . . . . . . . . . . . . . . . .   4
     5.1.  EPP query commands  . . . . . . . . . . . . . . . . . . .   4
       5.1.1.  EPP <info> command  . . . . . . . . . . . . . . . . .   4
     5.2.  EPP transform commands  . . . . . . . . . . . . . . . . .   5
       5.2.1.  EPP <create> command  . . . . . . . . . . . . . . . .   5
       5.2.2.  EPP <update> command  . . . . . . . . . . . . . . . .   6
   6.  Relationship between DELEG and host objects/attributes  . . .   9
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   8.  Formal syntax . . . . . . . . . . . . . . . . . . . . . . . .   9
   9.  IANA considerations . . . . . . . . . . . . . . . . . . . . .  11
     9.1.  XML Namespace . . . . . . . . . . . . . . . . . . . . . .  11
     9.2.  EPP Extension Registry  . . . . . . . . . . . . . . . . .  11
   10. Normative References  . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   The Internet-Draft "Extensible Delegation for DNS" ([DELEG]) aims to
   provide an enhanced method of delegation in the DNS, as an
   alternative to the traditional NS record.

   This document describes an extension to the EPP domain mapping
   (RFC5731) to allow EPP clients to provision DELEG records for domain
   names in an EPP server.

   EPP provides mechanisms for extending the protocol by (a) adding new
   properties to existing object mappings and (b) definining new object
   mappings.  Although EPP supports two different models for traditional
   NS records (host attributes and host objects, as described in
   Section 1.12 of [RFC5731]), this document only uses the former, and
   does not define a new object mapping for DELEG records because the
   DELEG specification itself implements many of the features that would
   otherwise require an object mapping: for example the "AliasMode"
   mode, which allows the delegation information for many domains to be
   managed as a single set.




Brown & Hoffman           Expires 29 July 2024                  [Page 2]

Internet-Draft             EPP DELEG Extension              January 2024


2.  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.

   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 required features of this protocol.

   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, 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 examples (such as the string deleg
   in deleg:create) are solely for illustrative purposes.  A conforming
   implementation MUST NOT require the use of these or any other
   specific namespace prefixes.

3.  Extension elements

   This document defines a new element, <deleg:deleg>, which appears in
   query and transform commands for domain objects.

   This element is a representation of a DELEG record in XML.  Note that
   DELEG records have the same presentation format as SVCB records
   ([RFC9460]).

   The <deleg:deleg> element has the following attributes:

   *  a priority attribute, which is an integer that corresponds to the
      SvcPriority field;

   *  a target attribute, which corresponds to the TargetName field.




Brown & Hoffman           Expires 29 July 2024                  [Page 3]

Internet-Draft             EPP DELEG Extension              January 2024


   The <deleg:deleg> element MAY have a single child element,
   <deleg:params>, which corresponds to the svcParams field.  DELEG
   record SvcParams are mapped onto this element's attributes, with
   SvcParamKey being the attribute name, and SvcParamValue being its
   value.

4.  Examples

   Example "AliasMode" <deleg:deleg> element:

   <deleg:deleg
     priority="0"
     target="config.example.net"/>

   Example "ServiceMode" <deleg:deleg> element:

   <deleg:deleg
     priority="1"
     target="ns1.example.com">
     <deleg:params
       ipv4hint="192.0.2.1"
       ipv6hint="2001:DB8::1"/>
   </deleg:deleg>

5.  EPP command mapping

5.1.  EPP query commands

5.1.1.  EPP <info> command

   This extension defines an additional element for EPP <info> responses
   for domain object.

   When a server receives a domain or host <info> command from a client
   which included the extension namespace in the <svcExtension> element
   of the <login> command, the response MUST contain an <extension>
   element, which MUST contain a <deleg:infData> element.  This element
   MAY contain one or more <deleg:deleg> elements as described in
   Section 3.

   Example <info> response:










Brown & Hoffman           Expires 29 July 2024                  [Page 4]

Internet-Draft             EPP DELEG Extension              January 2024


   S:<?xml version="1.0" encoding="utf-8" standalone="no"?>
   S:<epp 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>example.com</domain:name>
   S:        <domain:roid>EXAMPLE1-REP</domain:roid>
   S:        <domain:status s="ok"/>
   S:        <domain:clID>ClientX</domain:clID>
   S:        <domain:crID>ClientX</domain:crID>
   S:        <domain:crDate>2023-11-08T10:14:55.0Z</domain:crDate>
   S:        <domain:exDate>2024-11-08T10:14:55.0Z</domain:exDate>
   S:      </domain:infData>
   S:    </resData>
   S:    <extension>
   S:      <deleg:infData
   S:        xmlns:deleg="urn:ietf:params:xml:ns:epp:deleg-0.01">
   S:        <deleg:deleg priority="1" target="ns1.example.com">
   S:          <deleg:params
   S:            ipv4hint="192.0.2.1"
   S:            ipv6hint="2001:DB8::1"/>
   S:        </deleg:deleg>
   S:        <deleg:deleg priority="1" target="ns2.example.net">
   S:          <deleg:params
   S:            ipv4hint="192.0.2.2"
   S:            ipv6hint="2001:DB8::2"/>
   S:        </deleg:deleg>
   S:      </deleg:infData>
   S:    </extension>
   S:    <trID>
   S:      <clTRID>ABC-12345</clTRID>
   S:      <svTRID>54322-XYZ</svTRID>
   S:    </trID>
   S:  </response>
   S:</epp>

5.2.  EPP transform commands

5.2.1.  EPP <create> command

   This extension defines an additional element for EPP <create>
   commands for domain objects.





Brown & Hoffman           Expires 29 July 2024                  [Page 5]

Internet-Draft             EPP DELEG Extension              January 2024


   The <command> element of the <create> command frame MAY contain an
   <extension> element which MAY contain a <deleg:create> element.  This
   element MUST contain one or more <deleg:deleg> records as described
   in Section 3.

   Example <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:authInfo>
   C:          <domain:pw/>
   C:        </domain:authInfo>
   C:      </domain:create>
   C:    </create>
   C:    <extension>
   C:      <deleg:create
   C:        xmlns:deleg="urn:ietf:params:xml:ns:epp:deleg-0.01">
   C:        <deleg:deleg priority="1" target="ns1.example.com">
   C:          <deleg:params
   C:            ipv4hint="192.0.2.1"
   C:            ipv6hint="2001:DB8::1"/>
   C:        </deleg:deleg>
   C:        <deleg:deleg priority="1" target="ns2.example.net">
   C:          <deleg:params
   C:            ipv4hint="192.0.2.2"
   C:            ipv6hint="2001:DB8::2"/>
   C:        </deleg:deleg>
   C:      </deleg:create>
   C:    </extension>
   C:    <clTRID>ABC-12345</clTRID>
   C:  </command>
   C:</epp>

5.2.2.  EPP <update> command

   This extension defines an additional element for EPP <update>
   commands for domain objects.

   The <command> element of the <create> command frame MAY contain an
   <extension> element which MAY contain a <deleg:update> element.

   The <deleg:update> element has the following child elements:



Brown & Hoffman           Expires 29 July 2024                  [Page 6]

Internet-Draft             EPP DELEG Extension              January 2024


   *  An OPTIONAL <deleg:add> element, containing any <deleg:deleg>
      records to be added to the domain; and

   *  An OPTIONAL <deleg:rem> element, containing any <deleg:deleg>
      records to be removed from the domain.

   Example <update> command, which removes one <deleg:deleg> record and
   adds another:

   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:      <deleg:update xmlns:deleg="urn:ietf:params:xml:ns:epp:deleg-0.01">
   C:        <deleg:add>
   C:          <deleg:deleg priority="1" target="ns3.example.org">
   C:            <deleg:params
   C:              ipv4hint="192.0.2.3"
   C:              ipv6hint="2001:DB8::3"/>
   C:          </deleg:deleg>
   C:        </deleg:add>
   C:        <deleg:rem>
   C:          <deleg:deleg priority="1" target="ns1.example.com">
   C:            <deleg:params
   C:              ipv4hint="192.0.2.1"
   C:              ipv6hint="2001:DB8::1"/>
   C:          </deleg:deleg>
   C:        </deleg:rem>
   C:      </deleg:update>
   C:    </extension>
   C:    <clTRID>ABC-12345</clTRID>
   C:  </command>
   C:</epp>

   Example <update> command, which removes one <deleg:deleg> record but
   does not add any:









Brown & Hoffman           Expires 29 July 2024                  [Page 7]

Internet-Draft             EPP DELEG Extension              January 2024


   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:      <deleg:update xmlns:deleg="urn:ietf:params:xml:ns:epp:deleg-0.01">
   C:        <deleg:rem>
   C:          <deleg:deleg priority="1" target="ns3.example.org">
   C:            <deleg:params
   C:              ipv4hint="192.0.2.3"
   C:              ipv6hint="2001:DB8::3"/>
   C:          </deleg:deleg>
   C:        </deleg:rem>
   C:      </deleg:update>
   C:    </extension>
   C:    <clTRID>ABC-12345</clTRID>
   C:  </command>
   C:</epp>

   Example <update> command, which adds one <deleg:deleg> record but
   does not remove any:

























Brown & Hoffman           Expires 29 July 2024                  [Page 8]

Internet-Draft             EPP DELEG Extension              January 2024


   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:      <deleg:update xmlns:deleg="urn:ietf:params:xml:ns:epp:deleg-0.01">
   C:        <deleg:add>
   C:          <deleg:deleg priority="1" target="ns3.example.org">
   C:            <deleg:params
   C:              ipv4hint="192.0.2.3"
   C:              ipv6hint="2001:DB8::3"/>
   C:          </deleg:deleg>
   C:        </deleg:add>
   C:      </deleg:update>
   C:    </extension>
   C:    <clTRID>ABC-12345</clTRID>
   C:  </command>
   C:</epp>

6.  Relationship between DELEG and host objects/attributes

   It is anticpated that most domains will need both DELEG and
   traditional NS records published in their parent zone for the
   foreseeable future.

   Therefore, EPP servers SHOULD allow clients to configure domain names
   to have both DELEG records and host objects or host attributes.

7.  Security Considerations

   Under the initial design of the DELEG record, the security
   implications of propoerly carrying the record in EPP, and name
   servers using such information in zones, are similar to the security
   implications for NS records.  If there are later extensions to the
   DELEG record, those extension may have different security
   considerations that will need to be documented.

8.  Formal syntax

   The formal syntax presented here is a complete schema representation
   of the extension suitable for automated validation of EPP XML
   instances.




Brown & Hoffman           Expires 29 July 2024                  [Page 9]

Internet-Draft             EPP DELEG Extension              January 2024


   <?xml version="1.0" encoding="UTF-8"?>
   <schema
     xmlns="http://www.w3.org/2001/XMLSchema"
     targetNamespace="urn:ietf:params:xml:ns:epp:deleg-0.01"
     xmlns:deleg="urn:ietf:params:xml:ns:epp:deleg-0.01"
     xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
     elementFormDefault="qualified">
     <annotation>
       <documentation>
         Extensible Provisioning Protocol v1.0 extension
         schema for DELEG records.
       </documentation>
     </annotation>

     <import namespace="urn:ietf:params:xml:ns:eppcom-1.0"/>

     <element name="infData" type="deleg:containerType"/>
     <element name="create" type="deleg:containerType"/>
     <element name="update" type="deleg:updateType"/>

     <complexType name="updateType">
       <sequence>
         <element name="add" type="deleg:containerType"
           minOccurs="0"/>
         <element name="rem" type="deleg:containerType"
           minOccurs="0"/>
       </sequence>
     </complexType>

     <complexType name="containerType">
       <sequence>
         <element name="deleg" type="deleg:delegType"
           minOccurs="0"
           maxOccurs="unbounded"/>
       </sequence>
     </complexType>

     <complexType name="delegType">
       <sequence>
         <element name="params" type="deleg:paramType"
           minOccurs="0"/>
       </sequence>
       <attribute name="priority" type="unsignedShort"/>
       <attribute name="target" type="eppcom:labelType"/>
     </complexType>

     <complexType name="paramType">
       <anyAttribute processContents="skip"/>



Brown & Hoffman           Expires 29 July 2024                 [Page 10]

Internet-Draft             EPP DELEG Extension              January 2024


     </complexType>
   </schema>

9.  IANA considerations

9.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 has been made by IANA:

   Registration for the DELEG namespace:

   *URI:* urn:ietf:params:xml:ns:epp:deleg-0.01

   *Registrant Contact:* See the author(s) of this document

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

   Registration for the DELEG XML schema:

   *URI:* urn:ietf:params:xml:schema:epp:deleg-0.01

   *Registrant Contact:* See the author(s) of this document

   *XML:* See the "Formal syntax" section of this document

9.2.  EPP Extension Registry

   The EPP extension described in this document has been registered by
   the IANA in the Extensions for the "Extensible Provisioning Protocol
   (EPP)" registry described in [RFC7451].  The details of the
   registration are as follows:

   *Name of Extension:* Extensible Provisioning Protocol (EPP) Mapping
   for DELEG records

   *Document Status:* Standards Track

   *Reference:* URL of this document

   *Registrant Name and Email Address:* See the author(s) of this
   document

   *TLDs:* Any

   *IPR Disclosure:* None




Brown & Hoffman           Expires 29 July 2024                 [Page 11]

Internet-Draft             EPP DELEG Extension              January 2024


   *Status:* Active

   *Notes:* None

10.  Normative References

   [RFC2119]  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>.

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

   [RFC7451]  Hollenbeck, S., "Extension Registry for the Extensible
              Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451,
              February 2015, <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,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC9460]  Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
              and Parameter Specification via the DNS (SVCB and HTTPS
              Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
              November 2023, <https://www.rfc-editor.org/info/rfc9460>.

   [STD69]    Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
              STD 69, RFC 5730, August 2009.

              Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
              Domain Name Mapping", STD 69, RFC 5731, August 2009.

              Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
              Host Mapping", STD 69, RFC 5732, August 2009.

              Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
              Contact Mapping", STD 69, RFC 5733, August 2009.

              Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
              Transport over TCP", STD 69, RFC 5734, August 2009.

              <https://www.rfc-editor.org/info/std69>







Brown & Hoffman           Expires 29 July 2024                 [Page 12]

Internet-Draft             EPP DELEG Extension              January 2024


   [DELEG]    April, T., Špaček, P., Weber, R., and Lawrence,
              "Extensible Delegation for DNS", Work in Progress,
              Internet-Draft, draft-dnsop-deleg-00, 23 January 2024,
              <https://datatracker.ietf.org/doc/html/draft-dnsop-deleg-
              00>.

Authors' Addresses

   Gavin Brown
   ICANN
   12025 Waterfront Drive, Suite 300
   Los Angeles, CA 90094-2536
   United States of America
   Email: gavin.brown@icann.org


   Paul Hoffman
   ICANN
   12025 Waterfront Drive, Suite 300
   Los Angeles, CA 90094-2536
   United States of America
   Email: paul.hoffman@icann.org





























Brown & Hoffman           Expires 29 July 2024                 [Page 13]