From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001
From: Thomas Voss <mail@thomasvoss.com>
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, <iesg@ietf.org>".
+
+
+
+
+
+
+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:
+ <text string> (quotes are optional)
+
+ Document Status: <document status>
+
+ Reference: <RFC number, URL, etc.>
+
+ Registrant Name and Email Address:
+ <registrant name>, <email 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 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, <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:
+ 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 <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). 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, <iesg@ietf.org>
+
+ 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, <iesg@ietf.org>
+
+ 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, <iesg@ietf.org>
+
+ 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, <iesg@ietf.org>
+
+ 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,
+ <http://www.rfc-editor.org/info/rfc3979>.
+
+ [RFC4879] Narten, T., "Clarification of the Third Party Disclosure
+ Procedure in RFC 3979", BCP 79, RFC 4879, April 2007,
+ <http://www.rfc-editor.org/info/rfc4879>.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ May 2008, <http://www.rfc-editor.org/info/rfc5226>.
+
+
+
+Hollenbeck Informational [Page 11]
+
+RFC 7451 EPP Extension Registry February 2015
+
+
+ [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
+ STD 69, RFC 5730, August 2009,
+ <http://www.rfc-editor.org/info/rfc5730>.
+
+ [RFC5890] Klensin, J., "Internationalized Domain Names for
+ Applications (IDNA): Definitions and Document Framework",
+ RFC 5890, August 2010,
+ <http://www.rfc-editor.org/info/rfc5890>.
+
+5.2. Informative References
+
+ [RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible
+ Provisioning Protocol (EPP)", RFC 3735, March 2004,
+ <http://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.
+
+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