<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	<!ENTITY RFC2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
      <!ENTITY RFC3588 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml'>
      <!ENTITY RFC3692 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3692.xml'>
      <!ENTITY RFC5226 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml'>
      <!ENTITY I-D.ietf-dime-rfc3588bis PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dime-rfc3588bis.xml'>
]>

<rfc category="std" updates="rfc3588" ipr="trust200902"
	docName="draft-romascanu-diameter-cmd-iana-00.txt">
	<?rfc toc="yes" ?>
	<?rfc symrefs="yes" ?>
	<?rfc sortrefs="yes"?>
	<?rfc iprnotified="no" ?>
	<?rfc strict="yes" ?>
	<front>
		<title abbrev="Diameter Command Code Allocation Policy">Updated IANA Considerations for
			Diameter Command Code Allocations</title>
		<author fullname="Dan Romascanu" initials="D." surname="Romascanu">
			<organization>Avaya</organization>
			<address>
				<postal>
					<street>Industrial Park Atidim, Bldg#3</street>
					<city>Tel Aviv</city>
					<code>61581</code>
					<country>Israel</country>
				</postal>
				<phone>+972-3-645-8414</phone>
				<email>dromasca@avaya.com</email>
			</address>
		</author>
		<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
			<organization>Nokia Siemens Networks</organization>
			<address>
				<postal>
					<street>Linnoitustie 6</street>
					<city>Espoo</city>
					<code>02600</code>
					<country>Finland</country>
				</postal>
				<phone>+358 (50) 4871445</phone>
				<email>Hannes.Tschofenig@gmx.net</email>
				<uri>http://www.tschofenig.priv.at</uri>
			</address>
		</author>
		<date year="2009"/>
		<workgroup>dime</workgroup>
		<abstract>
			<t> 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. </t>
			<t> 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. </t>
		</abstract>
	</front>
	<middle>
		<section title="Introduction">
			<t> The Diameter Base specification, described in RFC 3588 <xref target="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. </t>
			<t> 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. </t>
			<t> 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
					<xref target="RFC5226"/>. </t>
			<t> A revision of RFC 3588 is currently in development in the IETF DIME WG <xref
				target="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. </t>
		</section>

		<section title="Conventions used in this document">
			<t> 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 <xref target="RFC2119"/>. </t>
		</section>
		<!-- ****************************************************************************************** -->

		<section title="Security Considerations">
			<t> 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. </t>
		</section>

		<section title="IANA Considerations">

			<t> This section describes changes to the IANA consideration sections outlined in RFC
				3588 regarding the allocation of Command Codes by IANA. </t>
			<t> 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 <xref target="RADTYPE"/>. Values 256 - 8,388,607
				(0x100 to 0x7fffff) are for permanent, standard commands, allocated by IETF Review
					<xref target="RFC5226"/>. <xref target="RFC3588"/> defines the Command Codes
				257, 258, 271, 274-275, 280 and 282. See Section 3.1 in <xref target="RFC3588"/> for
				the assignment of the namespace in this specification. </t>
			<t> 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 <xref target="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. </t>
			<t> 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 <xref target="RFC3692"/>. </t>
		</section>

		<section title="Acknowledgements">
			<t>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.</t>
		</section>
	</middle>
	<back>
		<references title="Normative References"> &RFC2119; &RFC3588; &RFC3692;
			&RFC5226; </references>

		<references title="Informative References"> &I-D.ietf-dime-rfc3588bis; <reference
				anchor="RADTYPE">
				<front>
					<title abbrev="">IANA, RADIUS Types,
						http://www.iana.org/assignments/radius-types</title>
					<author>
						<organization/>
					</author>
				</front>
			</reference>
		</references>


	</back>

</rfc>
