doc: Add RFC documents

1 files changed, 283 insertions, 0 deletions

diff --git a/doc/rfc/rfc5719.txt b/doc/rfc/rfc5719.txt
new file mode 100644
index 0000000..7a0cc86
--- /dev/null
+++ b/doc/rfc/rfc5719.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                      D. Romascanu
+Request for Comments: 5719                                         Avaya
+Updates: 3588                                              H. Tschofenig
+Category: Standards Track                         Nokia Siemens Networks
+ISSN: 2070-1721                                             January 2010
+
+
+   Updated IANA Considerations for Diameter Command Code Allocations
+
+Abstract
+
+   The Diameter base specification, described in RFC 3588, provides a
+   number of ways to extend Diameter, with new Diameter commands (i.e.,
+   messages used by Diameter applications) and applications as the most
+   extensive enhancements.  RFC 3588 illustrates the conditions that
+   lead to the need to define a new Diameter application or a new
+   command code.  Depending on the scope of the Diameter extension, IETF
+   actions are necessary.  Although defining new Diameter applications
+   does not require IETF consensus, defining new Diameter commands
+   requires IETF consensus per RFC 3588.  This has led to questionable
+   design decisions by other Standards Development Organizations, which
+   chose to define new applications on existing commands -- rather than
+   asking for assignment of new command codes -- for the pure purpose of
+   avoiding bringing their specifications to the IETF.  In some cases,
+   interoperability problems were an effect of the poor design caused by
+   overloading existing commands.
+
+   This document aligns the extensibility rules of the Diameter
+   application with the Diameter commands, offering ways to delegate
+   work on Diameter to other SDOs to extend Diameter in a way that does
+   not lead to poor design choices.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   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).  Further information on
+   Internet Standards is available in 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/rfc5719.
+
+
+
+
+
+
+Romascanu & Tschofenig      Standards Track                     [Page 1]
+
+RFC 5719        Diameter Command Code Allocation Policy     January 2010
+
+
+Copyright Notice
+
+   Copyright (c) 2010 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.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
+   2.  Conventions Used in This Document . . . . . . . . . . . . . . . 3
+   3.  Security Considerations . . . . . . . . . . . . . . . . . . . . 3
+   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3
+   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 4
+   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 4
+     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 5
+
+1.  Introduction
+
+   The Diameter Base specification, described in [RFC3588], provides a
+   number of ways to extend Diameter, with new Diameter commands (i.e.,
+   messages used by Diameter applications) and applications as the most
+   extensive enhancements.  [RFC3588] illustrates the conditions that
+   require the definition of a new Diameter application or a new
+   command.  Depending on the scope of the Diameter extension, IETF
+   actions are necessary.  Although defining new Diameter applications
+   does not require IETF consensus, defining new Diameter commands
+   requires IETF consensus per RFC 3588.  This has led to questionable
+   design decisions by other Standards Development Organizations (SDOs),
+   which chose to define new applications on existing commands -- rather
+   than asking for assignment of new command codes -- for the pure
+   purpose of avoiding bringing their specifications to the IETF.  In
+   some cases, interoperability problems were an effect of poor the
+   design caused by overloading existing commands.
+
+   This document aligns the extensibility rules for Diameter command
+   codes with those defined for Diameter application identifiers and
+   offers a consistent way to delegate work on Diameter to other SDOs to
+   extend Diameter in a way that does not lead to poor design choices.
+
+
+
+Romascanu & Tschofenig      Standards Track                     [Page 2]
+
+RFC 5719        Diameter Command Code Allocation Policy     January 2010
+
+
+   This is achieved by splitting the command code space into ranges and
+   providing different allocation policies to them: the first range is
+   reserved for RADIUS backward compatibility, allocation of a command
+   code in the second number range requires IETF review, the third range
+   is utilized by vendor-specific command codes, and finally the last
+   range is for experimental commands.  Section 4 provides more details
+   about the command code number ranges, and the different allocation
+   policies are described in [RFC5226].
+
+   A revision of RFC 3588 is currently in development in the IETF DIME
+   WG [RFC3588bis]; when approved, it will obsolete RFC 3588 as well as
+   this document.  A goal of this document is to provide in advance the
+   change in the command codes allocation policy, so that
+   interoperability problems like the ones described above are avoided
+   as soon as possible.
+
+2.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+3.  Security Considerations
+
+   This document modifies the IANA allocation of Diameter command codes
+   in relationship to RFC 3588.  This process change itself does not
+   raise security concerns, but the command code space is split into a
+   standard command code space and a vendor-specific command code space,
+   the latter being allocated on a First Come, First Served basis by
+   IANA at the request of vendors or other standards organizations.
+   Whenever work gets delegated to organizations outside the IETF, there
+   is always the chance that security reviews will be conducted in
+   different manner and that the criteria and style of those reviews
+   will be different than the reviews performed in the IETF.  The
+   members of the DIME working group are aware of the risks involved in
+   using different security and quality review processes and of the
+   desire to offload work (e.g., to reduce the workload in the IETF) to
+   other organizations.  Other organizations are therefore made
+   responsible for the quality of the specifications they produce.
+
+4.  IANA Considerations
+
+   This section describes changes to the IANA Considerations sections
+   outlined in RFC 3588 regarding the allocation of command codes by
+   IANA.
+
+   The command code namespace is used to identify Diameter commands.
+   The values 0 - 255 (0x00 - 0xff) are reserved for RADIUS backward
+
+
+
+Romascanu & Tschofenig      Standards Track                     [Page 3]
+
+RFC 5719        Diameter Command Code Allocation Policy     January 2010
+
+
+   compatibility and are defined as "RADIUS Packet Type Codes" in
+   [RADTYPE].  Values 256 - 8,388,607 (0x100 - 0x7fffff) are for
+   permanent, standard commands allocated by IETF Review [RFC5226].
+   [RFC3588] defines the command codes 257, 258, 271, 274, 275, 280, and
+   282; see Section 3.1 in [RFC3588] for the assignment of the namespace
+   in that specification.
+
+   The values 8,388,608 - 16,777,213 (0x800000 - 0xfffffd) are reserved
+   for vendor-specific command codes, to be allocated on a First Come,
+   First Served basis by IANA [RFC5226].  The request to IANA for a
+   vendor-specific command code SHOULD include a reference to a publicly
+   available specification that documents the command in sufficient
+   detail to aid in interoperability between independent
+   implementations.  If the specification cannot be made publicly
+   available, the request for a vendor-specific command code MUST
+   include the contact information of persons and/or entities
+   responsible for authoring and maintaining the command.
+
+   The values 16,777,214 and 16,777,215 (hexadecimal values 0xfffffe -
+   0xffffff) are reserved for experimental commands.  As these codes are
+   only for experimental and testing purposes, no guarantee is made for
+   interoperability between Diameter peers using experimental commands,
+   as outlined in [RFC3692].
+
+5.  Acknowledgements
+
+   The content of this document is the result of the work in the IETF
+   Diameter Maintenance and Extensions (DIME) working group.  We would
+   therefore like to thank all the working group members who were
+   involved in that discussion.  While it appears to be a fairly small
+   change in the allocation policy, the effect on implementations is
+   rather dramatic.
+
+   We would like to thank Mark Jones for his review comments.
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3588]     Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and
+                 J. Arkko, "Diameter Base Protocol", RFC 3588,
+                 September 2003.
+
+   [RFC3692]     Narten, T., "Assigning Experimental and Testing Numbers
+                 Considered Useful", BCP 82, RFC 3692, January 2004.
+
+
+
+Romascanu & Tschofenig      Standards Track                     [Page 4]
+
+RFC 5719        Diameter Command Code Allocation Policy     January 2010
+
+
+   [RFC5226]     Narten, T. and H. Alvestrand, "Guidelines for Writing
+                 an IANA Considerations Section in RFCs", BCP 26,
+                 RFC 5226, May 2008.
+
+6.2.  Informative References
+
+   [RADTYPE]     IANA, "Radius Types", <http://www.iana.org>.
+
+   [RFC3588bis]  Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
+                 "Diameter Base Protocol", Work in Progress,
+                 September 2009.
+
+Authors' Addresses
+
+   Dan Romascanu
+   Avaya
+   Industrial Park Atidim, Bldg#3
+   Tel Aviv  61581
+   Israel
+
+   Phone: +972-3-645-8414
+   EMail: dromasca@avaya.com
+
+
+   Hannes Tschofenig
+   Nokia Siemens Networks
+   Linnoitustie 6
+   Espoo  02600
+   Finland
+
+   Phone: +358 (50) 4871445
+   EMail: Hannes.Tschofenig@gmx.net
+   URI:   http://www.tschofenig.priv.at
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Romascanu & Tschofenig      Standards Track                     [Page 5]
+