Extension Registry for the Extensible Provisioning Protocol
draft-ietf-regext-ext-registry-epp-00

Network Working Group                                      S. Hollenbeck
Internet-Draft                                             Verisign Labs
Obsoletes: 7451 (if approved)                            13 October 2025
Intended status: Informational                                          
Expires: 16 April 2026

      Extension Registry for the Extensible Provisioning Protocol
                 draft-ietf-regext-ext-registry-epp-00

Abstract

   The Extensible Provisioning Protocol (EPP) includes features to add
   functionality by extending the protocol.  It does not, however,
   describe how those extensions are managed.  This document describes a
   procedure for the registration and management of extensions to EPP,
   and it specifies a format for an IANA registry to record those
   extensions.

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 16 April 2026.

Copyright Notice

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

Hollenbeck                Expires 16 April 2026                 [Page 1]
RFC 7451                 EPP Extension Registry             October 2025

   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
   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
   2.  Extension Specification and Registration Procedure  . . . . .   3
     2.1.  Extension Specification . . . . . . . . . . . . . . . . .   3
       2.1.1.  Designated Expert Evaluation Criteria . . . . . . . .   3
     2.2.  Registration Procedure  . . . . . . . . . . . . . . . . .   4
       2.2.1.  Required Information  . . . . . . . . . . . . . . . .   5
       2.2.2.  Registration Form . . . . . . . . . . . . . . . . . .   6
       2.2.3.  Registration Processing . . . . . . . . . . . . . . .   7
       2.2.4.  Updating Registry Entries . . . . . . . . . . . . . .   7
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     5.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   9
   Change Log  . . . . . . . . . . . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   Domain name registries implement a variety of operational and
   business models.  The differences in these models make it impossible
   to develop a "one size fits all" provisioning protocol; the
   Extensible Provisioning Protocol [RFC5730] was designed to focus on a
   minimal set of common functionality with built-in extension
   capabilities that allow new features to be specified on an "as
   needed" basis.  Guidelines for extending EPP are documented in RFC
   3735 [RFC3735].

   RFCs 3735 and 5730 do not describe how extension development can be
   managed and coordinated.  This has led to a situation in which server
   operators can develop different extensions to address similar needs,
   such as the provisioning of Value Added Tax (VAT) information.
   Clients then need to support multiple extensions that serve similar
   purposes, and interoperability suffers as a result.

Hollenbeck                Expires 16 April 2026                 [Page 2]
RFC 7451                 EPP Extension Registry             October 2025

   An IANA registry can be used to help manage and coordinate the
   development of protocol extensions.  This document describes an IANA
   registry that will be used to coordinate the development of EPP
   extensions.

   This update was written to address a few issues that were identified
   with RFC 7451 [RFC7451] over time.  The name of the mailing list used
   to review and discuss registration requests was changed from "eppext"
   to "regext" throughout the document.  Text has been added to describe
   reviewer responsibility to confirm correctness of URIs used in
   extension registration requests.  "Other" has been added to the set
   of document status values for the registry to avoid confusion with
   "Informational" RFCs.  Section 2.2.3 has been updated to note that
   registry entries can be removed with IESG approval.  Section 2.2.2
   has been updated by changing "<registrant name>, <email address>" to
   "<name>, <address>" to meet right margin constraints.

2.  Extension Specification and Registration Procedure

   This section describes the format of an IANA registry and the
   procedures used to populate and manage registry entries.

2.1.  Extension Specification

   This registry uses the "Specification Required" policy described in
   RFC 8126 [RFC8126].  An English language version of the extension
   specification will be referenced from the registry, though non-
   English versions of the specification may also be provided.  Note
   that Section 2.1 of RFC 3735 [RFC3735] provides specific guidelines
   for documenting EPP extensions.

   Note that the "Specification Required" policy implies review by a
   "designated expert".  Section 5 of RFC 8126 [RFC8126] describes the
   role of designated experts and the function they perform.

2.1.1.  Designated Expert Evaluation Criteria

   A high-level description of the role of the designated expert is
   described in Section 5.2 of RFC 8126 [RFC8126].  Specific guidelines
   for the appointment of designated experts and the evaluation of EPP
   extensions are provided here.

   The IESG should appoint a small pool of individuals (perhaps 3 - 5)
   to serve as designated experts, as described in Section 5.2 of RFC
   8126 [RFC8126].  The pool should have a single administrative chair
   who is appointed by the IESG.  The designated experts should use the
   existing regext mailing list (regext@ietf.org) or its successor for
   public discussion of registration requests.

