Network Working Group S. Hollenbeck Internet-Draft Verisign Labs Obsoletes: 7451 (if approved) 17 June 2025 Intended status: Informational Expires: 19 December 2025 Extension Registry for the Extensible Provisioning Protocol draft-hollenbeck-rfc7451bis-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 19 December 2025. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Hollenbeck Expires 19 December 2025 [Page 1] RFC 7451 EPP Extension Registry June 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 . . . . . . . . . . . . . . . . 4 2.2.2. Registration Form . . . . . . . . . . . . . . . . . . 5 2.2.3. Registration Processing . . . . . . . . . . . . . . . 7 2.2.4. Updating Registry Entries . . . . . . . . . . . . . . 7 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Normative References . . . . . . . . . . . . . . . . . . 10 5.2. Informative References . . . . . . . . . . . . . . . . . 10 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 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 19 December 2025 [Page 2] RFC 7451 EPP Extension Registry June 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. 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. 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 correctness. Hollenbeck Expires 19 December 2025 [Page 3] RFC 7451 EPP Extension Registry June 2025 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. 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", etc.) of the specification document. For documents that are not RFCs, this will always be "Informational". 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. Hollenbeck Expires 19 December 2025 [Page 4] RFC 7451 EPP Extension Registry June 2025 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, ". 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. 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: (quotes are optional) Document Status: Reference: Registrant Name and Email Address: , Hollenbeck Expires 19 December 2025 [Page 5] RFC 7451 EPP Extension Registry June 2025 TLDs: "Any"| IPR Disclosure: "None"| Status: "Active"|"Inactive" Notes: "None"| -----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, 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: Informational Reference: http://www.example.com/html/example-epp-ext.txt Registrant Name and Email Address: John Doe, jdoe@example.com TLDs: .example Hollenbeck Expires 19 December 2025 [Page 6] RFC 7451 EPP Extension Registry June 2025 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 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). At no time can a record be deleted from the registry. 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 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) Hollenbeck Expires 19 December 2025 [Page 7] RFC 7451 EPP Extension Registry June 2025 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: -----BEGIN FORM----- Name of Extension: "Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)" Document Status: Standards Track Reference: RFC 3915 Registrant Name and Email Address: IESG, TLDs: Any IPR Disclosure: None Status: Active Notes: None -----END FORM----- -----BEGIN FORM----- Name of Extension: "E.164 Number Mapping for the Extensible Provisioning Protocol (EPP)" Document Status: Standards Track Reference: RFC 4114 Hollenbeck Expires 19 December 2025 [Page 8] RFC 7451 EPP Extension Registry June 2025 Registrant Name and Email Address: IESG, TLDs: Any IPR Disclosure: None Status: Active Notes: None -----END FORM----- -----BEGIN FORM----- Name of Extension: "ENUM Validation Information Mapping for the Extensible Provisioning Protocol" Document Status: Standards Track Reference: RFC 5076 Registrant Name and Email Address: IESG, TLDs: Any IPR Disclosure: None Status: Active Notes: None -----END FORM----- -----BEGIN FORM----- Name of Extension: "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)" Document Status: Standards Track Reference: RFC 5910 Registrant Name and Email Address: IESG, TLDs: Any IPR Disclosure: None Status: Active Hollenbeck Expires 19 December 2025 [Page 9] RFC 7451 EPP Extension Registry June 2025 Notes: None -----END FORM----- In addition, the form used to populate and manage the registry will be added to the table of Protocol Registration Forms maintained by IANA. 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 5.1. Normative References [RFC3979] Bradner, S., Ed., "Intellectual Property Rights in IETF Technology", RFC 3979, DOI 10.17487/RFC3979, March 2005, . [RFC4879] Narten, T., "Clarification of the Third Party Disclosure Procedure in RFC 3979", RFC 4879, DOI 10.17487/RFC4879, April 2007, . [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, . [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, . [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, . 5.2. Informative References [RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible Provisioning Protocol (EPP)", RFC 3735, DOI 10.17487/RFC3735, March 2004, . Hollenbeck Expires 19 December 2025 [Page 10] RFC 7451 EPP Extension Registry June 2025 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. Change Log This section is to be removed before publishing as an RFC. -00: Initial version ported from RFC 7451. Changed "eppext" to "regext" throughout to update the name of the mailing list used for review discussion and information. Added text noting reviewer responsibility to confirm correctness of URIs used in extension registration requests. Updated references to RFC 5226 to cite 8126 instead; updated 8126 section numbers. 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 19 December 2025 [Page 11]