< draft-ietf-soc-load-control-event-package-10.txt		draft-ietf-soc-load-control-event-package-11.txt >
	IETF SOC Working Group C. Shen		IETF SOC Working Group C. Shen
	Internet-Draft H. Schulzrinne		Internet-Draft H. Schulzrinne
	Intended status: Standards Track Columbia U.		Intended status: Standards Track Columbia U.
	Expires: May 09, 2014 A. Koike		Expires: May 28, 2014 A. Koike
	NTT		NTT
	November 05, 2013		November 24, 2013
	A Session Initiation Protocol (SIP) Load Control Event Package		A Session Initiation Protocol (SIP) Load Control Event Package
	draft-ietf-soc-load-control-event-package-10.txt		draft-ietf-soc-load-control-event-package-11.txt
	Abstract		Abstract
	We define a load control event package for the Session Initiation		We define a load control event package for the Session Initiation
	Protocol (SIP). It allows SIP entities to distribute load filtering		Protocol (SIP). It allows SIP entities to distribute load filtering
	policies to other SIP entities in the network. The load filtering		policies to other SIP entities in the network. The load filtering
	policies contain rules to throttle calls based on their source or		policies contain rules to throttle calls based on their source or
	destination domain, telephone number prefix or for a specific user.		destination domain, telephone number prefix or for a specific user.
	The mechanism helps to prevent signaling overload and complements		The mechanism helps to prevent signaling overload and complements
	feedback-based SIP overload control efforts.		feedback-based SIP overload control efforts.
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 May 09, 2014.		This Internet-Draft will expire on May 28, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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 2, line 21 ¶		skipping to change at page 2, line 21 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Design Requirements . . . . . . . . . . . . . . . . . . . . . 6		4. Design Requirements . . . . . . . . . . . . . . . . . . . . . 6
	5. SIP Load Filtering Overview . . . . . . . . . . . . . . . . . 6		5. SIP Load Filtering Overview . . . . . . . . . . . . . . . . . 6
	5.1. Load Filtering Policy Format . . . . . . . . . . . . . . 6		5.1. Load Filtering Policy Format . . . . . . . . . . . . . . 6
	5.2. Load Filtering Policy Computation . . . . . . . . . . . . 7		5.2. Load Filtering Policy Computation . . . . . . . . . . . . 7
	5.3. Load Filtering Policy Distribution . . . . . . . . . . . 7		5.3. Load Filtering Policy Distribution . . . . . . . . . . . 7
	5.4. Applicable Network Domains . . . . . . . . . . . . . . . 10		5.4. Applicable Network Domains . . . . . . . . . . . . . . . 10
	6. Load Control Event Package . . . . . . . . . . . . . . . . . 11		6. Load Control Event Package . . . . . . . . . . . . . . . . . 11
	6.1. Event Package Name . . . . . . . . . . . . . . . . . . . 11		6.1. Event Package Name . . . . . . . . . . . . . . . . . . . 12
	6.2. Event Package Parameters . . . . . . . . . . . . . . . . 12		6.2. Event Package Parameters . . . . . . . . . . . . . . . . 12
	6.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . 12		6.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . 12
	6.4. SUBSCRIBE Duration . . . . . . . . . . . . . . . . . . . 12		6.4. SUBSCRIBE Duration . . . . . . . . . . . . . . . . . . . 12
	6.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 12		6.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 12
	6.6. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 12		6.6. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 12
	6.7. Notifier Generation of NOTIFY Requests . . . . . . . . . 13		6.7. Notifier Generation of NOTIFY Requests . . . . . . . . . 13
	6.8. Subscriber Processing of NOTIFY Requests . . . . . . . . 13		6.8. Subscriber Processing of NOTIFY Requests . . . . . . . . 13
	6.9. Handling of Forked Requests . . . . . . . . . . . . . . . 14		6.9. Handling of Forked Requests . . . . . . . . . . . . . . . 14
	6.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 15		6.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 15
	6.11. State Delta . . . . . . . . . . . . . . . . . . . . . . . 15		6.11. State Delta . . . . . . . . . . . . . . . . . . . . . . . 15
	skipping to change at page 3, line 6 ¶		skipping to change at page 3, line 6 ¶
	8. XML Schema Definition for Load Control . . . . . . . . . . . 27		8. XML Schema Definition for Load Control . . . . . . . . . . . 27
	9. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 30		9. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 30
	9.1. Relationship with Load Filtering in PSTN . . . . . . . . 30		9.1. Relationship with Load Filtering in PSTN . . . . . . . . 30
	9.2. Relationship with Other IETF SIP Overload Control Efforts 31		9.2. Relationship with Other IETF SIP Overload Control Efforts 31
	10. Discussion of this specification meeting the requirements of		10. Discussion of this specification meeting the requirements of
	RFC5390 . . . . . . . . . . . . . . . . . . . . . . . . . . . 32		RFC5390 . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 37		11. Security Considerations . . . . . . . . . . . . . . . . . . . 37
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
	12.1. Load Control Event Package Registration . . . . . . . . 38		12.1. Load Control Event Package Registration . . . . . . . . 38
	12.2. application/load-control+xml MIME Registration . . . . . 38		12.2. application/load-control+xml MIME Registration . . . . . 38
	12.3. Load Control Schema Registration . . . . . . . . . . . . 39		12.3. URN Sub-Namespace Registration . . . . . . . . . . . . . 39
	13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39		12.4. Load Control Schema Registration . . . . . . . . . . . . 40
			13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . 40		14. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
	14.1. Normative References . . . . . . . . . . . . . . . . . . 40		14.1. Normative References . . . . . . . . . . . . . . . . . . 40
	14.2. Informative References . . . . . . . . . . . . . . . . . 41		14.2. Informative References . . . . . . . . . . . . . . . . . 41
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
	1. Introduction		1. Introduction
	Proper functioning of Session Initiation Protocol (SIP) [RFC3261]		Proper functioning of Session Initiation Protocol (SIP) [RFC3261]
	signaling servers is critical in SIP-based communications networks.		signaling servers is critical in SIP-based communications networks.
	The performance of SIP servers can be severely degraded when the		The performance of SIP servers can be severely degraded when the
	server is overloaded with excessive number of signaling requests.		server is overloaded with excessive number of signaling requests.
	Both legitimate and malicious traffic can overload SIP servers,		Both legitimate and malicious traffic can overload SIP servers,
	despite appropriate capacity planning.		despite appropriate capacity planning. Some of the SIP server
			overload situations are predictable, while others are not.
	There are three common examples of legitimate short-term increases in		There are four common examples of predictable short-term increases in
	call volumes. Viewer-voting TV shows or ticket giveaways may		call volumes. Viewer-voting TV shows or ticket giveaways, special
	generate millions of calls within a few minutes. Call volume may		holidays such as New Year's Day and Mother's Day, end-of-season peaks
	also spike during special holidays such as New Year's Day and		in phone orders, or after forecastable natural disasters such as
	Mother's Day. Finally, callers may want to reach friends and family		hurricanes. On the other hand, examples of unpredicted or
	in natural disaster areas such as those affected by hurricanes. When		unpredictable mass calling may happen after earthquakes, terrorist
	possible, only calls traversing overloaded servers should be		attacks, or at call centers that provide troubleshooting services
	throttled under those conditions.		when a mass service fails. When possible, only calls traversing
			overloaded servers should be throttled under overload conditions.
	SIP load control mechanisms are needed to prevent congestion collapse		SIP load control mechanisms are needed to prevent congestion collapse
	in these cases [RFC5390]. There are two types of load control		in these cases [RFC5390]. There are two types of load control
	approaches. In the first approach, feedback control, SIP servers		approaches. In the first approach, feedback control, SIP servers
	provide load limits to upstream servers, to reduce the incoming rate		provide load limits to upstream servers, to reduce the incoming rate
	of all SIP requests [I-D.ietf-soc-overload-control]. These upstream		of all SIP requests [I-D.ietf-soc-overload-control]. These upstream
	servers then drop or delay incoming SIP requests. Feedback control		servers then drop or delay incoming SIP requests. Feedback control
	is reactive and affects signaling messages that have already been		is reactive and affects signaling messages that have already been
	issued by user agent clients. They work well when SIP proxy servers		issued by user agent clients. They work well when SIP proxy servers
	in the core networks (core proxy servers) or destination-specific SIP		in the core networks (core proxy servers) or destination-specific SIP
	skipping to change at page 4, line 13 ¶		skipping to change at page 4, line 17 ¶
	policies that indicate calls to specific destinations or from		policies that indicate calls to specific destinations or from
	specific sources should be rate-limited or randomly dropped. These		specific sources should be rate-limited or randomly dropped. These
	load filtering policies are then distributed to SIP servers and		load filtering policies are then distributed to SIP servers and
	possibly SIP user agents that are likely to generate calls to the		possibly SIP user agents that are likely to generate calls to the
	affected destinations or from the affected sources. Load filtering		affected destinations or from the affected sources. Load filtering
	works best if it prevents calls as close to the originating user		works best if it prevents calls as close to the originating user
	agent clients as possible.		agent clients as possible.
	The load filtering approach is most applicable for situations where a		The load filtering approach is most applicable for situations where a
	traffic surge and its source/destination distribution can be		traffic surge and its source/destination distribution can be
	predicted in advance. For instance, it is appropriate for a mass-		predicted in advance. It is less likely to be effective for the
	phone-voting event, Mother's Day, New Year's Day, and even a		initial phase of unpredicted or unpredictable mass calling events.
	hurricane. However, it is less likely to be effective for the		In the latter cases, the local traffic load may peak by more than an
	initial phase of unpredicted/unpredictable mass calling events, such		order of magnitude in minutes, if not seconds. This does not allow
	as earthquakes or terrorist attacks. In these latter cases, the		time to either effectively identify the load filtering policies
	local traffic load may peak by more than an order of magnitude in		needed, nor distribute them to the appropriate servers soon enough to
	minutes, if not seconds. This does not allow time to either		prevent server congestion. Once other, more immediate, techniques
	effectively identify the load filtering policies needed, nor		(such as the loss-based or rate-based load feedback control methods)
	distribute them to the appropriate servers soon enough to prevent		have prevented the initial congestion collapse, the load filtering
	server congestion. Once other, more immediate, techniques (such as
	the loss-based or rate-based load feedback control methods) have
	prevented the initial congestion collapse, the load filtering
	approach can be used to effectively control the continuing overload.		approach can be used to effectively control the continuing overload.
	Performing SIP load filtering involves the following components of		Performing SIP load filtering involves the following components of
	load filtering policies: format definition, computation, distribution		load filtering policies: format definition, computation, distribution
	and enforcement. This specification defines the load filtering		and enforcement. This specification defines the load filtering
	policy, distribution and enforcement in the SIP load control event		policy, distribution and enforcement in the SIP load control event
	package built upon existing SIP event notification framework.		package built upon existing SIP event notification framework.
	However, load filtering policy computation is out of scope of this		However, load filtering policy computation is out of scope of this
	specification, because it depends heavily on the actual network		specification, because it depends heavily on the actual network
	topology and other service provider policies.		topology and other service provider policies.
	skipping to change at page 5, line 8 ¶		skipping to change at page 5, line 8 ¶
	The rest of this specification is structured as follows: we begin by		The rest of this specification is structured as follows: we begin by
	listing the design requirements for this work in Section 4. We then		listing the design requirements for this work in Section 4. We then
	give an overview of load filtering operation in Section 5. The load		give an overview of load filtering operation in Section 5. The load
	control event package for load filtering policy distribution is		control event package for load filtering policy distribution is
	detailed in Section 6. The load filtering policy format is defined		detailed in Section 6. The load filtering policy format is defined
	in the two sections that follow, with Section 7 introducing the XML		in the two sections that follow, with Section 7 introducing the XML
	document for load filtering policies and Section 8 listing the		document for load filtering policies and Section 8 listing the
	associated schema. Section 9 relates this work to corresponding		associated schema. Section 9 relates this work to corresponding
	mechanisms in PSTN and other IETF efforts addressing SIP overload		mechanisms in PSTN and other IETF efforts addressing SIP overload
	control. Section 10 evaluates whether this specification meets the		control. Section 10 evaluates whether this specification meets the
	SIP overload control requirements set forth by RFC5390 [RFC5390].		SIP overload control requirements set forth by [RFC5390]. Finally,
	Finally, Section 11 presents security considerations and Section 12		Section 11 presents security considerations and Section 12 provides
	provides IANA considerations.		IANA considerations.
	2. Conventions		2. Conventions
	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. Definitions		3. Definitions
	This specification reuses the definitions for "Event Package",		This specification reuses the definitions for "Event Package",
	skipping to change at page 6, line 39 ¶		skipping to change at page 6, line 39 ¶
	the load filtering policy should be able to specify the caller.		the load filtering policy should be able to specify the caller.
	o Caller and callee need to be specified as both SIP URIs and 'tel'		o Caller and callee need to be specified as both SIP URIs and 'tel'
	URIs [RFC3966] in load filtering policies.		URIs [RFC3966] in load filtering policies.
	o It should be possible to specify particular information in the SIP		o It should be possible to specify particular information in the SIP
	headers (e.g., prefixes in telephone numbers) which allow load		headers (e.g., prefixes in telephone numbers) which allow load
	filtering over limited regionally-focused overloads.		filtering over limited regionally-focused overloads.
	o The solution should draw upon experiences from related PSTN		o The solution should draw upon experiences from related PSTN
	mechanisms where applicable.		mechanisms [Q.1248.2][E.412][E.300SerSup3] where applicable.
	o The solution should be extensible to meet future needs.		o The solution should be extensible to meet future needs.
	5. SIP Load Filtering Overview		5. SIP Load Filtering Overview
	5.1. Load Filtering Policy Format		5.1. Load Filtering Policy Format
	Load filtering policies are specified by sets of rules. Each rule		Load filtering policies are specified by sets of rules. Each rule
	contains both load filtering conditions and actions. The load		contains both load filtering conditions and actions. The load
	filtering conditions define identities of the targets to be		filtering conditions define identities of the targets to be
	skipping to change at page 11, line 15 ¶		skipping to change at page 11, line 15 ¶
	o The mechanisms used to secure the communication among SIP entities		o The mechanisms used to secure the communication among SIP entities
	within the Trust Domain.		within the Trust Domain.
	o The manner used to determine which SIP entities are part of the		o The manner used to determine which SIP entities are part of the
	Trust Domain.		Trust Domain.
	o That SIP entities in the Trust Domain are compliant to SIP		o That SIP entities in the Trust Domain are compliant to SIP
	[RFC3261]		[RFC3261]
			o That SIP entities in the Trust Domain are compliant to SIP
			[RFC6665]
	o That SIP entities in the Trust Domain are compliant to this		o That SIP entities in the Trust Domain are compliant to this
	document.		document.
	o The agreement on what types of calls can be affected by this SIP		o The agreement on what types of calls can be affected by this SIP
	load filtering mechanism. For example, call identity condition		load filtering mechanism. For example, call identity condition
	elements (Section 7.3.1) <one> and <many> might be limited to		elements (Section 7.3.1) <one> and <many> might be limited to
	describe specific domains; <many-tel> and <except-tel> might be		describe specific domains; <many-tel> and <except-tel> might be
	limited to describe within certain prefixes.		limited to describe within certain prefixes.
	o The agreement on the destinations to which calls may be redirected		o The agreement on the destinations to which calls may be redirected
	skipping to change at page 39, line 9 ¶		skipping to change at page 39, line 4 ¶
	Encoding considerations: Same as encoding considerations of		Encoding considerations: Same as encoding considerations of
	application/xml in [RFC3023]		application/xml in [RFC3023]
	Security considerations: See Section 10 of [RFC3023] and Section 11		Security considerations: See Section 10 of [RFC3023] and Section 11
	of this specification		of this specification
	Interoperability considerations: None		Interoperability considerations: None
	Published Specification: This specification		Published Specification: This specification
	Applications which use this media type: load control of SIP entities		Applications which use this media type: load control of SIP entities
	Additional information:		Additional information:
	Magic number: None		Magic number: None
	File extension: .xml		File extension: .xml
	Macintosh file type code: 'TEXT'		Macintosh file type code: 'TEXT'
	Personal and email address for further information:		Personal and email address for further information:
	Charles Shen, charles@cs.columbia.edu		Charles Shen, charles@cs.columbia.edu
	Intended usage: COMMON		Intended usage: COMMON
	Author/Change Controller: IETF SOC Working Group <sip-		Author/Change Controller: IETF SOC Working Group <sip-
	overload@ietf.org>, as designated by the IESG <iesg@ietf.org>		overload@ietf.org>, as designated by the IESG <iesg@ietf.org>
	12.3. Load Control Schema Registration		12.3. URN Sub-Namespace Registration
			This section registers a new XML namespace, as per the guidelines in
			[RFC3688]
			URI: The URI for this namespace is
			urn:ietf:params:xml:ns:load-control
			Registrant Contact: IETF SOC Working Group <sip-overload@ietf.org>,
			as designated by the IESG <iesg@ietf.org>
			XML:
			BEGIN
			<?xml version="1.0"?>
			<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
			"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
			<html xmlns="http://www.w3.org/1999/xhtml">
			<head>
			<meta http-equiv="content-type"
			content="text/html;charset=iso-8859-1"/>
			<title>SIP Load Control Namespace</title>
			</head>
			<body>
			<h1>Namespace for SIP Load Control</h1>
			<h2>urn:ietf:params:xml:ns:load-control</h2>
			<p>See <a href="http://www.rfc-editor.org/rfc/rfc[?].txt">
			RFC[?]</a>.</p>
			</body>
			</html>
			END
			12.4. Load Control Schema Registration
	URI: urn:ietf:params:xml:schema:load-control		URI: urn:ietf:params:xml:schema:load-control
	Registrant Contact: IETF SOC working group, Charles Shen		Registrant Contact: IETF SOC working group, Charles Shen
	(charles@cs.columbia.edu).		(charles@cs.columbia.edu).
	XML: the XML schema to be registered is contained in Section 8.		XML: the XML schema to be registered is contained in Section 8.
	Its first line is		Its first line is
	skipping to change at page 39, line 51 ¶		skipping to change at page 40, line 31 ¶
	and its last line is		and its last line is
	</xs:schema>		</xs:schema>
	13. Acknowledgements		13. Acknowledgements
	The authors would like to thank Richard Barnes, Bruno Chatras, Martin		The authors would like to thank Richard Barnes, Bruno Chatras, Martin
	Dolly, Keith Drage, Ashutosh Dutta, Janet Gunn, Vijay Gurbani, Volker		Dolly, Keith Drage, Ashutosh Dutta, Janet Gunn, Vijay Gurbani, Volker
	Hilt, Geoff Hunt, Carolyn Johnson, Hadriel Kaplan, Paul Kyzivat,		Hilt, Geoff Hunt, Carolyn Johnson, Hadriel Kaplan, Paul Kyzivat,
	Salvatore Loreto, Timothy Moran, Eric Noel, Parthasarathi R, Adam		Pearl Liang, Salvatore Loreto, Timothy Moran, Eric Noel,
	Roach, Shida Schubert, Robert Sparks, Phil Williams and other members		Parthasarathi R, Adam Roach, Dan Romascanu, Shida Schubert, Robert
	of the SOC and SIPPING working group for many helpful comments. In		Sparks, Phil Williams and other members of the SOC and SIPPING
	particular, Bruno Chatras proposed the <method> and <target-sip-		working group for many helpful comments. In particular, Bruno
	entity> condition elements along with many other text improvements.		Chatras proposed the <method> and <target-sip-entity> condition
	Janet Gunn provided detailed text suggestions including Section 10.		elements along with many other text improvements. Janet Gunn
	Eric Noel suggested clarification on load filtering policy		provided detailed text suggestions including Section 10. Eric Noel
	distribution initialization process. Shida Schubert made many		suggested clarification on load filtering policy distribution
	suggestions such as terminology usage. Phil Williams suggested		initialization process. Shida Schubert made many suggestions such as
	adding support for delta updates. Ashutosh Dutta gave pointers to		terminology usage. Phil Williams suggested adding support for delta
	PSTN references. Adam Roach suggested RFC6665-related and other		updates. Ashutosh Dutta gave pointers to PSTN references. Adam
	helpful clarifications. Richard Barnes made many suggestions such as		Roach suggested RFC6665-related and other helpful clarifications.
	referencing the Trust Domain concept of RFC3324, the use of a		Richard Barnes made many suggestions such as referencing the Trust
	separate element for 'tel' URI grouping and addressing the "redirect"		Domain concept of RFC3324, the use of a separate element for 'tel'
	action security threat.		URI grouping and addressing the "redirect" action security threat.
	14. References		14. References
	14.1. Normative References		14.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.
	[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.		[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
	skipping to change at page 41, line 9 ¶		skipping to change at page 41, line 37 ¶
	[RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665,		[RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665,
	July 2012.		July 2012.
	[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type		[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
	Specifications and Registration Procedures", BCP 13, RFC		Specifications and Registration Procedures", BCP 13, RFC
	6838, January 2013.		6838, January 2013.
	14.2. Informative References		14.2. Informative References
	[E.300SerSup3]		[E.300SerSup3]
	ITU-T, ., "North American Precise Audible Tone Plan",		ITU-T, , "North American Precise Audible Tone Plan", E.300
	E.300 Series Supplement 3 , November 1988.		Series Supplement 3 , November 1988.
	[E.412] ITU-T, ., "Network Management Controls", E.412-2003 ,		[E.412] ITU-T, , "Network Management Controls", E.412-2003 ,
	January 2003.		January 2003.
	[I-D.ietf-soc-overload-control]		[I-D.ietf-soc-overload-control]
	Gurbani, V., Hilt, V., and H. Schulzrinne, "Session		Gurbani, V., Hilt, V., and H. Schulzrinne, "Session
	Initiation Protocol (SIP) Overload Control", draft-ietf-		Initiation Protocol (SIP) Overload Control", draft-ietf-
	soc-overload-control-13 (work in progress), May 2013.		soc-overload-control-13 (work in progress), May 2013.
	[Q.1248.2]		[Q.1248.2]
	ITU-T, ., "Interface Recommendation for Intelligent		ITU-T, , "Interface Recommendation for Intelligent Network
	Network Capability Set4:SCF-SSF interface", Q.1248.2 ,		Capability Set4:SCF-SSF interface", Q.1248.2 , July 2001.
	July 2001.
	[RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,		[RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
	August 1999.		August 1999.
	[RFC3324] Watson, M., "Short Term Requirements for Network Asserted		[RFC3324] Watson, M., "Short Term Requirements for Network Asserted
	Identity", RFC 3324, November 2002.		Identity", RFC 3324, November 2002.
	[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource		[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource
	Priority for the Session Initiation Protocol (SIP)", RFC		Priority for the Session Initiation Protocol (SIP)", RFC
	4412, February 2006.		4412, February 2006.
End of changes. 19 change blocks.
	56 lines changed or deleted		90 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/