draft-ietf-dime-diameter-cmd-iana-01.txt   rfc5719.txt 
dime D. Romascanu Internet Engineering Task Force (IETF) D. Romascanu
Internet-Draft Avaya Request for Comments: 5719 Avaya
Updates: rfc3588 H. Tschofenig Updates: 3588 H. Tschofenig
(if approved) Nokia Siemens Networks Category: Standards Track Nokia Siemens Networks
Intended status: Standards Track July 13, 2009 ISSN: 2070-1721 January 2010
Expires: January 14, 2010
Updated IANA Considerations for Diameter Command Code Allocations Updated IANA Considerations for Diameter Command Code Allocations
draft-ietf-dime-diameter-cmd-iana-01.txt
Status of this Memo Abstract
This Internet-Draft is submitted to IETF in full conformance with the The Diameter base specification, described in RFC 3588, provides a
provisions of BCP 78 and BCP 79. 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.
Internet-Drafts are working documents of the Internet Engineering This document aligns the extensibility rules of the Diameter
Task Force (IETF), its areas, and its working groups. Note that application with the Diameter commands, offering ways to delegate
other groups may also distribute working documents as Internet- work on Diameter to other SDOs to extend Diameter in a way that does
Drafts. not lead to poor design choices.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
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 This is an Internet Standards Track document.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (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.
This Internet-Draft will expire on January 14, 2010. 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.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
The Diameter Base specification, described in RFC 3588, provides a described in the Simplified BSD License.
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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 5 2. Conventions Used in This Document . . . . . . . . . . . . . . . 3
3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 3
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . . 4
6.2. Informative References . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
The Diameter Base specification, described in RFC 3588 [RFC3588], The Diameter Base specification, described in [RFC3588], provides a
provides a number of ways to extend Diameter, with new Diameter number of ways to extend Diameter, with new Diameter commands (i.e.,
commands, i.e. messages used by Diameter applications, and messages used by Diameter applications) and applications as the most
applications as the most extensive enhancements. RFC3588 illustrates extensive enhancements. [RFC3588] illustrates the conditions that
the conditions, which require the definition of a new Diameter require the definition of a new Diameter application or a new
application or a new command. Depending on the scope of the Diameter command. Depending on the scope of the Diameter extension, IETF
extension IETF actions are necessary. Although defining new Diameter actions are necessary. Although defining new Diameter applications
applications does not require IETF consensus, defining new Diameter does not require IETF consensus, defining new Diameter commands
commands requires IETF consensus per RFC 3588. This has lead to requires IETF consensus per RFC 3588. This has led to questionable
questionable design decisions by other Standards Development design decisions by other Standards Development Organizations (SDOs),
Organizations which chose to define new applications on existing which chose to define new applications on existing commands -- rather
commands rather than asking for assignment of new command codes for than asking for assignment of new command codes -- for the pure
the pure purpose of avoiding bringing their specifications to the purpose of avoiding bringing their specifications to the IETF. In
IETF. In some cases interoperability problems were causes as an some cases, interoperability problems were an effect of poor the
effect of the poor design caused by overloading existing commands. design caused by overloading existing commands.
This document aligns the extensibility rules for Diameter command This document aligns the extensibility rules for Diameter command
codes with those defined for Diameter application identifiers and codes with those defined for Diameter application identifiers and
offers a consistent way to delegate work on Diameter to other SDOs to 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. extend Diameter in a way that does not lead to poor design choices.
This is achieved by splitting the command code space into ranges and This is achieved by splitting the command code space into ranges and
providing different allocation policies to them: the first range is providing different allocation policies to them: the first range is
reserved for RADIUS backward compatibility, allocation of a command reserved for RADIUS backward compatibility, allocation of a command
code in the second number range requires IETF review, the third range code in the second number range requires IETF review, the third range
is utilized by vendor-specific command codes, and finally the last is utilized by vendor-specific command codes, and finally the last
range is for experimental commands. Section 4 provides more details range is for experimental commands. Section 4 provides more details
about the command code number ranges and the different allocation about the command code number ranges, and the different allocation
policies are described in [RFC5226]. policies are described in [RFC5226].
A revision of RFC 3588 is currently in development in the IETF DIME 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 WG [RFC3588bis]; when approved, it will obsolete RFC 3588 as well as
3588 as well as this document. This document has as a goal providing this document. A goal of this document is to provide in advance the
in advance the change in the command codes allocation policy, so that change in the command codes allocation policy, so that
interoperability problems as the ones described above are avoided as interoperability problems like the ones described above are avoided
soon as possible. as soon as possible.
2. Conventions used in this document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Security Considerations 3. Security Considerations
This document modifies the IANA allocation of Diameter Command Codes This document modifies the IANA allocation of Diameter command codes
in relationship to RFC 3588. This process change itself does not in relationship to RFC 3588. This process change itself does not
raise security concerns, but the command codes space is split into a raise security concerns, but the command code space is split into a
standards commands space and a vendor-specific command codes space, standard command code space and a vendor-specific command code space,
the later being allocated on a First Come, First Served basis by IANA the latter being allocated on a First Come, First Served basis by
at the request of vendors or other standards organizations. Whenever IANA at the request of vendors or other standards organizations.
work gets delegated to organizations outside the IETF there is always Whenever work gets delegated to organizations outside the IETF, there
the chance that fewer security reviews are conducted and hence the is always the chance that security reviews will be conducted in
quality of the resulting protocol document is weaker compared to the different manner and that the criteria and style of those reviews
rather extensive reviews performed in the IETF. The members of the will be different than the reviews performed in the IETF. The
DIME working group are aware of the tradeoff between better members of the DIME working group are aware of the risks involved in
specification quality and the desire to offload work (e.g., to reduce using different security and quality review processes and of the
the workload in the IETF) to other organizations. Other desire to offload work (e.g., to reduce the workload in the IETF) to
organizations are therefore made responsible for the quality of the other organizations. Other organizations are therefore made
specifications they produce. responsible for the quality of the specifications they produce.
4. IANA Considerations 4. IANA Considerations
This section describes changes to the IANA consideration sections This section describes changes to the IANA Considerations sections
outlined in RFC 3588 regarding the allocation of Command Codes by outlined in RFC 3588 regarding the allocation of command codes by
IANA. IANA.
The Command Code namespace is used to identify Diameter commands. The command code namespace is used to identify Diameter commands.
The values 0-255 (0x00-0xff) are reserved for RADIUS backward The values 0 - 255 (0x00 - 0xff) are reserved for RADIUS backward
compatibility, and are defined as "RADIUS Packet Type Codes" in compatibility and are defined as "RADIUS Packet Type Codes" in
[RADTYPE]. Values 256 - 8,388,607 (0x100 to 0x7fffff) are for [RADTYPE]. Values 256 - 8,388,607 (0x100 - 0x7fffff) are for
permanent, standard commands, allocated by IETF Review [RFC5226]. permanent, standard commands allocated by IETF Review [RFC5226].
[RFC3588] defines the Command Codes 257, 258, 271, 274-275, 280 and [RFC3588] defines the command codes 257, 258, 271, 274, 275, 280, and
282. See Section 3.1 in [RFC3588] for the assignment of the 282; see Section 3.1 in [RFC3588] for the assignment of the namespace
namespace in this specification. in that specification.
The values 8,388,608 - 16,777,213 (0x800000 - 0xfffffd) are reserved The values 8,388,608 - 16,777,213 (0x800000 - 0xfffffd) are reserved
for vendor-specific command codes, to be allocated on a First Come, for vendor-specific command codes, to be allocated on a First Come,
First Served basis by IANA [RFC5226]. The request to IANA for a First Served basis by IANA [RFC5226]. The request to IANA for a
Vendor-Specific Command Code SHOULD include a reference to a publicly vendor-specific command code SHOULD include a reference to a publicly
available specification which documents the command in sufficient available specification that documents the command in sufficient
detail to aid in interoperability between independent detail to aid in interoperability between independent
implementations. If the specification cannot be made publicly implementations. If the specification cannot be made publicly
available, the request for a vendor-specific command code MUST available, the request for a vendor-specific command code MUST
include the contact information of persons and/or entities include the contact information of persons and/or entities
responsible for authoring and maintaining the command. responsible for authoring and maintaining the command.
The values 16,777,214 and 16,777,215 (hexadecimal values 0xfffffe - The values 16,777,214 and 16,777,215 (hexadecimal values 0xfffffe -
0xffffff) are reserved for experimental commands. As these codes are 0xffffff) are reserved for experimental commands. As these codes are
only for experimental and testing purposes, no guarantee is made for only for experimental and testing purposes, no guarantee is made for
interoperability between Diameter peers using experimental commands, interoperability between Diameter peers using experimental commands,
as outlined in [RFC3692]. as outlined in [RFC3692].
5. Acknowledgements 5. Acknowledgements
The content of this document is the result of the work in the IETF The content of this document is the result of the work in the IETF
Diameter Maintenance and Extensions (dime) working group. We would Diameter Maintenance and Extensions (DIME) working group. We would
therefore like to thank all the working group members who were therefore like to thank all the working group members who were
involved in that discussion. While it appears to be a fairly small involved in that discussion. While it appears to be a fairly small
change in the allocation policy the effect on implementations is change in the allocation policy, the effect on implementations is
rather dramatic. rather dramatic.
We would like to thank Mark Jones for his review comments. We would like to thank Mark Jones for his review comments.
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and
Arkko, "Diameter Base Protocol", RFC 3588, September 2003. J. Arkko, "Diameter Base Protocol", RFC 3588,
September 2003.
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004. Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
IANA Considerations Section in RFCs", BCP 26, RFC 5226, an IANA Considerations Section in RFCs", BCP 26,
May 2008. RFC 5226, May 2008.
6.2. Informative References 6.2. Informative References
[I-D.ietf-dime-rfc3588bis] [RADTYPE] IANA, "Radius Types", <http://www.iana.org>.
Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
"Diameter Base Protocol", draft-ietf-dime-rfc3588bis-18
(work in progress), July 2009.
[RADTYPE] "IANA, RADIUS Types, [RFC3588bis] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
http://www.iana.org/assignments/radius-types". "Diameter Base Protocol", Work in Progress,
September 2009.
Authors' Addresses Authors' Addresses
Dan Romascanu Dan Romascanu
Avaya Avaya
Industrial Park Atidim, Bldg#3 Industrial Park Atidim, Bldg#3
Tel Aviv 61581 Tel Aviv 61581
Israel Israel
Phone: +972-3-645-8414 Phone: +972-3-645-8414
Email: dromasca@avaya.com EMail: dromasca@avaya.com
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
Espoo 02600 Espoo 02600
Finland Finland
Phone: +358 (50) 4871445 Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at URI: http://www.tschofenig.priv.at
 End of changes. 31 change blocks. 
127 lines changed or deleted 118 lines changed or added

This html diff was produced by rfcdiff 1.37b. The latest version is available from http://tools.ietf.org/tools/rfcdiff/