]> Verisign Labs

12061 Bluemont Way Reston VA 20190 United States of America sah@sahollenbeck.com shollenbeck@verisign.com https://www.verisignlabs.com/

The Extensible Provisioning Protocol (EPP) includes features to add functionality by extending the protocol. It does not, however, describe how those extensions are maintained. 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. If approved, this document obsoletes RFC 7451.

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 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 (or its future replacement). 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. RFC 7451 filled that gap by defining the Extensions for the Extensible Provisioning Protocol (EPP) IANA registry to help manage and coordinate the development of EPP extensions. This update was written to address issues that were identified with RFC 7451 over time. Refer to for more details.

Changes Since RFC 7451

• The intended status has been changed from Informational to Standards Track.
• The name of the mailing list used to review and discuss registration requests was changed from "eppext" to "regext" throughout the document.
• has been updated to note that Internet-Draft documents are not acceptable specifications for this registry.
• has been updated to describe Designated Expert responsibility to confirm correctness of URIs used in extension registration requests, and that IETF namespaces MUST be reserved for specifications published in the IETF Stream.
• has been updated by adding "Other" to the set of document status values for the registry to avoid confusion with "Informational" RFCs and removing use of "Informational" for proprietary extensions. This document includes instructions for IANA to update existing registry entries appropriately.
• has been updated by changing "<registrant name>, <email address>" to "<name>, <address>" to meet right margin constraints.
• has been updated to note that registry entries can be removed with IESG approval.
• (Operational Considerations) has been added.

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

Extension Specification and Registration Procedure This section describes the format of the Extensions for the Extensible Provisioning Protocol (EPP) IANA registry and the procedures used to populate and manage registry entries.

Extension Specification This registry uses the "Specification Required" policy described in RFC 8126 . An English language version of the extension specification MUST be referenced from the registry, though non- English versions of the specification may also be provided. Note that Section 2.1 of RFC 3735 (or its future replacement) provides specific guidelines for documenting EPP extensions. The "Specification Required" policy requires review by a designated expert. Section 5 of describes the role of designated experts and the function they perform. For this registry, acceptable specifications include RFC documents and proprietary specifications that meet the "permanent and readily available" requirement described in Section 4.6 of . Internet-Draft documents are not acceptable specifications for this registry.

Designated Expert Evaluation Criteria A high-level description of the role of the designated expert is described in Section 5.2 of RFC 8126 . Specific guidelines for the appointment of designated experts and the evaluation of EPP extensions are provided here. The IESG should appoint a primary designated expert and a small number of individuals (perhaps 3 - 5) to serve as backup designated experts as described in Section 5.2 of . The primary designated expert is responsible for conducting all reviews requested by IANA. The secondary designated experts are responsible for conducting reviews as a consensus-based group if the primary designated expert is unavailable. In cases where a registration decision could be perceived as creating a conflict of interest for a particular Designated Expert, that Expert SHOULD defer to the judgment of the other Experts. 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 (or its future replacement, 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 schemas, XML schema URIs, and XML namespace URIs defined in the extension specification MUST be registered in the IETF XML Registry using the procedures described in RFC 3688 . IETF namespaces MUST be reserved for specifications published in the IETF Stream. 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 or its successor. 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 or its successor. 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.

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.

Required Information Name of Extension: A case-insensitive, ASCII text string that contains the name of the extension specification and does not overlap with an existing registered extension. 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 . For documents that are not RFCs, this will always be "Other". Reference: A permanent, publicly available reference to the specification of this extension as described in . Registrant Name and Email Address: The name and email address of the entity that is responsible for managing the registry entry. If the extension is registered by an IETF stream RFC, this can simply be listed as "IETF, <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 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. 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 BCP 79 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 . Notes: Either "None" or other text that describes optional notes to be included with the registered extension. If the Status value is being changed, text MUST be included to describe the rationale for the status change.

Registration Form The required information MUST be provided using the following registration form. Form field names and values MAY appear on the same line. (quotes are optional) Document Status: Reference: Registrant Name and Email Address: ,

TLDs: "Any"|"N/A"| 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: IETF, 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----- ]]>

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). IESG Approval (Section 4.10 of ) is REQUIRED to remove or deactivate registrations created through IETF consensus. Registrations not created through IETF consensus can be removed or deactivated with the approval of the IESG, in consultation with or at the request of the Designated Experts. Registrations not created through IETF consensus can also be removed or deactivated by the original registrant, in consultation with the Designated Experts. On receipt of a registration request, IANA will initiate review by the designated expert(s), who will evaluate the request using the criteria in in consultation with the current working group mailing list focused on the development of EPP extensions if such working group exists.

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, a 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.

IANA Considerations IANA has created the "Extensions for the Extensible Provisioning Protocol (EPP)" registry to manage EPP extensions, described in . This document requests IANA to replace the reference of the EPP registry from RFC 7451 to the RFC number to be assigned to this document. This document also requests IANA to update "Document Status" of all non-RFC documents from "Informational" to "Other".

Security Considerations This document introduces no new security considerations to EPP. However, extensions should be evaluated according to the Security Considerations of RFC 3735 (or its future replacement) and STD 69 .

Operational Considerations The updates defined in this document are meant to enhance the guidance for reviewing EPP extensions (e.g., avoid non-IETF specifications squatting on IETF XML namespaces) and thus allows for better interoperability. includes provisions for modifying and deleting existing registration entries by registrants. Such requests MUST NOT be granted if the requested action has operational implication on other entities that deploy that extension, assuming that those entities can be identified. This guidance can be overridden if the requested action MUST be taken to comply with actions that are beyond the control of the experts and/or IANA, e.g., to comply with legal actions. Note that the registry does not include a history mechanism and there is no way to track deleted entries once they have been removed. updates the content of "Document Status" to be compliant with the guidance in . That update does not impact the extension itself. No operational issues are induced by that update.

&BCP79; &STD69; &RFC2026; &RFC2119; &RFC3688; &RFC3735; &RFC5890; &RFC8126; &RFC8174; &RFC7451; Internet Assigned Numbers Authority

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.

Change Log

-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 . Added DEACTIVATE and REMOVE request processing to . Clarified use of IETF namespaces and "work in progress" specifications in . Clarified status values in . Updated acknowledgements.

-02:

Changed intended status from Informational to BCP. Added text to address Independent Submission stream RFCs to . Noted that the value of the TLDs field () can be "N/A". Added text to to ensure that it's consistent with . Updated examples to use "https" instead of "http". Updated acknowledgements.

-03:

Updated to use BCP 14 keywords. Updated and to clarify ISE RFC use as a reference specification for an extension.

-04:

Second WG last call edits: Updated "XML schemas, XML schema URIs, and XML namespace URIs" wording in . Noted that the value of "TLDs" can be "N/A" in . Updated "removed or deactivated" wording in . Changed RFC 3735 from an informative reference to a normative reference. Changed "IESG" to "IETF" in the "Registrant Name and Email Address" description in and the example registration template in . Updated obsolete normative references to RFCs 3979 and 4879 (obsoleted by RFC 8179/BCP 79).

-05:

Post-WG last call edits: changed "should not" to "SHOULD NOT" in the last sentence of . Changed "RFC 5730" to "STD 69" in and added "STD 69" to .

-06:

Shepherd write-up edit: Added "If approved" sentence to the Abstract.

-07:

AD review edits.