< draft-ietf-dime-app-design-guide-23.txt		draft-ietf-dime-app-design-guide-24.txt >
	Diameter Maintenance and Extensions (DIME) L. Morand, Ed.		Diameter Maintenance and Extensions (DIME) L. Morand, Ed.
	Internet-Draft Orange Labs		Internet-Draft Orange Labs
	Intended status: Best Current Practice V. Fajardo		Intended status: Best Current Practice V. Fajardo
	Expires: November 13, 2014 Independent		Expires: December 6, 2014 Independent
	H. Tschofenig		H. Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	May 12, 2014		June 4, 2014
	Diameter Applications Design Guidelines		Diameter Applications Design Guidelines
	draft-ietf-dime-app-design-guide-23		draft-ietf-dime-app-design-guide-24
	Abstract		Abstract
	The Diameter base protocol provides facilities for protocol		The Diameter base protocol provides facilities for protocol
	extensibility enabling to define new Diameter applications or modify		extensibility enabling to define new Diameter applications or modify
	existing applications. This document is a companion document to the		existing applications. This document is a companion document to the
	Diameter Base protocol that further explains and clarifies the rules		Diameter Base protocol that further explains and clarifies the rules
	to extend Diameter. Futhermore, this document provides guidelines to		to extend Diameter. Futhermore, this document provides guidelines to
	Diameter application designers reusing/defining Diameter applications		Diameter application designers reusing/defining Diameter applications
	or creating generic Diameter extensions.		or creating generic Diameter extensions.
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on November 13, 2014.		This Internet-Draft will expire on December 6, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 10, line 7 ¶		skipping to change at page 10, line 7 ¶
	new functionality as well as maintain the integrity of existing		new functionality as well as maintain the integrity of existing
	dictionaries.		dictionaries.
	4.4. Reusing Existing AVPs		4.4. Reusing Existing AVPs
	This section discusses rules in reusing existing AVP when reusing an		This section discusses rules in reusing existing AVP when reusing an
	existing command or defining a new command in a new application.		existing command or defining a new command in a new application.
	4.4.1. Setting of the AVP Flags		4.4.1. Setting of the AVP Flags
	When reusing AVPs in a new application, the M-bit flag setting MUST		When reusing existing AVPs in a new application, application
	be re-evaluated for a new Diameter application and, if necessary,		designers MUST specify the setting of the M-bit flag for a new
	even for every command within the application. In general, for AVPs		Diameter application and, if necessary, for every command of the
	defined outside of the Diameter base protocol, the characteristics of		application that can carry these AVPs. In general, for AVPs defined
	an AVP are tied to its role within a given application and the		outside of the Diameter base protocol, the characteristics of an AVP
	commands used in this application.		are tied to its role within a given application and the commands used
			in this application.
	All other AVP flags (V-bit, P-bit, reserved bits) MUST remain		All other AVP flags (V-bit, P-bit, reserved bits) MUST remain
	unchanged.		unchanged.
	4.4.2. Reuse of AVP of Type Enumerated		4.4.2. Reuse of AVP of Type Enumerated
	When reusing an AVP of type Enumerated in a command for a new		When reusing an AVP of type Enumerated in a command for a new
	application, it is RECOMMENDED to avoid modifying the set of valid		application, it is RECOMMENDED to avoid modifying the set of valid
	values defined for this AVP. Modifying the set of Enumerated values		values defined for this AVP. Modifying the set of Enumerated values
	includes adding a value or deprecating the use of a value defined		includes adding a value or deprecating the use of a value defined
	skipping to change at page 14, line 5 ¶		skipping to change at page 14, line 5 ¶
	an Enumerated AVP whether the set of values will remain unchanged or		an Enumerated AVP whether the set of values will remain unchanged or
	new values may be required in a near future. If such extension is		new values may be required in a near future. If such extension is
	foreseen or cannot be avoided, it is RECOMMENED to rather define AVPs		foreseen or cannot be avoided, it is RECOMMENED to rather define AVPs
	of type Unsigned32 or Unsigned64 in which the data field would		of type Unsigned32 or Unsigned64 in which the data field would
	contain an address space representing "values" that would have the		contain an address space representing "values" that would have the
	same use of Enumerated values.		same use of Enumerated values.
	For illustration, an AVP describing possible access networks would be		For illustration, an AVP describing possible access networks would be
	defined as follow:		defined as follow:
	Access-Network-Type AVP (XXX) is of type Unsigned32 and contains an		Access-Network-Type AVP (XXX) is of type Unsigned32 and contains a
	32-bit address space representing types of access networks. This		32-bit address space representing types of access networks. This
	application defines the following classes of access networks, all		application defines the following classes of access networks, all
	identified by the thousands digit in the decimal notation:		identified by the thousands digit in the decimal notation:
	o 1xxx (Mobile Access Networks)		o 1xxx (Mobile Access Networks)
	o 2xxx (Fixed Access Network)		o 2xxx (Fixed Access Network)
	o 3xxx (Wireless Access Networks)		o 3xxx (Wireless Access Networks)
	skipping to change at page 20, line 43 ¶		skipping to change at page 20, line 43 ¶
	7. Guidelines for Registrations of Diameter Values		7. Guidelines for Registrations of Diameter Values
	As summarized in the Section 3 of this document and further described		As summarized in the Section 3 of this document and further described
	in the Section 1.3 of [RFC6733], there are four main ways to extend		in the Section 1.3 of [RFC6733], there are four main ways to extend
	Diameter. The process for defining new functionality slightly varies		Diameter. The process for defining new functionality slightly varies
	based on the different extensions. This section provides protocol		based on the different extensions. This section provides protocol
	designers with some guidance regarding the definition of values for		designers with some guidance regarding the definition of values for
	possible Diameter extensions and the necessary interaction with IANA		possible Diameter extensions and the necessary interaction with IANA
	to register the new functionality.		to register the new functionality.
	a. Defining new AVP values		a. Defining new AVP values
	The specifications defining AVPs and AVP values MUST provide		The specifications defining AVPs and AVP values MUST provide
	guidance for defining new values and the corresponding policy for		guidance for defining new values and the corresponding policy for
	adding these values. For example, the RFC 5777 [RFC5777] defines		adding these values. For example, the RFC 5777 [RFC5777] defines
	the Treatment-Action AVP which contains a list of valid values		the Treatment-Action AVP which contains a list of valid values
	corresponding to pre-defined actions (drop, shape, mark, permit).		corresponding to pre-defined actions (drop, shape, mark, permit).
	This set of values can be extended following the Specification		This set of values can be extended following the Specification
	Required policy defined in [RFC5226]. As a second example, the		Required policy defined in [RFC5226]. As a second example, the
	Diameter base specification [RFC6733] defines the Result-Code AVP		Diameter base specification [RFC6733] defines the Result-Code AVP
	that contains a 32-bit address space used to identity possible		that contains a 32-bit address space used to identity possible
	errors. According to the Section 11.3.2 of [RFC6733], new values		errors. According to the Section 11.3.2 of [RFC6733], new values
	can be assigned by IANA via an IETF Review process [RFC5226].		can be assigned by IANA via an IETF Review process [RFC5226].
	b. Creating new AVPs		b. Creating new AVPs
	Two different types of AVP Codes namespaces can be used to create		Two different types of AVP Codes namespaces can be used to create
	a new AVPs:		a new AVPs:
	* IETF AVP Codes namespace;		* IETF AVP Codes namespace;
	* Vendor-specific AVP Codes namespace.		* Vendor-specific AVP Codes namespace.
	In the latter case, a vendor needs to be first assigned by IANA		In the latter case, a vendor needs to be first assigned by IANA
	with a private enterprise number, which can be used within the		with a private enterprise number, which can be used within the
	skipping to change at page 21, line 32 ¶		skipping to change at page 21, line 32 ¶
	responsible for vendor-specific AVP code value assignment. The		responsible for vendor-specific AVP code value assignment. The
	absence of a Vendor-Id or a Vendor-Id value of zero (0) in the AVP		absence of a Vendor-Id or a Vendor-Id value of zero (0) in the AVP
	header identifies standard AVPs from the IETF AVP Codes namespace		header identifies standard AVPs from the IETF AVP Codes namespace
	managed by IANA. The allocation of code values from the IANA-		managed by IANA. The allocation of code values from the IANA-
	managed namespace is conditioned by an Expert Review of the		managed namespace is conditioned by an Expert Review of the
	specification defining the AVPs or an IETF review if a block of		specification defining the AVPs or an IETF review if a block of
	AVPs needs to be assigned. Moreover, the remaining bits of the		AVPs needs to be assigned. Moreover, the remaining bits of the
	AVP Flags field of the AVP header are also assigned via Standard		AVP Flags field of the AVP header are also assigned via Standard
	Action if the creation of new AVP Flags is desired.		Action if the creation of new AVP Flags is desired.
	c. Creating new commands		c. Creating new commands
	Unlike the AVP Code namespace, the Command Code namespace is flat		Unlike the AVP Code namespace, the Command Code namespace is flat
	but the range of values is subdivided into three chunks with		but the range of values is subdivided into three chunks with
	distinct IANA registration policies:		distinct IANA registration policies:
	* A range of standard Command Code values that are allocated via		* A range of standard Command Code values that are allocated via
	IETF review;		IETF review;
	* A range of vendor-specific Command Code values that are		* A range of vendor-specific Command Code values that are
	allocated on a First-Come/First-Served basis;		allocated on a First-Come/First-Served basis;
	* A range of values reserved only for experimental and testing		* A range of values reserved only for experimental and testing
	purposes.		purposes.
	As for AVP Flags, the remaining bits of the Command Flags field of		As for AVP Flags, the remaining bits of the Command Flags field of
	the Diameter header are also assigned via a Standards Action to		the Diameter header are also assigned via a Standards Action to
	create new Command Flags if required.		create new Command Flags if required.
	d. Creating new applications		d. Creating new applications
	Similarly to the Command Code namespace, the Application-Id		Similarly to the Command Code namespace, the Application-Id
	namespace is flat but divided into two distinct ranges:		namespace is flat but divided into two distinct ranges:
	* A range of values reserved for standard Application-Ids		* A range of values reserved for standard Application-Ids
	allocated after Expert Review of the specification defining the		allocated after Expert Review of the specification defining the
	standard application;		standard application;
	* A range for values for vendor specific applications, allocated		* A range for values for vendor specific applications, allocated
	by IANA on a First-Come/First-Serve basis.		by IANA on a First-Come/First-Serve basis.
	The IANA AAA parameters page can be found at http://www.iana.org/		The IANA AAA parameters page can be found at http://www.iana.org/
	assignments/aaa-parameters/aaa-parameters.xml and the enterprise		assignments/aaa-parameters/aaa-parameters.xml and the enterprise
	number IANA page is available at http://www.iana.org/assignments/		number IANA page is available at http://www.iana.org/assignments/
	enterprise-numbers. More details on the policies followed by IANA		enterprise-numbers. More details on the policies followed by IANA
	for namespace management (e.g. First-Come/First-Served, Expert		for namespace management (e.g. First-Come/First-Served, Expert
	Review, IETF Review, etc.) can be found in [RFC5226].		Review, IETF Review, etc.) can be found in [RFC5226].
	NOTE:		NOTE:
	When the same functionality/extension is used by more than one		When the same functionality/extension is used by more than one
	vendor, it is RECOMMENDED to define a standard extension.		vendor, it is RECOMMENDED to define a standard extension.
	Moreover, a vendor-specific extension SHOULD be registered to		Moreover, a vendor-specific extension SHOULD be registered to
	avoid interoperability issues in the same network. With this aim,		avoid interoperability issues in the same network. With this aim,
	the registration policy of vendor-specific extension has been		the registration policy of vendor-specific extension has been
	simplified with the publication of [RFC6733] and the namespace		simplified with the publication of [RFC6733] and the namespace
	reserved for vendor-specific extensions is large enough to avoid		reserved for vendor-specific extensions is large enough to avoid
	skipping to change at page 23, line 44 ¶		skipping to change at page 23, line 44 ¶
	[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.
	[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,		[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
	"Diameter Base Protocol", RFC 6733, October 2012.		"Diameter Base Protocol", RFC 6733, October 2012.
	12.2. Informative References		12.2. Informative References
	[Q.3303.3]		[Q.3303.3]
	3rd Generation Partnership Project, "ITU-T Recommendation		3rd Generation Partnership Project, "ITU-T Recommendation
	Q.3303.3, "Resource control protocol no. 3 (rcp3):		Q.3303.3, "Resource control protocol no. 3 (rcp3):
	Protocol at the Rw interface between the Policy Decision		Protocol at the Rw interface between the Policy Decision
	Physical Entity (PD-PE) and the Policy Enforcement		Physical Entity (PD-PE) and the Policy Enforcement
	Physical Entity (PE-PE): Diameter"", 2008.		Physical Entity (PE-PE): Diameter"", 2008.
	[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange		[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
	(IKE)", RFC 2409, November 1998.		(IKE)", RFC 2409, November 1998.
	[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.		[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
	Arkko, "Diameter Base Protocol", RFC 3588, September 2003.		Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
	skipping to change at page 24, line 42 ¶		skipping to change at page 24, line 42 ¶
	[RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M.,		[RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M.,
	and A. Lior, "Traffic Classification and Quality of		and A. Lior, "Traffic Classification and Quality of
	Service (QoS) Attributes for Diameter", RFC 5777, February		Service (QoS) Attributes for Diameter", RFC 5777, February
	2010.		2010.
	[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,		[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
	"Internet Key Exchange Protocol Version 2 (IKEv2)", RFC		"Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
	5996, September 2010.		5996, September 2010.
	[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
	"Diameter Base Protocol", RFC 6733, October 2012.
	[RFC6735] Carlberg, K. and T. Taylor, "Diameter Priority Attribute-		[RFC6735] Carlberg, K. and T. Taylor, "Diameter Priority Attribute-
	Value Pairs", RFC 6735, October 2012.		Value Pairs", RFC 6735, October 2012.
	[RFC7075] Tsou, T., Hao, R., and T. Taylor, "Realm-Based Redirection		[RFC7075] Tsou, T., Hao, R., and T. Taylor, "Realm-Based Redirection
	In Diameter", RFC 7075, November 2013.		In Diameter", RFC 7075, November 2013.
	[RFC7155] Zorn, G., "Diameter Network Access Server Application",		[RFC7155] Zorn, G., "Diameter Network Access Server Application",
	RFC 7155, April 2014.		RFC 7155, April 2014.
	[TS29.228]		[TS29.228]
End of changes. 13 change blocks.
	20 lines changed or deleted		18 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/