doc: Add RFC documents

1 files changed, 283 insertions, 0 deletions

diff --git a/doc/rfc/rfc5237.txt b/doc/rfc/rfc5237.txt
new file mode 100644
index 0000000..97984ff
--- /dev/null
+++ b/doc/rfc/rfc5237.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                           J. Arkko
+Request for Comments: 5237                                      Ericsson
+BCP: 37                                                       S. Bradner
+Updates: 2780                                         Harvard University
+Category: Best Current Practice                            February 2008
+
+
+           IANA Allocation Guidelines for the Protocol Field
+
+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.
+
+Abstract
+
+   This document revises the IANA guidelines for allocating new Protocol
+   field values in IPv4 header.  It modifies the rules specified in RFC
+   2780 by removing the Expert Review option.  The change will also
+   affect the allocation of Next Header field values in IPv6.
+
+1.  Introduction
+
+   This document revises the IANA guidelines [RFC2780] for allocating
+   new Protocol field values in IPv4 header [RFC0791].  The change will
+   also be applicable for IPv6, as the IANA guidelines for IPv6 Next
+   Header values [RFC2460] allocation refer to the IPv4 guidelines.
+
+   Previously, RFC 2780 allowed such allocations to happen through IESG
+   Approval, Standards action, or Expert Review processes
+   [RFC2780][RFC2434].  The Expert Review process was specified to be
+   used only in the case where a non-disclosure agreement was involved:
+
+      IANA allocates values from the IPv4 Protocol name space following
+      an Expert Review, IESG Approval or Standards Action process.  The
+      Expert Review process should only be used in those special cases
+      where non-disclosure information is involved.  In these cases the
+      expert(s) should be designated by the IESG.
+
+   The need for the Standards Action rule is obvious as the IETF keeps
+   developing new protocols.  It is equally obvious that there is a need
+   to allow experimental allocations in this space; see RFC 4727
+   [RFC4727] for an example.  Similarly, there are cases when it makes
+   sense to allocate values out of this space for other non-Standards
+   Track or non-IETF uses.  However, the size of the field is 256
+   values, and 55% of these were in use at the time this document was
+   written.  As a result, a sanity check is needed to ensure that
+
+
+
+Arkko & Bradner          Best Current Practice                  [Page 1]
+
+RFC 5237               Protocol Field IANA Rules           February 2008
+
+
+   allocations are not made needlessly.  RFC 2780 specifies the IESG
+   Approval rule to take care of these sanity checks for the non-
+   Standards Track cases.  The judgment call can take into account the
+   existence of a stable protocol specification, constituency that wants
+   to use it, need to avoid duplicated allocations for the same purpose,
+   whether protocol number allocation is the right solution for this
+   problem as opposed to, say, a TCP port, and so on.
+
+   However, we now believe that the non-disclosure agreement option is
+   not appropriate for allocations in this space.  Traditionally, non-
+   disclosure agreements have been used by the IANA when a company was
+   developing a proprietary protocol and did not want to disclose new
+   areas of research or future products.  The protocol space is limited
+   enough that we no longer believe that it is reasonable to use the
+   resource for such proprietary protocols.  Thus, we believe that
+   allocations should only be made using the IESG Approval or Standards
+   Action processes when there are public specifications that can be
+   reviewed.
+
+   As a result, this document revises the RFC 2780 rules by removing the
+   option for Expert Review for the IPv4 Protocol and IPv6 Next Header
+   fields.  This document takes no position on the allocation of other
+   parameters with non-disclosure agreements, as those parameters may
+   require different policies.
+
+2.  IANA Considerations
+
+   This document replaces the RFC 2780 Section 4.3 rule [RFC2780] with
+   the following:
+
+      IANA allocates values from the IPv4 Protocol name space following
+      an IESG Approval or Standards Action process.
+
+   This document also makes an implicit change to the rule for the IPv6
+   Next Header field in Section 5.3 of RFC 2780.  That rule refers to
+   the rule in Section 4.3 of the same RFC.  From now on, this reference
+   should be understood to refer to the rule revised here, i.e., without
+   the Expert Review option.
+
+3.  Security Considerations
+
+   This specification does not change the security properties of the
+   affected protocols.
+
+
+
+
+
+
+
+
+Arkko & Bradner          Best Current Practice                  [Page 2]
+
+RFC 5237               Protocol Field IANA Rules           February 2008
+
+
+4.  Acknowledgments
+
+   Issues with the original RFC 2780 rules were uncovered in discussions
+   of the IETF-IANA team.  The team also provided background information
+   on the practical difficulties encountered with non-disclosure
+   agreements.  The authors would like to thank Thomas Narten, Bill
+   Fenner, and Michelle Cotton in particular.
+
+5.  References
+
+5.1.  Normative References
+
+   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
+              September 1981.
+
+   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+              October 1998.
+
+   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
+              (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC2780]  Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
+              Values In the Internet Protocol and Related Headers",
+              BCP 37, RFC 2780, March 2000.
+
+5.2.  Informative References
+
+   [RFC4727]  Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
+              ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arkko & Bradner          Best Current Practice                  [Page 3]
+
+RFC 5237               Protocol Field IANA Rules           February 2008
+
+
+Appendix A.  Changes from RFC 2780
+
+   Section 4.3 from RFC 2780 has been changed from:
+
+      IANA allocates values from the IPv4 Protocol name space following
+      an Expert Review, IESG Approval or Standards Action process.  The
+      Expert Review process should only be used in those special cases
+      where non-disclosure information is involved.  In these cases the
+      expert(s) should be designated by the IESG.
+
+   to:
+
+      IANA allocates values from the IPv4 Protocol name space following
+      an IESG Approval or Standards Action process.
+
+   In addition, RFC 2780 Section 5.3 reference to IPv4 rules should be
+   understood to refer to the rule revised here, i.e., without the
+   Expert Review option.
+
+Authors' Addresses
+
+   Jari Arkko
+   Ericsson
+   Jorvas  02420
+   Finland
+
+   EMail: jari.arkko@piuha.net
+
+
+   Scott Bradner
+   Harvard University
+   Cambridge, MA  02138
+   US
+
+   Phone: +1 617 495 3864
+   EMail: sob@harvard.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arkko & Bradner          Best Current Practice                  [Page 4]
+
+RFC 5237               Protocol Field IANA Rules           February 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   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, THE IETF TRUST 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Arkko & Bradner          Best Current Practice                  [Page 5]
+