doc: Add RFC documents

1 files changed, 254 insertions, 0 deletions

diff --git a/doc/rfc/rfc9121.txt b/doc/rfc/rfc9121.txt
new file mode 100644
index 0000000..a72c925
--- /dev/null
+++ b/doc/rfc/rfc9121.txt
@@ -0,0 +1,254 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                         K. Davies
+Request for Comments: 9121                                      A. Baber
+Obsoletes: 1528                                                     IANA
+Updates: 1706                                                 April 2023
+Category: Informational                                                 
+ISSN: 2070-1721
+
+
+                Deprecating Infrastructure "int" Domains
+
+Abstract
+
+   This document deprecates the use of any "int" domain names that were
+   designated for infrastructure purposes by the IETF, and it identifies
+   them for removal from the "int" top-level domain.  Any
+   implementations that involve these domains are now deprecated.  This
+   document also changes the status of RFC 1528 and RFC 1706 to
+   Historic.
+
+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 candidates for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9121.
+
+Copyright Notice
+
+   Copyright (c) 2023 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
+   (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.  Historical Infrastructural Uses
+     2.1.  atma.int
+     2.2.  ip4.int
+     2.3.  ip6.int
+     2.4.  nsap.int
+     2.5.  rdi.int
+     2.6.  reg.int
+     2.7.  tpc.int
+   3.  Updates to Other RFC Series Documents
+     3.1.  RFC 1528
+     3.2.  RFC 1706
+   4.  IANA Considerations
+   5.  Security Considerations
+   6.  Additional Information
+   7.  Informative References
+   Acknowledgments
+   Authors' Addresses
+
+1.  Introduction
+
+   The "int" top-level domain [RFC1591] is a specialized domain
+   designated for intergovernmental organizations, which are
+   organizations established by international treaties between or among
+   national governments.
+
+   Historically, the "int" domain was also used for purposes related to
+   Internet infrastructure.  This practice ended in 2001 when the "arpa"
+   domain was declared the appropriate home for infrastructural
+   identifier spaces [RFC3172].  In conjunction with this change, the
+   eligibility for "int" domains was limited to only intergovernmental
+   treaty organizations.
+
+   The documented uses of infrastructural identifiers in the "int"
+   domain were largely experimental and are now, in practice, obsolete.
+   This document changes the status of related specifications to
+   Historic, and it removes any associated delegations from the "int"
+   zone in the domain name system.
+
+2.  Historical Infrastructural Uses
+
+   The following domains were used for infrastructural identifier
+   purposes that are now considered historic.  Although each of these
+   names was either delegated or documented at one time, the parties
+   administering them have long since stopped using them.
+
+2.1.  atma.int
+
+   The atma.int domain was experimentally defined to implement address
+   lookups for Asynchronous Transfer Mode (ATM), including ATM End
+   System Addresses (AESAs) [ANS].
+
+2.2.  ip4.int
+
+   The ip4.int domain was described as providing an alternative to the
+   in-addr.arpa domain for mapping host IPv4 addresses to host names.
+   The in-addr.arpa domain zone continues to be administered for this
+   purpose [RFC1035].
+
+2.3.  ip6.int
+
+   The ip6.int domain was originally delegated for mapping host IPv6
+   addresses to host names.  It was subsequently removed from the "int"
+   zone, having been replaced by ip6.arpa [RFC4159].
+
+2.4.  nsap.int
+
+   The nsap.int domain name was specified to experimentally map Open
+   Systems Interconnection (OSI) Network Service Access Points to domain
+   names [RFC1706].
+
+2.5.  rdi.int
+
+   The rdi.int domain name experimentally mapped OSI Inter-Domain
+   Routing Protocol's Routing Domain Identifiers [ISO10747] to the
+   domain name system.
+
+2.6.  reg.int
+
+   The reg.int domain name hosted an experimental mechanism for
+   publishing IANA registration values in the domain name system.
+
+2.7.  tpc.int
+
+   The tpc.int domain name hosted an experimental remote printing
+   service that served as a gateway between Internet mail and facsimile
+   transmission [RFC1528].
+
+3.  Updates to Other RFC Series Documents
+
+3.1.  RFC 1528
+
+   The specification for tpc.int [RFC1528] is Historic, as it no longer
+   functions as described in the document.
+
+3.2.  RFC 1706
+
+   The specification for nsap.int [RFC1706] is Historic, as it no longer
+   functions as described in the document.
+
+4.  IANA Considerations
+
+   IANA has removed the historical "int" domains discussed in this
+   document.
+
+5.  Security Considerations
+
+   Some old systems might have one or more subdomains of these names
+   hardwired and expect a positive response for at least the second-
+   level domain.  This is, of course, true for any name in the DNS and
+   should not be the sole basis for retaining obsolete names.
+
+   Existing applications should eliminate any reliance upon these zones.
+   The operator of the "int" domain should be cautious about any
+   potential re-use of these domains for intergovernmental treaty
+   organizations.
+
+6.  Additional Information
+
+   This document is the result of a comprehensive inventory of .int
+   domains to accurately establish and record their purpose based on
+   historical documentation.  As part of this inventory, IANA studied
+   the domains delegated for purposes related to infrastructure
+   identifiers.  Query patterns in the DNS for these domains were
+   analyzed and judged to be insignificant; preliminary outreach to the
+   contacts for the associated domains was conducted.  The assessment
+   concluded that these domains are very likely obsolete.  This document
+   formalizes that assessment.
+
+   There are a small number of nominal "int" domains for "international
+   databases" that are not defined by any standards documentation.  They
+   are assigned to entities rather than for identifier purposes.  Their
+   dispositions are beyond the scope of this memo.
+
+7.  Informative References
+
+   [ANS]      The ATM Forum Technical Committee, "ATM Name System
+              Specification Version 1.0", ATM Forum af-saa-0069.000,
+              November 1996, <https://www.broadband-
+              forum.org/technical/download/af-saa-0069.000.pdf>.
+
+   [ISO10747] ISO/IEC, "Information technology - Telecommunications and
+              information exchange between systems - Protocol for
+              exchange of inter-domain routeing information among
+              intermediate systems to support forwarding of ISO 8473
+              PDUs", ISO/IEC 10747:1994, October 1994,
+              <https://www.iso.org/standard/21417.html>.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
+              November 1987, <https://www.rfc-editor.org/info/rfc1035>.
+
+   [RFC1528]  Malamud, C. and M. Rose, "Principles of Operation for the
+              TPC.INT Subdomain: Remote Printing -- Technical
+              Procedures", RFC 1528, DOI 10.17487/RFC1528, October 1993,
+              <https://www.rfc-editor.org/info/rfc1528>.
+
+   [RFC1591]  Postel, J., "Domain Name System Structure and Delegation",
+              RFC 1591, DOI 10.17487/RFC1591, March 1994,
+              <https://www.rfc-editor.org/info/rfc1591>.
+
+   [RFC1706]  Manning, B. and R. Colella, "DNS NSAP Resource Records",
+              RFC 1706, DOI 10.17487/RFC1706, October 1994,
+              <https://www.rfc-editor.org/info/rfc1706>.
+
+   [RFC3172]  Huston, G., Ed., "Management Guidelines & Operational
+              Requirements for the Address and Routing Parameter Area
+              Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172,
+              September 2001, <https://www.rfc-editor.org/info/rfc3172>.
+
+   [RFC4159]  Huston, G., "Deprecation of "ip6.int"", BCP 109, RFC 4159,
+              DOI 10.17487/RFC4159, August 2005,
+              <https://www.rfc-editor.org/info/rfc4159>.
+
+Acknowledgments
+
+   This document was compiled with help from Ted Hardie and Michelle
+   Cotton, with additional input from Jari Arkko, John Klensin, Warren
+   Kumari, Pete Resnick, George Michaelson, and Toerless Eckert.
+
+Authors' Addresses
+
+   Kim Davies
+   Internet Assigned Numbers Authority
+   PTI/ICANN
+   12025 Waterfront Drive
+   Los Angeles, CA 90094
+   United States of America
+   Email: kim.davies@iana.org
+
+
+   Amanda Baber
+   Internet Assigned Numbers Authority
+   PTI/ICANN
+   12025 Waterfront Drive
+   Los Angeles, CA 90094
+   United States of America
+   Email: amanda.baber@iana.org