Hollenbeck                Expires 16 April 2026                 [Page 3]
RFC 7451                 EPP Extension Registry             October 2025

   Extensions should be evaluated for architectural soundness using the
   guidelines described in RFC 3735 [RFC3735], including the Security
   Considerations section of that document.  Expert evaluation should
   explicitly include consideration of the privacy consequences of
   proposed extensions, and, at a minimum, ensure that any privacy
   considerations are fully documented in the relevant specification(s).
   URIs proposed in extensions (XML namespace and schema registration
   requests are commonly found in EPP extensions) should be evaluated
   for both syntactic and semantic correctness.  For example, IETF
   namespaces should be reserved for IETF specifications.

   The results of the evaluation should be shared via email with the
   registrant and the regext mailing list.  Issues discovered during the
   evaluation can be corrected by the registrant, and those corrections
   can be submitted to the designated experts until the designated
   experts explicitly decide to accept or reject the registration
   request.  The designated experts must make an explicit decision and
   that decision must be shared via email with the registrant and the
   regext mailing list.  If the specification for an extension is an
   IETF Standards Track document, no review is required by the
   designated expert.

   Designated experts should be permissive in their evaluation of
   requests to register extensions that have been implemented and
   deployed by at least one registry/registrar pair.  This implies that
   it may indeed be possible to register multiple extensions that
   provide the same functionality.  Requests to register extensions that
   have not been deployed should be evaluated with a goal of reducing
   functional duplication.  A potential registrant who submits a request
   to register a new, un-deployed extension that includes similar
   functionality to an existing, registered extension should be made
   aware of the existing extension.  The registrant should be asked to
   reconsider their request given the existence of a similar extension.
   Should they decline to do so, perceived similarity should not be a
   sufficient reason for rejection as long as all other requirements are
   met.

2.2.  Registration Procedure

   The registry contains information describing each registered
   extension.  Registry entries are created and managed by sending forms
   to IANA that describe the extension and the operation to be performed
   on the registry entry.

Hollenbeck                Expires 16 April 2026                 [Page 4]
RFC 7451                 EPP Extension Registry             October 2025

