From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7451.txt | 675 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 675 insertions(+) create mode 100644 doc/rfc/rfc7451.txt (limited to 'doc/rfc/rfc7451.txt') diff --git a/doc/rfc/rfc7451.txt b/doc/rfc/rfc7451.txt new file mode 100644 index 0000000..34bd514 --- /dev/null +++ b/doc/rfc/rfc7451.txt @@ -0,0 +1,675 @@ + + + + + + +Internet Engineering Task Force (IETF) S. Hollenbeck +Request for Comments: 7451 Verisign Labs +Category: Informational February 2015 +ISSN: 2070-1721 + + + Extension Registry for the Extensible Provisioning Protocol + +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 document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7451. + +Copyright Notice + + Copyright (c) 2015 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://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 Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + +Hollenbeck Informational [Page 1] + +RFC 7451 EPP Extension Registry February 2015 + + +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 . . . . . . . . . . . . . . . . . . 6 + 2.2.3. Registration Processing . . . . . . . . . . . . . . . 8 + 2.2.4. Updating Registry Entries . . . . . . . . . . . . . . 8 + 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 5.1. Normative References . . . . . . . . . . . . . . . . . . 11 + 5.2. Informative References . . . . . . . . . . . . . . . . . 12 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 + + +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. + + 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. + + + + + + + + + +Hollenbeck Informational [Page 2] + +RFC 7451 EPP Extension Registry February 2015 + + +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 5226 [RFC5226]. 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 3 of RFC 5226 [RFC5226] 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 3.2 of RFC 5226 [RFC5226]. 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 3.2 of RFC + 5226 [RFC5226]. The pool should have a single administrative chair + who is appointed by the IESG. The designated experts should use the + existing eppext mailing list (eppext@ietf.org) for public discussion + of registration requests. This implies that the mailing list should + remain open after the work of the EPPEXT working group has concluded. + + 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). + + The results of the evaluation should be shared via email with the + registrant and the eppext 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 + + + + +Hollenbeck Informational [Page 3] + +RFC 7451 EPP Extension Registry February 2015 + + + eppext 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. + + 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, ". + + + + + + +Hollenbeck Informational [Page 4] + +RFC 7451 EPP Extension Registry February 2015 + + + 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 Informational [Page 5] + +RFC 7451 EPP Extension Registry February 2015 + + +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: + , + + TLDs: "Any"| + + IPR Disclosure: "None"| + + Status: "Active"|"Inactive" + + Notes: "None"| + -----END FORM----- + + + + + + + + + + + + + + + + + + + + + + + + + + +Hollenbeck Informational [Page 6] + +RFC 7451 EPP Extension Registry February 2015 + + + 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 + + IPR Disclosure: + http://www.example.com/ipr/example-epp-ext-ipr.html + + Status: Active + + Notes: None + -----END FORM----- + + + +Hollenbeck Informational [Page 7] + +RFC 7451 EPP Extension Registry February 2015 + + +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 eppext 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) + + 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 + + + +Hollenbeck Informational [Page 8] + +RFC 7451 EPP Extension Registry February 2015 + + + Required information: See Section 2.2.1. + + Review process: "Specification Required" as described in RFC 5226 + [RFC5226]. + + 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----- + + + + + + + + + + + + + + + + + + + + +Hollenbeck Informational [Page 9] + +RFC 7451 EPP Extension Registry February 2015 + + + -----BEGIN FORM----- + Name of Extension: + "E.164 Number Mapping for the + Extensible Provisioning Protocol (EPP)" + + Document Status: + Standards Track + + Reference: + RFC 4114 + + 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----- + + + + + + +Hollenbeck Informational [Page 10] + +RFC 7451 EPP Extension Registry February 2015 + + + -----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 + + 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., "Intellectual Property Rights in IETF + Technology", BCP 79, RFC 3979, March 2005, + . + + [RFC4879] Narten, T., "Clarification of the Third Party Disclosure + Procedure in RFC 3979", BCP 79, RFC 4879, April 2007, + . + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008, . + + + +Hollenbeck Informational [Page 11] + +RFC 7451 EPP Extension Registry February 2015 + + + [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", + STD 69, RFC 5730, August 2009, + . + + [RFC5890] Klensin, J., "Internationalized Domain Names for + Applications (IDNA): Definitions and Document Framework", + RFC 5890, August 2010, + . + +5.2. Informative References + + [RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible + Provisioning Protocol (EPP)", RFC 3735, March 2004, + . + +Acknowledgements + + The information described in the registry is based on a suggestion + posted to the provreg mailing list by Jay Daley in August 2013. + +Author's Address + + Scott Hollenbeck + Verisign Labs + 12061 Bluemont Way + Reston, VA 20190 + US + + EMail: shollenbeck@verisign.com + URI: http://www.verisignlabs.com/ + + + + + + + + + + + + + + + + + + + + + +Hollenbeck Informational [Page 12] + -- cgit v1.2.3