draft-ietf-dime-app-design-guide-02.txt		draft-ietf-dime-app-design-guide-01.txt
	Diameter Maintanence and V. Fajardo, Ed.		Diameter Maintanence and V. Fajardo, Ed.
	Extensions (DIME) Toshiba America Research Inc.		Extensions (DIME) Toshiba America Research Inc.
	Internet-Draft T. Asveren		Internet-Draft T. Asveren
	Intended status: Informational Sonus Network		Intended status: Informational Sonus Network
	Expires: January 7, 2008 H. Tschofenig		Expires: December 8, 2007 H. Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	G. McGregor		G. McGregor
	Alcatel-Lucent		Alcatel-Lucent
	J. Loughney		J. Loughney
	Nokia Research Center		Nokia Research Center
	July 6, 2007		June 6, 2007
	Diameter Applications Design Guidelines		Diameter Applications Design Guidelines
	draft-ietf-dime-app-design-guide-02.txt		draft-ietf-dime-app-design-guide-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 41		skipping to change at page 1, line 41
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on January 7, 2008.		This Internet-Draft will expire on December 8, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	The Diameter Base protocol provides updated rules on how to extend		The Diameter Base protocol provides rules on how to extend Diameter
	Diameter by modifying and/or deriving from existing applications or		and to create new Diameter applications. This is a companion
	creating entirely new applications. This is a companion document to		document to clarify these rules. This document does not intended to
	the Diameter Base protocol which further explains and/or clarify		add, remove or change these rules, rather it helps protocol designers
	these rules. It is meant as a guidelines document and therefore it		to extend Diameter.
	does not add, remove or change existing rules.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Brief Overview of the Diameter Application Model . . . . . . . 4		3. Diameter Application Model . . . . . . . . . . . . . . . . . . 3
	4. Rules on Extending Diameter . . . . . . . . . . . . . . . . . 4		4. Rules on Diameter Extensibility . . . . . . . . . . . . . . . 4
	4.1. Reusing Existing Applications . . . . . . . . . . . . . . 5		4.1. Rules on Extending Existing Applications . . . . . . . . . 5
	4.1.1. Adding a new command . . . . . . . . . . . . . . . . . 6		5. Design Considerations . . . . . . . . . . . . . . . . . . . . 7
	4.1.2. Deleting a command . . . . . . . . . . . . . . . . . . 7		5.1. Diameter Accounting Support . . . . . . . . . . . . . . . 7
	4.2. Reusing Existing Commands . . . . . . . . . . . . . . . . 7		5.2. Generic Diameter Extensions . . . . . . . . . . . . . . . 8
	4.2.1. Adding AVPs to a command . . . . . . . . . . . . . . . 7		5.3. Updating an existing Application . . . . . . . . . . . . . 9
	4.2.2. Deleting AVPs from a command . . . . . . . . . . . . . 9		5.4. Use of optional AVPs . . . . . . . . . . . . . . . . . . . 10
	4.3. Reusing Existing AVPs . . . . . . . . . . . . . . . . . . 10		5.5. Deleting AVPs from a Command ABNF . . . . . . . . . . . . 10
	5. Rules for new Applications . . . . . . . . . . . . . . . . . . 10		5.6. Justifying the Allocation of Application-Id . . . . . . . 11
	5.1. Rules in Allocating new Command Codes . . . . . . . . . . 10		5.7. Use of Application-Id in a Message . . . . . . . . . . . . 11
	5.2. Justifying the Allocation of Application-Id . . . . . . . 11		5.8. Application Specific Session Statemachine . . . . . . . . 11
	5.3. Use of Application-Id in a Message . . . . . . . . . . . . 11		5.9. System Architecture and Deployment . . . . . . . . . . . . 12
	5.4. Application Specific Session Statemachine . . . . . . . . 11		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	5.5. End-to-End Applications Capabilities Exchange . . . . . . 12		7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	6. Other Design Considerations . . . . . . . . . . . . . . . . . 12		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
	6.1. Diameter Accounting Support . . . . . . . . . . . . . . . 12		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	6.2. Generic Diameter Extensions . . . . . . . . . . . . . . . 14		9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
	6.3. Updating an existing Application . . . . . . . . . . . . . 15		9.2. Informative References . . . . . . . . . . . . . . . . . . 14
	6.4. System Architecture and Deployment . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		Intellectual Property and Copyright Statements . . . . . . . . . . 16
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
	10.2. Informative References . . . . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
	Intellectual Property and Copyright Statements . . . . . . . . . . 19
	1. Introduction		1. Introduction
	The Diameter Base protocol document defines rules on how one would		The Diameter Base protocol document defines rules on how one would
	extend Diameter (see Section 1.2 of [1]). In the context of this		extend Diameter (see Section 1.2 of [1]). In the context of this
	document, extending Diameter means one of the following:		document, extending Diameter means that a new Diameter application is
			being defined which may or may not be based on an existing Diameter
	1. A new functionality is being added to an existing Diameter		application. A decision to define a new application would mean
	application without defining a new application.		allocation of a new application ID.
	2. A new Diameter application is being defined by reusing an
	existing application.
	3. A completely new application is being defined that has no
	dependencies to any existing applications.
	4. A new generic functionality is being defined that can be reused		By themselves, the rules defined in the Diameter Base protocol are
	across different applications.		not necessarily comprehensive enough that one can easily derive good
			design decisions from them. The effect of this can be seen in
			various attempts to extend Diameter where protocol designers have no
			clear answer on whether to even define a new application or not. At
			worst, some existing Diameter applications that had purposely been
			derived from another existing application resulted in some in-
			appropriate design decision in which both applications are no longer
			interoperable in certain conditions.
	All of these choices are design decisions that can done by any		The intent of this document is to influence ongoing and future
	combination of reusing existing or defining new commands, AVPs or AVP		Diameter application design by providing the following content:
	values. The objective of this document is the following:
	o Clarify updated Diameter extensibility rules in the Diameter Base		o Clarify existing Diameter extensibility rules present in the
	Protocol.		Diameter Base Protocol.
	o Clarify usage of certain Diameter functionality which are not		o Clarify usage of certain Diameter functionality which are not
	explicitly described in the Diameter Base specification.		explicitly described in the Diameter Base specification.
	o Discuss design choices and provide guidelines when defining		o Discuss design choices when defining new applications.
	applications.
	o Present tradeoffs of design choices.		o Present tradeoffs of design choices.
	These guidelines are necessary since the existing rules do not cover		Note that it is not always possible to offer a complete and concise
	the ambiguity that exist when some of the design choices overlap. A		answer to certain design choices. There is, however, the belief that
	typical example would be deciding between item one(1) and two(2)		at a minimum, this document can be used as a guide to Diameter
	above when an application designer requires a new application		extensibility.
	functionality which has many things in common with an existing
	application. Certain ambiguous aspects of such cases was not
	foreseen in the existing extensibility rules; i.e., use of optional
	AVPs to differentiate new functionality in the old application versus
	defining a new application and importing the existing set of
	commands. In this example, it was only based on collective
	experiences of application designers that the decision to create a
	new application (item two(2)) is now seen as the cleanest approach.
	Along with the gained experience however, additional bad practices
	have developed as well. Continuing the example above, the decision
	to create a new application would result in the allocation of a new
	application ID which often times is foreseen as cumbersome by
	application designers because of the lengthy process. Designers
	therefore tend to circumvent the better approach leading to many
	compromises in the design that eventually lead to interoperability
	issues (See Section 5.1).
	The basic issue is that the rules defined in the Diameter Base
	protocol are not comprehensive enough that one can easily derive good
	design decisions from them. The effect of this can be seen in
	various attempts to extend Diameter applications where designers have
	no clear answer on whether to even define a new application or not.
	At worst, some existing Diameter applications that had purposely been
	derived from another existing application resulted in some in-
	appropriate design decision where both the existing application and
	the derived applications are no longer interoperable under certain
	conditions. Note that it is not always possible to offer a complete
	and concise answer to certain design choices but at the least, this
	document can be used as a guide to Diameter extensibility.
	2. Terminology		2. Terminology
	This document reuses the terminology used in [1].		This document reuses the terminology used in [1].
	3. Brief Overview of the Diameter Application Model		3. Diameter Application Model
	As it is currently interpreted and practiced, the Diameter Base		As it is currently interpreted and practiced, the Diameter Base
	protocol is a two-layer protocol. The lower layer is mainly		protocol is a two-layer protocol. The lower layer is mainly
	responsible for managing connections between neighboring peers and		responsible for managing connections between neighboring peers and
	for message routing. The upper layer is where the Diameter		for message routing. The upper layer is where the Diameter
	applications reside. This model is inline with a Diameter node		applications reside. This model is inline with a Diameter node
	having an application layer and a peer-to-peer delivery layer. The		having an application layer and a peer-to-peer delivery layer. The
	Diameter Base protocol document completely defines the architecture		Diameter Base protocol document completely defines the architecture
	and behavior of the message delivery layer and then provides the		and behavior of the message delivery layer and then provides the
	framework for designing Diameter applications on the application		framework for designing Diameter applications on the application
	layer. This framework includes definitions of application sessions		layer. This framework includes definitions of application sessions
	and accounting support (see Section 8 and 9 of [1]). The remainder		and accounting support (see Section 8 and 9 of [1]). The remainder
	of this document also treats a Diameter node as a single instance of		of this document also treats a Diameter node as a single instance of
	a Diameter message delivery layer and one or more Diameter		a Diameter message delivery layer and one or more Diameter
	applications using it.		applications using it.
	4. Rules on Extending Diameter		4. Rules on Diameter Extensibility
	Extending Diameter can mean the reuse of commands, AVPs and AVP
	values in any combination for the purpose of inheriting the features
	of an existing Diameter applications. This section discusses the
	rules on how such reuse can be done.
	When reusing existing applications, the requirements of the new
	applications are typically not completely unique and there are
	existing application's that can be reused to solve some or all of the
	application requirements. Therefore, there is a greater likelihood
	of ambiguity on how much of the existing application can be reused,
	to what extent and what the implications for both the new and
	existing application. To broadly categorize, the rules for reusing
	existing applications can be either:
	1. Minimal - which typically means adding optional AVPs to existing
	commands.
	2. Invasive - where addition or deletion of commands and/or AVPs,
	and/or AVP values.
	Because it can fundamentally change the application, the latter
	approach has strict repercussions. Specifically, it would result in
	the definition of a new application and therefore allocation of a new
	application ID is required. Discussion about the specific Diameter
	Base protocol rules associated with this approach are covered
	subsequent sections.
	The former approach, although simple, has pitfalls. The problems
	arise when there is a tendency by applications designers to keep
	adding optional AVPs to existing command so they can circumvent the
	rules associated with the latter approach. Specifically, some
	designers want to circumvent the standardization process associated
	with these rules and not necessarily the rules themselves. The
	pitfalls associated with this approach is described further in
	Section 4.2.1. Additionally, if designers choose this approach, all
	of the functionality of the existing application will be inherited
	even if the new usage has no intent of using some of the existing
	features.
	4.1. Reusing Existing Applications
	This section discusses the reuse of existing applications by adding
	and/or deleting commands from the application. This scenario is
	categorize as "Invasive" in Section 4 and would always result in the
	creation of new applications when the rules are applied.
	4.1.1. Adding a new command
	The rules are strict in this case. Adding a command to an
	application is not allowed and doing so will force a definition of a
	new application. However, if this is the intent, then the new
	application can be created by defining a new command for an existing
	application or importing an existing command from another application
	so as to inherit some or all of the functionality of that
	application. In the former case, the decision is straight forward
	since this is typically a result of adding new functionality that
	does not yet exist. See Section 5.1 for rules on how to allocate new
	command codes for new applications. The latter case would result in
	a new application but it has a more subtle issue such as deciding
	whether importing of commands and functionality is really better than
	simply using the existing application as it is in conjunction with
	any new application.
	A typical example would be the Diameter MIPv6 split scenario (see
	[2]) in which several application models would have been possible
	during the design phase; one model would reuse existing Diameter EAP
	application combined with a new Diameter MIPv6 application to form a
	complete authentication and authorization scheme and another would be
	to reuse Diameter EAP like commands within the new Diameter MIPv6
	application to accomplish the same result. In this case, the latter
	model was chosen which would permit the reuse of commands and/or AVPs
	from one application to another. Other applications such as Diameter
	QoS (see [3]) would likely face similar decisions.
	In general, it is difficult to come to a hard and fast guideline so a
	case by case study of each application requirement should be applied.
	Before adding or importing a command, application designers should
	consider the following:
	o Can the new functionality be fulfilled by creating a new
	application independent from the existing applications ? In this
	case, a deployment architecture could be designed such that both
	old and new application can work independent of but cooperating
	with each other.
	o Can the existing application be reused as is without fundamental
	changes; i.e. a non-mandatory optional AVP is sufficient to
	indicate support for new optional functionality if any. There are
	pitfalls to this as well. See Section 4.2.1
	o Care should be taken to avoid a liberal method of importing many		The general theme of Diameter extensibility is to reuse AVPs, AVP
	commands that results in a monolithic and hard to manage		values, commands and applications as much as possible. However,
	application which supports many different functionality.		there are also rules for extending Diameter as specified in Section
			1.2 of [1]. As is, the rules apply to the scenario where one is
			trying to define a new Diameter application. Defining a new Diameter
			application can be done by:
	o Will the new feature or functionality refers only to semantic or		Defining a completely new application
	statemachine changes in the application requiring extra message
	round-trips ? In such cases, definition of new commands may not
	be necessary and use of existing commands maybe sufficient.
	o Reuse of existing applications would result in a distributed
	environment which may not be conducive to certain requirements of
	the applications; i.e. security and or deployment difficulties -
	because of Diameter routing, messages for different applications
	providing service to the same user may end up in different servers
	would then need to be co-related. This could mean extra signaling
	between application servers. A typical example would be the
	initial proposal for Diameter MIPv6 split scenario (see [2]) where
	authorization and authentication is separated.
	Note that accounting commands normally require special treatment and		This case applies to applications which have requirements that
	would not necessarily fall into this category. See Section 6.1.		cannot be filled by existing applications and would require
			definition of new command(s), AVPs and AVP values. Typically,
			there is little ambiguity about the decision to create these types
			of applications. Some examples are the interfaces defined for the
			IP Multimedia Subsystem of 3GPP, i.e.; Cx/Dx ([2] and [3]), Sh
			([4] and [5]) etc . Though some decisions may be clear, designers
			should also consider certain aspects of the application itself.
			Some of these are described in Section 5. Applications design
			should also follow the theme of Diameter extensibility which
			advocates reuse of AVPs and AVP values as much as possible even in
			newly defined commands. In certain cases where accounting will be
			used, the models described in Section 5.1 should be considered.
	4.1.2. Deleting a command		Extending an existing application
	Although this is not typical, deleting an command from an existing		In this case, the requirements of the new applications are not
	application is fundamentally changing the application. In general,		completely unique and there are existing application's that can be
	the implications of this approach is the same as Section 4.1.1		reused to solve some or all of the application requirements.
	regardless of whether new commands will also be added to the		Thus, there is a greater likelihood of ambiguity on how much of
	resulting application. In general, it is unusual to delete an		the existing application can be reused, to what extent and what
	existing command from an existing for the sake of deleting it or the		the implications for both the new and existing application.
	functionality it represents. This design decision would normally be		Section 4.1 discusses some of the issues in this case.
	an indication of a flawed designed. An exception might be if the
	intent of the deletion is to create a newer version of the same
	application which is somehow simpler than the previous version. In
	that case, the considerations in Section 6.3 should apply instead.
	4.2. Reusing Existing Commands		4.1. Rules on Extending Existing Applications
	This section deals with a little more granularity than Section 4.1.		The Diameter base protocol provides a clear set of rules on when one
	Specifically, it discusses rules in adding and/or deleting AVPs from		should define a new Diameter application. In the context of this
	an existing command of an existing application. Unlike Section 4.1,		document, the rules are:
	the cases in this section may not necessarily result in the creation
	of new application(s). In some cases, there are a lot of ambiguity.
	So design considerations have been outline to ease the decision
	making process.
	4.2.1. Adding AVPs to a command		Adding an AVP to a command ABNF of an existing application
	Based on the rules in [1], AVPs that are added to an existing command		The rules are strict in the case where the AVP(s) to be added is
	can be categorized into:		mandatory. As defined in [1], a mandatory AVP is an AVP that has
	o Mandatory to understand AVPs. As defined in [1], these are AVPs		its M-bit flag set which requires a receiver to understand,
	which has their M-bit flag set which means Diameter nodes that		correctly interpret and process the AVP when it is present in a
	receives these AVPs has to understand not only their values but		message. This rule is independent of whether the AVP is defined
	their semantics and usage as well. This is regardless of whether		as required or optional to exist in a message. As long as the AVP
	these AVPs are required or optional to appear in the command; as		will added to a messages' ABNF then this rule will apply.
	specified by the commands ABNF.
	o Non-mandatory AVPs that are also optional in the commands ABNF.
	The rules are strict in the case where the AVPs to be added is		The mandatory AVP rules applies to AVP(s) that either already
	mandatory. A mandatory cannot be added to or deleted from an		exist in the same or in another application or the AVP(s) are yet
	existing command. [1] states that doing so would require the		to be defined. The ambiguity arises when trying to decide whether
	definition of a new application. This falls into the "Invasive"		the AVP(s) should be mandatory or not. There are several
	category described in Section 4. Despite the clarity of the rule,		questions that application designers should contemplate when
	ambiguity still arises when trying to decide whether a new AVP being		trying to decide:
	added should be mandatory to begin with. There are several questions
	that application designers should contemplate when trying to decide:
	o Does the AVPs change the state machine of the application ?		* Does the AVP(s) change the state machine of the application ?
	o Would the presence of the AVPs cause additional message round-		* Would the presence of the AVP(s) cause additional message
	trips; effectively changing the state machine of the application ?		round-trips; effectively changing the state machine of the
			application ?
	o Will the AVP be used to fulfill new required functionality ?		* Will the AVP be used to fulfill new required functionality ?
	o Would the AVP be used to differentiate between old and new		* Would the AVP be used to differentiate between old and new
	versions of the same application ?		versions of the same application ?
	o Will it have duality in meaning; i.e., be used to carry		* Will it have duality in meaning; i.e., be used to carry
	application related information as well as be used to indicate		application related information as well as be used to indicate
	that the message is for a new application ?		that the message is for a new application ?
	If one or more of the above conditions are true, the AVP is consider		These questions are not comprehensive in any way but in all cases
	mandatory. These questions are not comprehensive in any way but in		the semantics of the application must change to justify the use of
	all cases the semantics of the application must change to justify the
	use of mandatory AVPs.
	The rules are less restrictive when adding Non-mandatory, optional
	AVPs. This falls into the "Minimal" category described in Section 4.
	However, care should also be taken when opting for optional AVPs
	instead of mandatory AVPs simply to avoid the process of creating a
	new applications. Optional AVPs that answers any of the questions
	above also have consequences. Some of the issues associated with
	using optional AVPs are:
	o Use of optional AVPs with intersecting meaning; one AVP has
	partially the same usage and/or meaning as another AVP. The
	presence of both can lead to confusion.
	o An optional AVPs with dual purpose; i.e.; to carry applications
	data as well as to indicate support for one or more features.
	This has a tendency to introduce interpretation issues.
	o Use of optional AVPs with a minimum occurrence of one(1) in the
	command ABNF. This is generally contradictory. Application
	designers should not use this scheme to circumvent definition of
	mandatory AVPs.		mandatory AVPs.
	All of these practices generally result in interoperability problems		However, care should also be taken when opting for optional AVPs
	so they should be avoided as much as possible.		instead of mandatory AVPs simply to avoid allocating new
			applications. Optional AVPs that fall into any of the categorical
	4.2.2. Deleting AVPs from a command		questions above would have consequences. See Section 5.4 for
			details.
	Although this scenario is not as common, the deletion of AVPs from a
	command ABNF is significant when trying to extend an existing
	application. Deletion can again be categorized between mandatory and
	non-mandatory optional AVPs described in Section 4.2.1.
	In the unlikely event that an application designer would require that
	mandatory AVPs must be deleted then it constitutes a fundamental
	change to an existing application. Though not specified in [1],
	deletion of mandatory would require the definition of a new
	application since it dictates changes in the behavior and semantics
	of an application.
	Instead of deleting commands, a better alternative would be to define
	a new command that would represent the new behavior. Reusing the
	same command code for different use cases can lead to more confusion
	since the command will have different semantics depending on usage.
	This is especially true to base protocol commands (session related
	commands, ASR/ASA, STR/STA, RAR/RAA defined in [1]) where they are
	being used by many different applications.
	The deletion of an optional AVP may not necessarily indicate
	allocation of a new application. Deletion of non-mandatory optional
	AVPs with a zero(0) minimum occurrence in the commands ABNF would not
	require a new application. In the case where an optional AVP has a
	minimum occurrence of at least one(1) in the commands ABNF, then
	deletion of the AVP would effectively change the behavior of the
	application. It would be similar to the deletion of mandatory AVPs.
	Such cases are highly dubious to begin with since those AVPs already
	exhibits properties of mandatory AVPs. Extra consideration should be
	given as to why it was not defined as mandatory in the first place
	and that decision may have to be corrected as well.
	In other cases, it is recommended that application designers reuse
	the command ABNF without modification and simply ignore (but not
	delete) any optional AVP that will not be used. This is to maintain
	compatibility with existing applications that will not know about the
	new functionality as well as maintain the integrity of existing
	dictionaries.
	4.3. Reusing Existing AVPs
	This section deals with even more granularity than Section 4.1 and
	Section 4.2. Specifically, it discusses rules in adding, deleting or
	modifying the specified values of an AVP. The rules state that
	modifying the value of an AVP is allowed only if it does not change
	the semantics of the AVP and the application using it. Otherwise,
	the change can be consider "Invasive" as described in Section 4 and
	require definition of a new application. Note that designers should
	consider Section 5.2 when contemplating on these types of changes.
	Typically, the data types of the AVPs in question are scalar in
	nature and each ordinal value represent a specific semantic behavior
	of the application. An example is CC-Request-Type AVP of [4].
	Adding, deleting or modifying known values of this AVP can modify the
	behavior of the application itself. Additionally, the mandatory and
	optional AVPs rules are inherited from Section 4.2. So this affects
	the decision for defining new applications as well.
	5. Rules for new Applications
	The general theme of Diameter extensibility is to reuse commands,
	AVPs and AVP values as much as possible. However, some of the
	extensibility rules described in the previous section also apply to
	scenarios where a designer is trying to define a completely new
	Diameter application.
	This section discusses the case where new applications have
	requirements that cannot be filled by existing applications and would
	require definition of completely new commands, AVPs and/or AVP
	values. Typically, there is little ambiguity about the decision to
	create these types of applications. Some examples are the interfaces
	defined for the IP Multimedia Subsystem of 3GPP, i.e.; Cx/Dx ([5] and
	[6]), Sh ([7] and [8]) etc.
	Application design should also follow the theme of Diameter
	extensibility which in this case may mean importing of existing AVPs
	and AVP values for any newly defined commands. In certain cases
	where accounting will be used, the models described in Section 6.1
	should also be considered. Though some decisions may be clear,
	designers should also consider certain aspects of defining a new
	application. Some of these are described in following sections.
	5.1. Rules in Allocating new Command Codes
	[Editor's note: The expert review process for command code allocation
	is being introduced to hasten the allocation process itself.
	Hopefully this will lessen the tendency to circumvent this process.
	The core rules for this process will be introduced in rfc3588bis and
	full description will be added in this section in the next rev of
	this document]
	5.2. Justifying the Allocation of Application-Id
	Application designers should avoid justifying the allocation of an
	application ID for each new functionality or any change that is made
	to an existing application. Proliferation of application ID can lead
	to confusion and an in-efficient use of the application ID
	namespaces. Application designers should always use Section 4 as a
	basis for justifying allocation of a new application ID.
	5.3. Use of Application-Id in a Message
	When designing new applications, designers should specify that the
	application ID carried in all session level messages must be the
	application ID of the application using those messages. This
	includes the session level messages defined in base protocol, i.e.,
	RAR/RAA, STR/STA, ASR/ASA