2.2.1.  Required Information

   Name of Extension: A case-insensitive, ASCII text string that
   contains the name of the extension specification.  Non-ASCII
   representations of the extension name can be included in the "Notes"
   described below.

   Document Status: The document status ("Informational", "Standards
   Track", "Other", etc.) of the specification document.  For documents
   that are not RFCs, this will always be "Other".

   Reference: A publicly available reference to the specification of
   this extension.  This could be an RFC number or some other pointer to
   the document defining the extension.

   Registrant Name and Email Address: The name and email address of the
   person that is responsible for managing the registry entry.  If the
   registration is of an IETF Standards Track document, this can simply
   be listed as "IESG, <iesg@ietf.org>".

   TLDs: A text string containing the top-level domain name (or domain
   names), including the preceding ".", for which the extension has been
   specified (e.g., ".org").  If there are multiple TLDs, they are given
   as a list of domain names separated by commas, (e.g. ".com", ".net").
   Internationalized Domain Name (IDN) TLDs should be specified in
   A-label [RFC5890] format.  If the extension is not associated with a
   specific top-level domain, the case-insensitive text string "Any" can
   be used to indicate that.

   IPR Disclosure: A pointer to any Intellectual Property Rights (IPR)
   disclosure document(s) related to this extension, or "None" may be
   used if there are no such disclosures.  This can be an IPR disclosure
   filed with the IETF in accordance with RFC 3979 [RFC3979] as updated
   by RFC 4879 [RFC4879] if the extension is part of an IETF
   Contribution, or it can be other IPR disclosure documents identifying
   the claimed intellectual property rights and terms of use for
   extensions that are not part of an IETF Contribution.

   Status: Either "Active" or "Inactive".  The "Active" status is used
   for extensions that are currently implemented and in use.  The
   "Inactive" status is used for extensions that are not implemented or
   are otherwise not being used.

   Notes: Either "None" or other text that describes optional notes to
   be included with the registered extension.  If the Status value is
   "Inactive", text should be included to describe how and when this
   state was reached.

Hollenbeck                Expires 16 April 2026                 [Page 5]
RFC 7451                 EPP Extension Registry             October 2025

2.2.2.  Registration Form

   The required information must be formatted consistently using the
   following registration form.  Form field names and values may appear
   on the same line.

    -----BEGIN FORM-----
    Name of Extension: <text string> (quotes are optional)

    Document Status: <document status>

    Reference: <RFC number, URL, etc.>

    Registrant Name and Email Address: <name>, <address>

    TLDs: "Any"|<one or more TLD text strings separated by commas>

    IPR Disclosure: "None"|<URL>

    Status: "Active"|"Inactive"

    Notes: "None"|<optional text>
    -----END FORM-----

   Example form with RFC specification:

    -----BEGIN FORM-----
    Name of Extension:
    "An Extension RFC for the Extensible Provisioning Protocol (EPP)"

    Document Status:  Standards Track

    Reference:  RFC XXXX

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

    TLDs: Any

    IPR Disclosure: None

    Status: Active

    Notes: None
    -----END FORM-----

   Example form with non-RFC specification:

    -----BEGIN FORM-----

Hollenbeck                Expires 16 April 2026                 [Page 6]
RFC 7451                 EPP Extension Registry             October 2025

    Name of Extension:
    "An Example Extension for the .example Top-Level Domain"

    Document Status:  Informational

    Reference:
    http://www.example.com/html/example-epp-ext.txt

   Registrant Name and Email Address:  John Doe, jdoe@example.com

   TLDs:  .example

    IPR Disclosure:
    http://www.example.com/ipr/example-epp-ext-ipr.html

    Status: Active

    Notes: None
    -----END FORM-----

2.2.3.  Registration Processing

   Registrants should send each registration form to IANA with a single
   record for incorporation into the registry.  Send the form via email
   to <iana@iana.org> or complete the online form found on the IANA web
   site.  The subject line should indicate whether the enclosed form
   represents an insertion of a new record (indicated by the word
   "INSERT" in the subject line) or a replacement of an existing record
   (indicated by the word "MODIFY" in the subject line).  Records in
   this registry may be revoked with IESG approval (see [RFC8126]).  On
   receipt of the registration request, IANA will initiate review by the
   designated expert(s), who will evaluate the request using the
   criteria in Section 2.1.1 in consultation with the regext mailing
   list.

2.2.4.  Updating Registry Entries

   When submitting changes to existing registry entries, include text in
   the "Notes" field of the registration form describing the change.
   Under normal circumstances, registry entries are only to be updated
   by the registrant.  If the registrant becomes unavailable or
   otherwise unresponsive, the designated expert can submit a
   registration form to IANA to update the registrant information.
   Entries can change state from "Active" to "Inactive" and back again
   as long as state-change requests conform to the processing
   requirements identified in this document.  In addition to entries
   that become "Inactive" due to a lack of implementation, entries for
   which a specification becomes consistently unavailable over time

Hollenbeck                Expires 16 April 2026                 [Page 7]
RFC 7451                 EPP Extension Registry             October 2025

   should be marked "Inactive" by the designated expert until the
   specification again becomes reliably available.

3.  IANA Considerations

   IANA has created the "Extensions for the Extensible Provisioning
   Protocol (EPP)" registry to manage EPP extensions.  This registry has
   its own heading on IANA's protocol listings.  The information to be
   registered and the procedures to be followed in populating the
   registry are described in Section 2.

   Name of registry: Extensions for the Extensible Provisioning Protocol
   (EPP)

      Section at http://www.iana.org/protocols:
        Registry Title:
          Extensions for the Extensible Provisioning Protocol (EPP)
        Registry Name:
          Extensions for the Extensible Provisioning Protocol (EPP)
        Registration Procedure:
          Specification Required
        Reference:
          This document
        Required information:
          See Section 2.2.1
        Review process:
          "Specification Required" as described in RFC 8126 [RFC8126]
        Size, format, and syntax of registry entries:
          See Section 2.2.1
        Initial assignments and reservations:
          Preserved from the existing registry.  Please change all non-
          RFC entries in the registry that have document status
          "Informational" to document status "Other".

   In addition, the form used to populate and manage the registry has
   been added to the table of Protocol Registration Forms maintained by
   IANA.  IANA is further requested to forward all designated expert
   review requests to both the designated expert and the "regext"
   mailing list or its successor.

4.  Security Considerations

   This document introduces no new security considerations to EPP.
   However, extensions should be evaluated according to the Security
   Considerations of RFC 3735 [RFC3735].

5.  References

Hollenbeck                Expires 16 April 2026                 [Page 8]
RFC 7451                 EPP Extension Registry             October 2025

5.1.  Normative References

   [RFC3979]  Bradner, S., Ed., "Intellectual Property Rights in IETF
              Technology", RFC 3979, DOI 10.17487/RFC3979, March 2005,
              <https://www.rfc-editor.org/info/rfc3979>.

   [RFC4879]  Narten, T., "Clarification of the Third Party Disclosure
              Procedure in RFC 3979", RFC 4879, DOI 10.17487/RFC4879,
              April 2007, <https://www.rfc-editor.org/info/rfc4879>.

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

   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, DOI 10.17487/RFC5890, August 2010,
              <https://www.rfc-editor.org/info/rfc5890>.

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

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

5.2.  Informative References

   [RFC3735]  Hollenbeck, S., "Guidelines for Extending the Extensible
              Provisioning Protocol (EPP)", RFC 3735,
              DOI 10.17487/RFC3735, March 2004,
              <https://www.rfc-editor.org/info/rfc3735>.

Acknowledgements

   The information described in the registry is based on a suggestion
   posted to the provreg mailing list by Jay Daley in August 2013.  The
   need to update RFC 7451 was first proposed by Gavin Brown.
   Additional feedback for the update was provided by the following
   people: Andrew Newton.

Change Log

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

   -00:  Initial WG version.

Hollenbeck                Expires 16 April 2026                 [Page 9]
RFC 7451                 EPP Extension Registry             October 2025

Author's Address

   Scott Hollenbeck
   Verisign Labs
   12061 Bluemont Way
   Reston, VA 20190
   United States of America
   Email: shollenbeck@verisign.com
   URI:   http://www.verisignlabs.com/

Hollenbeck                Expires 16 April 2026                [Page 10]