doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

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]
+