Network Working Group                                      S. HollenbeckInternet-Draft                                             Verisign LabsObsoletes: 7451 (if approved)                            2 February 2026Intended status: Best Current Practice                                  Expires: 6 August 2026      Extension Registry for the Extensible Provisioning Protocol                 draft-ietf-regext-ext-registry-epp-03Abstract   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 6 August 2026.Copyright Notice   Copyright (c) 2026 IETF Trust and the persons identified as the   document authors.  All rights reserved.Hollenbeck                Expires 6 August 2026                 [Page 1]RFC 7451                 EPP Extension Registry            February 2026   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     1.1.  Conventions Used in This Document . . . . . . . . . . . .   3   2.  Extension Specification and Registration Procedure  . . . . .   3     2.1.  Extension Specification . . . . . . . . . . . . . . . . .   3       2.1.1.  Designated Expert Evaluation Criteria . . . . . . . .   4     2.2.  Registration Procedure  . . . . . . . . . . . . . . . . .   5       2.2.1.  Required Information  . . . . . . . . . . . . . . . .   5       2.2.2.  Registration Form . . . . . . . . . . . . . . . . . .   6       2.2.3.  Registration Processing . . . . . . . . . . . . . . .   8       2.2.4.  Updating Registry Entries . . . . . . . . . . . . . .   8   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   9   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   9     5.2.  Informative References  . . . . . . . . . . . . . . . . .  10   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  10   Change Log  . . . . . . . . . . . . . . . . . . . . . . . . . . .  11   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  111.  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 6 August 2026                 [Page 2]RFC 7451                 EPP Extension Registry            February 2026   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.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.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.   The "Specification Required" policy requires review by a designated   expert.  Section 5 of RFC 8126 [RFC8126] describes the role of   designated experts and the function they perform.  This policy also   requires "a permanent and readily available public specification".   RFC documents meet that requirement.  Proprietary specifications may   meet that requirement, depending on how they are archived and   accessible.  Internet-Draft documents do not meet that requirement.   RFC 2026 [RFC2026] notes that "Internet-Drafts have no formal status,   and are subject to change or removal at any time".Hollenbeck                Expires 6 August 2026                 [Page 3]RFC 7451                 EPP Extension Registry            February 20262.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 MUST use the   existing regext mailing list (regext@ietf.org) or its successor for   public discussion of registration requests.   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.  XML schema and   namespace URIs MUST be registered in the IETF XML Registry using the   procedures described in RFC 3688 [RFC3688].  IETF namespaces MUST be   reserved for IETF specifications.  Non-IETF namespaces MUST be used   for non-IETF specifications (which includes RFC documents published   using the Independent Submission stream); the designated experts may   need to work with a registrant to identify URIs that can be added to   the IETF XML Registry.  Extensions and any normative reference   necessary to implement the extension MUST NOT be denoted with "work   in-progress" or any similar description.   The results of the evaluation MUST 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 thatHollenbeck                Expires 6 August 2026                 [Page 4]RFC 7451                 EPP Extension Registry            February 2026   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.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 of the specification document.   For RFC documents, the possible set of values includes "Standards   Track", "Informational", "Experimental", "Historic", and "BCP" as   described in Sections 4 and 5 of RFC 2026 [RFC2026].  For documents   that are not RFCs, this will always be "Other".   Reference: A permanent, 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 that meets the   "Specification Required" registry policy.   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 extension, 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 MUST 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 usedHollenbeck                Expires 6 August 2026                 [Page 5]RFC 7451                 EPP Extension Registry            February 2026   to indicate that.  If the extension is not associated with domain   name processing, the case-insensitive text string "N/A" (Not   Applicable) 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.  "Inactive" can also be used for   extensions for which a reference specification becomes unavailable as   described in Section 2.2.4.   Notes: Either "None" or other text that describes optional notes to   be included with the registered extension.  If the Status value is   "Inactive", text MUST be included to describe how and when this state   was reached.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-----Hollenbeck                Expires 6 August 2026                 [Page 6]RFC 7451                 EPP Extension Registry            February 2026   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-----    Name of Extension:    "An Example Extension for the .example Top-Level Domain"    Document Status: Other    Reference:    https://www.example.com/html/example-epp-ext.txt    Registrant Name and Email Address: John Doe, jdoe@example.com    TLDs: .example    IPR Disclosure:    https://www.example.com/ipr/example-epp-ext-ipr.html    Status: Active    Notes: None    -----END FORM-----Hollenbeck                Expires 6 August 2026                 [Page 7]RFC 7451                 EPP Extension Registry            February 20262.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 MUST indicate whether the enclosed form   represents an insertion of a new record (indicated by the word   "INSERT" in the subject line), replacement of an existing record   (indicated by the word "MODIFY" in the subject line), deactivation of   an existing record (indicated by the word "DEACTIVATE" in the subject   line), or removal of an existing record (indicated by the word   "REMOVE" in the subject line).  Records in this registry may only be   removed or deactivated with IESG Approval (see [RFC8126]).  On   receipt of a 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 current working   group mailing list focused on the development of EPP extensions.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   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 https://www.iana.org/protocols:        Registry Title:          Extensions for the Extensible Provisioning Protocol (EPP)Hollenbeck                Expires 6 August 2026                 [Page 8]RFC 7451                 EPP Extension Registry            February 2026        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.  References5.1.  Normative References   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision              3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,              <https://www.rfc-editor.org/info/rfc2026>.   [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>.Hollenbeck                Expires 6 August 2026                 [Page 9]RFC 7451                 EPP Extension Registry            February 2026   [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>.   [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>.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: Gavin Brown, James Galvin, James Gould, Pawel Kowalik, Andrew   Newton, Jasdip Singh.Hollenbeck                Expires 6 August 2026                [Page 10]RFC 7451                 EPP Extension Registry            February 2026Change Log   This section is to be removed before publishing as an RFC.   -00:  Initial WG version.   -01:  WG last call edits: added reference to RFC 2026 to clarify the      status of Internet-Draft documents as extension specifications.      "IESG approval" -> "IESG Approval" in Section 2.2.3.  Added      DEACTIVATE and REMOVE request processing to Section 2.2.3.      Clarified use of IETF namespaces and "work in progress"      specifications in Section 2.2.1.  Clarified status values in      Section 2.2.1.  Updated acknowledgements.   -02:  Changed intended status from Informational to BCP.  Added text      to address Independent Submission stream RFCs to Section 2.1.      Noted that the value of the TLDs field (Section 2.2.1) can be "N/      A".  Added text to Section 2.2.1 to ensure that it's consistent      with Section 2.2.4.  Updated examples to use "https" instead of      "http".  Updated acknowledgements.   -03:  Updated to use BCP 14 keywords.  Updated Section 2.1 and      Section 2.1.1 to clarify ISE RFC use as a reference specification      for an extension.Author's Address   Scott Hollenbeck   Verisign Labs   12061 Bluemont Way   Reston, VA 20190   United States of America   Email: shollenbeck@verisign.com, sah6284@gmail.com   URI:   https://www.verisignlabs.com/Hollenbeck                Expires 6 August 2026                [Page 11]