dime D. Romascanu Internet-Draft Avaya Updates: rfc3588 H. Tschofenig (if approved) Nokia Siemens Networks Intended status: Standards Track June 3, 2009 Expires: December 5, 2009 Updated IANA Considerations for Diameter Command Code Allocations draft-ietf-dime-diameter-cmd-iana-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 5, 2009. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Romascanu & Tschofenig Expires December 5, 2009 [Page 1]
Internet-Draft Diameter Command Code Allocation Policy June 2009 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 lead 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 causes as an effect of the poor design caused by overloading existing commands. This document aligns the extensibility rules of 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. Romascanu & Tschofenig Expires December 5, 2009 [Page 2]
Internet-Draft Diameter Command Code Allocation Policy June 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions used in this document . . . . . . . . . . . . . . 5 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Romascanu & Tschofenig Expires December 5, 2009 [Page 3]
Internet-Draft Diameter Command Code Allocation Policy June 2009 1. Introduction The Diameter Base specification, described in RFC 3588 [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. 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 lead 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 causes as an effect of the poor design caused by overloading existing commands. This document aligns the extensibility rules of 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. This is achieved by splitting the command code space into an IANA administered code space, and a vendors-specific code space with different rules of allocation as per [RFC5226]. A revision of RFC 3588 is currently in development in the IETF DIME WG [I-D.ietf-dime-rfc3588bis]. and when approved will obsolete RFC 3588 as well as this document. This document has as a goal providing in advance the change in the command codes allocation policy, so that interoperability problems as the ones described above are avoided as soon as possible. Romascanu & Tschofenig Expires December 5, 2009 [Page 4]
Internet-Draft Diameter Command Code Allocation Policy June 2009 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]. Romascanu & Tschofenig Expires December 5, 2009 [Page 5]
Internet-Draft Diameter Command Code Allocation Policy June 2009 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 codes space is split into a standards commands space and a vendor-specific command codes space, the later 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 fewer security reviews are conducted and hence the quality of the resulting protocol document is weaker compared to the rather extensive reviews performed in the IETF. The members of the DIME working group are aware of the tradeoff between better specification quality and 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. Romascanu & Tschofenig Expires December 5, 2009 [Page 6]
Internet-Draft Diameter Command Code Allocation Policy June 2009 4. IANA Considerations This section describes changes to the IANA consideration 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 compatibility, and are defined as "RADIUS Packet Type Codes" in [RADTYPE]. Values 256 - 8,388,607 (0x100 to 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 this 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 which 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]. Romascanu & Tschofenig Expires December 5, 2009 [Page 7]
Internet-Draft Diameter Command Code Allocation Policy June 2009 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. Romascanu & Tschofenig Expires December 5, 2009 [Page 8]
Internet-Draft Diameter Command Code Allocation Policy June 2009 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. [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 [I-D.ietf-dime-rfc3588bis] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", draft-ietf-dime-rfc3588bis-17 (work in progress), May 2009. [RADTYPE] "IANA, RADIUS Types, http://www.iana.org/assignments/radius-types". Romascanu & Tschofenig Expires December 5, 2009 [Page 9]
Internet-Draft Diameter Command Code Allocation Policy June 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 Expires December 5, 2009 [Page 10]
