doc: Add RFC documents

1 files changed, 227 insertions, 0 deletions

diff --git a/doc/rfc/rfc3818.txt b/doc/rfc/rfc3818.txt
new file mode 100644
index 0000000..cfc98dd
--- /dev/null
+++ b/doc/rfc/rfc3818.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+Network Working Group                                        V. Schryver
+Request for Comments: 3818                             Rhyolite Software
+BCP: 88                                                        June 2004
+Category: Best Current Practice
+
+
+       IANA Considerations for the Point-to-Point Protocol (PPP)
+
+Status of this Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   The charter of the Point-to-Point Protocol (PPP) Extensions working
+   group (pppext) includes the responsibility to "actively advance PPP's
+   most useful extensions to full standard, while defending against
+   further enhancements of questionable value."  In support of that
+   charter, the allocation of PPP protocol and other assigned numbers
+   will no longer be "first come first served."
+
+Introduction
+
+   The Point-to-Point protocol (PPP, RFC 1661 [1]) is a mature protocol
+   with a large number of subprotocols, encapsulations and other
+   extensions.  The main protocol as well as its extensions involve many
+   name spaces in which values must be assigned.
+   http://www.iana.org/assignments/ppp-numbers contains a list of the
+   address spaces and their current assignments.
+
+   Historically, initial values in new name spaces have often been
+   chosen in the RFCs creating the name spaces.  The IANA made
+   subsequent assignments with a "First Come First Served" policy.  This
+   memo changes that policy for some PPP address spaces.
+
+   Most of the PPP names spaces are quiescent, but some continue to
+   attract proposed extensions.  Extensions of PPP have been defined in
+   RFCs that are "Informational" and so are not subject to review.
+   These extensions usually require values assigned in one or more of
+   the PPP name spaces.  Making these allocations require "IETF
+   Consensus" will ensure that proposals are reviewed.
+
+
+
+
+Schryver                 Best Current Practice                  [Page 1]
+
+RFC 3818              IANA Considerations for PPP              June 2004
+
+
+Terminology
+
+   The terms "name space", "assigned value", and "registration" are used
+   here with the meanings defined in BCP 26 [2].  The policies "First
+   Come First Served" and "IETF Consensus" used here also have the
+   meanings defined in BCP 26.
+
+IANA Considerations for PPP
+
+   IETF Consensus, usually through the Point-to-Point Protocol
+   Extensions working group (pppext), is required for assigning new
+   values in the following address spaces:
+
+                PPP DLL PROTOCOL NUMBERS
+                PPP LCP AND IPCP CODES
+                PPP LCP CONFIGURATION OPTION TYPES
+                PPP CCP CONFIGURATION OPTION TYPES
+                PPP CHAP AUTHENTICATION ALGORITHMS
+                PPP LCP FCS-ALTERNATIVES
+                PPP MULTILINK ENDPOINT DISCRIMINATOR CLASS
+                PPP LCP CALLBACK OPERATION FIELDS
+                PPP BRIDGING CONFIGURATION OPTION TYPES
+                PPP BRIDGING MAC TYPES
+                PPP BRIDGING SPANNING TREE
+                PPP IPCP CONFIGURATION OPTION TYPES
+                PPP IPV6CP CONFIGURATION OPTIONS
+                PPP IP-Compression-Protocol Types
+
+Security Considerations
+
+   This memo deals with matters of process, not protocol.
+
+Normative References
+
+   [1] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51,
+       RFC 1661, July 1994.
+
+   [2] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
+       Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+
+
+
+
+
+
+
+
+
+
+
+Schryver                 Best Current Practice                  [Page 2]
+
+RFC 3818              IANA Considerations for PPP              June 2004
+
+
+Author's Address
+
+   Vernon Schryver
+   Rhyolite Software
+   2482 Lee Hill Drive
+   Boulder, Colorado 80302
+
+   EMail: vjs@rhyolite.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schryver                 Best Current Practice                  [Page 3]
+
+RFC 3818              IANA Considerations for PPP              June 2004
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+Schryver                 Best Current Practice                  [Page 4]
+