draft-ietf-netconf-notification-05.txt		draft-ietf-netconf-notification-06.txt
	Network Working Group S. Chisholm		Network Working Group S. Chisholm
	Internet-Draft Nortel		Internet-Draft Nortel
	Intended status: Standards Track H. Trevino		Intended status: Standards Track H. Trevino
	Expires: June 22, 2007 Cisco		Expires: August 24, 2007 Cisco
	December 19, 2006		February 20, 2007
	NETCONF Event Notifications		NETCONF Event Notifications
	draft-ietf-netconf-notification-05.txt		draft-ietf-netconf-notification-06.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 35		skipping to change at page 1, line 35
	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 June 22, 2007.		This Internet-Draft will expire on August 24, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document defines mechanisms which provide an asynchronous		This document defines mechanisms which provide an asynchronous
	message notification delivery service for the NETCONF protocol. This		message notification delivery service for the NETCONF protocol. This
	is an optional capability built on top of the base NETCONF		is an optional capability built on top of the base NETCONF
	definition. This document defines the capabilities and operations		definition. This document defines the capabilities and operations
	necessary to support this service.		necessary to support this service.
	Table of Contents		Table of Contents
	skipping to change at page 3, line 28		skipping to change at page 3, line 28
	3. Supporting Concepts . . . . . . . . . . . . . . . . . . . . . 10		3. Supporting Concepts . . . . . . . . . . . . . . . . . . . . . 10
	3.1. Capabilities Exchange . . . . . . . . . . . . . . . . . . 10		3.1. Capabilities Exchange . . . . . . . . . . . . . . . . . . 10
	3.1.1. Capability Identifier . . . . . . . . . . . . . . . . 10		3.1.1. Capability Identifier . . . . . . . . . . . . . . . . 10
	3.1.2. Capability Example . . . . . . . . . . . . . . . . . . 10		3.1.2. Capability Example . . . . . . . . . . . . . . . . . . 10
	3.2. Event Streams . . . . . . . . . . . . . . . . . . . . . . 10		3.2. Event Streams . . . . . . . . . . . . . . . . . . . . . . 10
	3.2.1. Event Stream Definition . . . . . . . . . . . . . . . 11		3.2.1. Event Stream Definition . . . . . . . . . . . . . . . 11
	3.2.2. Event Stream Content Format . . . . . . . . . . . . . 11		3.2.2. Event Stream Content Format . . . . . . . . . . . . . 11
	3.2.3. Default Event Stream . . . . . . . . . . . . . . . . . 11		3.2.3. Default Event Stream . . . . . . . . . . . . . . . . . 11
	3.2.4. Event Stream Sources . . . . . . . . . . . . . . . . . 12		3.2.4. Event Stream Sources . . . . . . . . . . . . . . . . . 12
	3.2.5. Event Stream Discovery . . . . . . . . . . . . . . . . 12		3.2.5. Event Stream Discovery . . . . . . . . . . . . . . . . 12
	3.2.6. Event Stream Subscription . . . . . . . . . . . . . . 15		3.3. Notification Management Schema . . . . . . . . . . . . . . 13
	3.3. Subscriptions not Configuration Data . . . . . . . . . . . 15		3.4. Subscriptions not Configuration Data . . . . . . . . . . . 16
	3.4. Filter Dependencies . . . . . . . . . . . . . . . . . . . 15		3.5. Filter Dependencies . . . . . . . . . . . . . . . . . . . 17
	3.4.1. Named Profiles . . . . . . . . . . . . . . . . . . . . 15		3.5.1. Named Profiles . . . . . . . . . . . . . . . . . . . . 17
	3.4.2. Filtering . . . . . . . . . . . . . . . . . . . . . . 16		3.5.2. Filtering . . . . . . . . . . . . . . . . . . . . . . 17
	3.5. Message Flow . . . . . . . . . . . . . . . . . . . . . . . 16		3.6. Message Flow . . . . . . . . . . . . . . . . . . . . . . . 17
	4. XML Schema for Event Notifications . . . . . . . . . . . . . . 17		4. XML Schema for Event Notifications . . . . . . . . . . . . . . 19
	5. Filtering examples . . . . . . . . . . . . . . . . . . . . . . 20		5. Filtering examples . . . . . . . . . . . . . . . . . . . . . . 22
	5.1. Subtree Filtering . . . . . . . . . . . . . . . . . . . . 20		5.1. Subtree Filtering . . . . . . . . . . . . . . . . . . . . 22
	5.2. XPATH filters . . . . . . . . . . . . . . . . . . . . . . 21		5.2. XPATH filters . . . . . . . . . . . . . . . . . . . . . . 25
	6. Notification Replay . . . . . . . . . . . . . . . . . . . . . 23		6. Notification Replay . . . . . . . . . . . . . . . . . . . . . 27
	6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 23		6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 27
	6.2. Creating a Subscription with Replay . . . . . . . . . . . 23		6.2. Creating a Subscription with Replay . . . . . . . . . . . 27
	6.3. Replay Complete Notification . . . . . . . . . . . . . . . 24		6.3. Replay Complete Notification . . . . . . . . . . . . . . . 28
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 26		7. Security Considerations . . . . . . . . . . . . . . . . . . . 30
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
	9. Normative References . . . . . . . . . . . . . . . . . . . . . 28		9. Normative References . . . . . . . . . . . . . . . . . . . . . 32
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
	Intellectual Property and Copyright Statements . . . . . . . . . . 30		Intellectual Property and Copyright Statements . . . . . . . . . . 34
	1. Introduction		1. Introduction
	[NETCONF] can be conceptually partitioned into four layers:		[NETCONF] can be conceptually partitioned into four layers:
	Layer Example		Layer Example
	+-------------+ +----------------------------------------+		+-------------+ +----------------------------------------+
	| Content | | Configuration data |		| Content | | Configuration data |
	+-------------+ +----------------------------------------+		+-------------+ +----------------------------------------+
	| |		| |
	skipping to change at page 5, line 34		skipping to change at page 5, line 34
	notifications to the NETCONF client as the events occur within the		notifications to the NETCONF client as the events occur within the
	system. These event notifications will continue to be sent until		system. These event notifications will continue to be sent until
	either the NETCONF session is terminated or the subscription to		either the NETCONF session is terminated or the subscription to
	terminate for some other reason. The event notification subscription		terminate for some other reason. The event notification subscription
	allows a number of options to enable the NETCONF client to specify		allows a number of options to enable the NETCONF client to specify
	which events are of interest. These are specified when the		which events are of interest. These are specified when the
	subscription is created.		subscription is created.
	An NETCONF server is not required to process RPC requests on the		An NETCONF server is not required to process RPC requests on the
	session associated with the subscription until the notification		session associated with the subscription until the notification
	subscription is done. A capability may be advertised to announce		subscription is done and may silently discard these requests. A
	that a server is able to process RPCs while a notification stream is		capability may be advertised to announce that a server is able to
	active on a session.		process RPCs while a notification stream is active on a session.
	1.3. Motivation		1.3. Motivation
	The motivation for this work is to enable the sending of asynchronous		The motivation for this work is to enable the sending of asynchronous
	messages that are consistent with the data model (content) and		messages that are consistent with the data model (content) and
	security model used within a NETCONF implementation.		security model used within a NETCONF implementation.
	1.4. Requirements		1.4. Requirements
	The following requirements have been addressed by the solution:		The following requirements have been addressed by the solution:
	skipping to change at page 8, line 41		skipping to change at page 8, line 41
	Once the subscription has been set up, the NETCONF server sends the		Once the subscription has been set up, the NETCONF server sends the
	event notifications asynchronously along the connection.		event notifications asynchronously along the connection.
	2.2.1. <notification>		2.2.1. <notification>
	Description:		Description:
	An event notification is sent to the initiator of a <create-		An event notification is sent to the initiator of a <create-
	subscription> command asynchronously when an event of interest		subscription> command asynchronously when an event of interest
	(i.e. meeting the specified filtering criteria) to them has		(i.e. meeting the specified filtering criteria) to them has
	occurred. An event notification is a complete XML document. Note		occurred. An event notification is a complete and well-formed XML
	that <notification> is not an RPC method but rather the top level		document. Note that <notification> is not an RPC method but
	element identifying the one way message as a notification.		rather the top level element identifying the one way message as a
			notification.
	Parameters:		Parameters:
	Data:		Data:
	Contains notification-specific tagged content.		Contains notification-specific tagged content.
	Response:		Response:
	No response. Not applicable.		No response. Not applicable.
	2.3. Terminating the Subscription		2.3. Terminating the Subscription
	Closing of the event notification subscription can be done by		Closing of the event notification subscription can be done by
	terminating the NETCONF session ( <kill-session> ).		terminating the NETCONF session ( <kill-session> ) or the underlying
			transport session. If a stop time is provided when the subscription
			is created, then the subscription will terminate after the stop time
			is reached. In this case, the Netconf session will still be an
			active session.
	3. Supporting Concepts		3. Supporting Concepts
	3.1. Capabilities Exchange		3.1. Capabilities Exchange
	The ability to process and send event notifications is advertised		The ability to process and send event notifications is advertised
	during the capability exchange between the NETCONF client and server.		during the capability exchange between the NETCONF client and server.
	3.1.1. Capability Identifier		3.1.1. Capability Identifier
	skipping to change at page 12, line 29		skipping to change at page 12, line 29
	The list of available event streams is retrieved by requesting the		The list of available event streams is retrieved by requesting the
	<eventStreams> subtree via a <get>operation. Available event streams		<eventStreams> subtree via a <get>operation. Available event streams
	for the requesting session are returned in the reply containing the		for the requesting session are returned in the reply containing the
	<name> and <description> elements, where <name> element is mandatory		<name> and <description> elements, where <name> element is mandatory
	and its value is unique. The returned list must only include the		and its value is unique. The returned list must only include the
	names of those event streams for which the NETCONF session has		names of those event streams for which the NETCONF session has
	sufficient privileges. The NETCONF session privileges are determined		sufficient privileges. The NETCONF session privileges are determined
	via access control mechanisms which are beyond the scope of this		via access control mechanisms which are beyond the scope of this
	document. An empty reply is returned if there are no available event		document. An empty reply is returned if there are no available event
	streams.		streams. The information is retrieved by requesting the
	The list of all event streams configured on a device may be retrieved
	over a NETCONF session with sufficient privileges (e.g.
	administrator). The information is retrieved by requesting the
	<eventStreams> subtree via a <get> operation.		<eventStreams> subtree via a <get> operation.
	Example: Retrieving available event stream list using <get>		Example: Retrieving available event stream list using <get>
	operation:		operation:
	<rpc message-id="101"		<rpc message-id="101"
	xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">		xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
	<get>		<get>
	<filter type="subtree">		<filter type="subtree">
	skipping to change at page 13, line 32		skipping to change at page 13, line 32
	<stream>		<stream>
	<name>syslog-critical</name>		<name>syslog-critical</name>
	<description>Critical and higher severity		<description>Critical and higher severity
	</description>		</description>
	<replaySupport>true</replaySupport>		<replaySupport>true</replaySupport>
	</stream>		</stream>
	</eventStreams>		</eventStreams>
	</data>		</data>
	</rpc-reply>		</rpc-reply>
	3.2.5.2. Stream Retrieval Schema		3.2.5.2. Event Stream Subscription
			A NETCONF client may request from the NETCONF server the list of
			available event streams to this session and then issue a <create-
			subscription> request with the desired event stream name. Omitting
			the event stream name from the <create-subscription> request results
			in subscription to the default NETCONF event stream.
			3.2.5.2.1. Filtering Event Stream Contents
			The set of event notifications delivered in an event stream may be
			further refined by applying a user-specified filter at subscription
			creation time ( <create-subscription> ). This is a transient filter
			associated with the event notification subscription and does not
			modify the event stream configuration.
			3.3. Notification Management Schema
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"		<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
	xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"		xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"
			xmlns:ncEvent="urn:ietf:params:xml:ns:netconf:notification:1.0"
			xmlns:manageEvent="urn:ietf:params:xml:ns:netmod:event:1.0"
			targetNamespace="urn:ietf:params:xml:ns:netmod:event:1.0"
	elementFormDefault="qualified"		elementFormDefault="qualified"
	attributeFormDefault="unqualified">		attributeFormDefault="unqualified">
	<xs:annotation>		<xs:annotation>
	<xs:documentation xml:lang="en">		<xs:documentation xml:lang="en">
	Schema for event streams
	</xs:documentation>
	<xs:appinfo>
	<nm:identity
	xmlns:nm="urn:ietf:params:xml:ns:netmod:base:1.0">
	<nm:Name>
	NetconfNotificationSchema
	</nm:Name>
	<nm:LastUpdated>
	2006-09-06T09:30:47-05:00
	</nm:LastUpdated>
	<nm:Organization>IETF
	</nm:Organization>
	<nm:Description>
	A schema that can be used to learn about current		A schema that can be used to learn about current
	event streams.		event streams and to manage named profiles.
	</nm:Description>		</xs:documentation>
	</nm:identity>
	</xs:appinfo>
	</xs:annotation>		</xs:annotation>
	<xs:import namespace="http://www.w3.org/XML/1998/namespace"		<xs:import namespace="http://www.w3.org/XML/1998/namespace"
	schemaLocation="http://www.w3.org/2001/xml.xsd"/>		schemaLocation="http://www.w3.org/2001/xml.xsd"/>
	<xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"		<xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"
	schemaLocation="./draft-ietf-netconf-prot-12.xsd"/>		schemaLocation="urn:ietf:params:xml:ns:netconf:base:1.0"/>
			<xs:import
			namespace="urn:ietf:params:xml:ns:netconf:notification:1.0"
			schemaLocation=
			"urn:ietf:params:xml:ns:netconf:notification:1.0"/>
	<xs:element name="eventStreams" >		<xs:element name="eventStreams" >
	<xs:annotation>		<xs:annotation>
	<xs:documentation>		<xs:documentation>
	The list of event streams supported by the system.		The list of event streams supported by the system.
	When a query is issued, the returned set of streams is		When a query is issued, the returned set of streams is
	determined based on user privileges		determined based on user privileges
	</xs:documentation>		</xs:documentation>
	</xs:annotation>		</xs:annotation>
	<xs:complexType>		<xs:complexType>
	skipping to change at page 14, line 42		skipping to change at page 14, line 49
	<xs:element name="stream">		<xs:element name="stream">
	<xs:annotation>		<xs:annotation>
	<xs:documentation>		<xs:documentation>
	Stream name and description		Stream name and description
	</xs:documentation>		</xs:documentation>
	</xs:annotation>		</xs:annotation>
	<xs:complexType>		<xs:complexType>
	<xs:sequence>		<xs:sequence>
	<xs:element name="name" type="xs:string"/>		<xs:element name="name" type="xs:string"/>
	<xs:element name="description" type="xs:string"/>		<xs:element name="description" type="xs:string"/>
	<xs:element name="replaySupport" type="xs:boolean"/>		<xs:element name="replaySupport"
			type="xs:boolean"/>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	</xs:element>		</xs:element>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	</xs:element>		</xs:element>
	</xs:schema>
	3.2.6. Event Stream Subscription		<xs:element name="namedProfile">
			<xs:annotation>
			<xs:documentation>
			A named profile, which is a saved set of parameters
			associated that may be associated with zero or more
			active subscriptions.
	A NETCONF client may request from the NETCONF server the list of		This object can be created, read, deleted and its
	available event streams to this session and then issue a <create-		individual components can be modified.
	subscription> request with the desired event stream name. Omitting		</xs:documentation>
	the event stream name from the <create-subscription> request results		</xs:annotation>
	in subscription to the default NETCONF event stream.		<xs:complexType>
			<xs:sequence>
	3.2.6.1. Filtering Event Stream Contents		<xs:element name="name">
			<xs:annotation>
			<xs:documentation>
			The name associated with the profile.
	The set of event notifications delivered in an event stream may be		This object is readable and modifiable.
	further refined by applying a user-specified filter at subscription		</xs:documentation>
	creation time ( <create-subscription> ). This is a transient filter		</xs:annotation>
	associated with the event notification subscription and does not		</xs:element>
	modify the event stream configuration.
	3.3. Subscriptions not Configuration Data		<xs:element name="stream" minOccurs="0">
			<xs:annotation>
			<xs:documentation xml:lang="en">
			The event stream associated with this named
			profile.
	While it is possible to retrieve information about subscriptions via		This object is readable and modifiable.
	a get operation, subscriptions are not stored configuration. They		</xs:documentation>
	are non-persistent state information. In this respect, they are		</xs:annotation>
			</xs:element>
			<xs:element name="filter"
			type="netconf:filterInlineType" minOccurs="0">
			<xs:annotation>
			<xs:documentation xml:lang="en">
			The filters associated with this named
			profile.
			This object is readable and modifiable.
			</xs:documentation>
			</xs:annotation>
			</xs:element>
			<xs:element name="lastModified" type="xs:dateTime">
			<xs:annotation>
			<xs:documentation>
			The timestamp of the last modification to this
			named Profile. Note that modification of the
			profile does not cause an immediate update
			to all applicable subscription. Therefore,
			this time should be compared with the last
			modified time associated with the
			subscription. If this time is earlier, then
			the subscription is using the exact set of
			parameters associated with this named profile.
			If this time is later, then the subscription
			is using an earlier version of this named
			profile and the exact parameters may not
			match.
			This object is read-only.
			</xs:documentation>
			</xs:annotation>
			</xs:element>
			</xs:sequence>
			</xs:complexType>
			</xs:element>
			<xs:element name="namedProfiles">
			<xs:complexType>
			<xs:sequence>
			<xs:element ref="manageEvent:namedProfile" minOccurs="0"
			maxOccurs="unbounded" />
			</xs:sequence>
			</xs:complexType>
			</xs:element>
			</xs:schema>
			3.4. Subscriptions not Configuration Data
			While it may be possible to retrieve information about subscriptions
			via a get operation, subscriptions are not stored configuration.
			They are non-persistent state information. In this respect, they are
	comparable to NETCONF sessions.		comparable to NETCONF sessions.
	Named profiles, if used, are considered configuration data.		Named profiles, if used, are considered configuration data.
	3.4. Filter Dependencies		3.5. Filter Dependencies
	Note that when multiple filters are specified, they are applied		Note that when multiple filters are specified, they are applied
	collectively, so event notifications need to pass all specified		collectively, so event notifications need to pass all specified
	filters in order to be sent to the subscriber. If a filter is		filters in order to be sent to the subscriber. If a filter is
	specified to look for data of a particular value, and the data item		specified to look for data of a particular value, and the data item
	is not present within a particular event notification for its value		is not present within a particular event notification for its value
	to be checked against, it will be filtered out. For example, if one		to be checked against, it will be filtered out. For example, if one
	were to check for 'severity=critical' in a configuration event		were to check for 'severity=critical' in a configuration event
	notification where this field was not supported, then the		notification where this field was not supported, then the
	notification would be filtered out.		notification would be filtered out.
	Note that the order that filters are applied does not matter since		Note that the order that filters are applied does not matter since
	the resulting set of notifications is the intersection of the set of		the resulting set of notifications is the intersection of the set of
	notifications that pass each filtering criteria.		notifications that pass each filtering criteria.
	3.4.1. Named Profiles		3.5.1. Named Profiles
	A named profile is a filter that is created ahead of time and applied		A named profile is a filter that is created ahead of time and applied
	at the time an event notification subscription is created . Note		at the time an event notification subscription is created . Note
	that changes to the profile after the subscription has been created		that changes to the profile after the subscription has been created
	will have no effect on the subscription. Since named profiles exist		will have no effect on the subscription. Since named profiles exist
	outside of the subscription, they persist after the subscription has		outside of the subscription, they persist after the subscription has
	been torn down.		been torn down.
	3.4.2. Filtering		3.5.2. Filtering
	Just-in-time filtering is explicitly stated when the event		Just-in-time filtering is explicitly stated when the event
	notification subscription is created. This is specified via the		notification subscription is created. This is specified via the
	'filter' parameter. Filters only exist as parameters to the		'filter' parameter. Filters only exist as parameters to the
	subscription.		subscription.
	3.5. Message Flow		3.6. Message Flow
	The following figure depicts message flow between a NETCONF client		The following figure depicts message flow between a NETCONF client
	(C) and NETCONF server (S) in order create a subscription and begin		(C) and NETCONF server (S) in order create a subscription and begin
	the flow of notifications.		the flow of notifications.
	C S		C S
	| |		| |
	| capability exchange |		| capability exchange |
	|-------------------------->|		|-------------------------->|
	|<------------------------->|		|<------------------------->|
	| |		| |
	skipping to change at page 17, line 7		skipping to change at page 19, line 7
	| |		| |
	| |		| |
	| |		| |
	| <notification> |		| <notification> |
	|<--------------------------|		|<--------------------------|
	| |		| |
	| |		| |
	4. XML Schema for Event Notifications		4. XML Schema for Event Notifications
			The following [XML Schema] defines Netconf Event Notifications.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"		<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
	xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"		xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"
	xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"		xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"
	targetNamespace="urn:ietf:params:xml:ns:netconf:notification:1.0"		targetNamespace="urn:ietf:params:xml:ns:netconf:notification:1.0"
	elementFormDefault="qualified"		elementFormDefault="qualified"
	attributeFormDefault="unqualified"		attributeFormDefault="unqualified"
	xml:lang="en">		xml:lang="en">
	<!-- import standard XML definitions -->		<!-- import standard XML definitions -->
	skipping to change at page 20, line 22		skipping to change at page 22, line 22
	XML subtree filtering is not well suited for creating elaborate		XML subtree filtering is not well suited for creating elaborate
	filter definitions given that it only supports equality comparisons		filter definitions given that it only supports equality comparisons
	and logical OR operations (e.g. in an event subtree give me all event		and logical OR operations (e.g. in an event subtree give me all event
	notifications which have severity=critical or severity=major or		notifications which have severity=critical or severity=major or
	severity=minor). Nevertheless, it may be used for defining simple		severity=minor). Nevertheless, it may be used for defining simple
	event notification forwarding filters as shown below.		event notification forwarding filters as shown below.
	In order to illustrate the use of filter expressions it is necessary		In order to illustrate the use of filter expressions it is necessary
	to assume some of the event notification content. The examples		to assume some of the event notification content. The examples
	herein assume that the event notification schema definition has an		herein assume that the event notification schema definition has an
	<eventClasses> element identifying the event category (e.g. fault,		<events> element at the top level that contains one or more child
	state, config, etc.) and events have a <severity> element.		elements <eventEntry> consisting of the event class (e.g. fault,
			state, config, etc.) reporting entity and either severity or
			operational state.
			Sample event list
			<events>
			<eventEntry>
			<eventClass>fault</eventClass>
			<reportingEntity>
			<card>Ethernet0</card>
			</reportingEntity>
			<severity>major</severity>
			</eventEntry>
			<eventEntry>
			<eventClass>fault</eventClass>
			<reportingEntity>
			<card>Ethernet2</card>
			</reportingEntity>
			<severity>critical</severity>
			</eventEntry>
			<eventEntry>
			<eventClass>fault</eventClass>
			<reportingEntity>
			<card>ATM1</card>
			</reportingEntity>
			<severity>minor</severity>
			</eventEntry>
			<eventEntry>
			<eventClass>state</eventClass>
			<reportingEntity>
			<card>Ethernet0</card>
			</reportingEntity>
			<operState>enabled</operState>
			</eventEntry>
			</events>
	The following example illustrates selecting events which have		The following example illustrates selecting events which have
	severities of critical, major, or minor (presumably fault events).		severities of critical, major, or minor (presumably fault events).
	The filtering criteria evaluation is as follows:		The filtering criteria evaluation is as follows:
	((severity=critical) | (severity=major) | (severity=minor))		((severity=critical) | (severity=major) | (severity=minor))
	<rpc message-id="101"		<rpc message-id="101"
	xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">		xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
	<create-subscription		<create-subscription
	xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">		xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
	<netconf:filter type="subtree">		<netconf:filter type="subtree">
	<event xmlns="http://example.com/event/1.0">		<event xmlns="http://example.com/event/1.0">
	<severity>critical</severity>		<severity>critical</severity>
	</event>		</event>
	<event xmlns="http://example.com/event/1.0">		<event xmlns="http://example.com/event/1.0">
	<severity>major</severity>		<severity>major</severity>
	skipping to change at page 20, line 49		skipping to change at page 24, line 22
	<event xmlns="http://example.com/event/1.0">		<event xmlns="http://example.com/event/1.0">
	<severity>major</severity>		<severity>major</severity>
	</event>		</event>
	<event xmlns="http://example.com/event/1.0">		<event xmlns="http://example.com/event/1.0">
	<severity>minor</severity>		<severity>minor</severity>
	</event>		</event>
	</netconf:filter>		</netconf:filter>
	</create-subscription>		</create-subscription>
	</rpc>		</rpc>
	The following example illustrates selecting fault, state, config		The following example illustrates selecting state or config
	EventClasses or events which are related to card Ethernet0. The		EventClasses or fault events that are related to card Ethernet0. The
	filtering criteria evaluation is as follows:		filtering criteria evaluation is as follows:
	(fault | state | config | card=Ethernet0)		( state | config | fault & card=Ethernet0)
	<rpc message-id="101"		<rpc message-id="101"
	xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">		xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
	<create-subscription>		<create-subscription>
	<netconf:filter type="subtree">		<netconf:filter type="subtree">
	xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">		xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
	<event xmlns="http://example.com/event/1.0">		<event xmlns="http://example.com/event/1.0">
	<eventClasses>fault</eventClasses>		<events>
	</event>		<eventEntry>
	<event xmlns="http://example.com/event/1.0">		<eventClass>fault</eventClass>
	<eventClasses>state</eventClasses>		</eventEntry>
	</event>		<eventEntry>
	<event xmlns="http://example.com/event/1.0">		<eventClass>state</eventClass>
	<eventClasses>config</eventClasses>		</eventEntry>
	</event>		<eventEntry>
	<event xmlns="http://example.com/event/1.0">		<eventClass>config</eventClass>
			</eventEntry>
			<eventEntry>
			<eventClass>fault</eventClass>
			<reportingElement>
	<card>Ethernet0</card>		<card>Ethernet0</card>
			</reportingElement>
			</eventEntry>
			</events>
	</event>		</event>
	</netconf:filter>		</netconf:filter>
	</create-subscription>		</create-subscription>
	</rpc>		</rpc>
	5.2. XPATH filters		5.2. XPATH filters
	The following example illustrates selecting fault EventClass		The following [XPATH] example illustrates selecting fault EventClass
	notifications that have severities of critical, major, or minor. In		notifications that have severities of critical, major, or minor. The
	this example, neb represents the namespace for the event definitions		filtering criteria evaluation is as follows:
	schema. The filtering criteria evaluation is as follows:
	((fault) & ((severity=critical) | (severity=major) | (severity =		((fault) & ((severity=critical) | (severity=major) | (severity =
	minor)))		minor)))
	<rpc message-id="101"		<rpc message-id="101"
	xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">		xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
	<create-subscription>		<create-subscription>
	<netconf:filter type="xpath"		<netconf:filter type="xpath"
	select="/neb:event/eventClasses/fault' and		select="event/eventClasses/fault' and
	(/neb:event[severity='critical'] or		(event[severity='critical'] or
	/neb:event[severity='major'] or		event[severity='major'] or
	/neb:event[severity='minor')))"/>		event[severity='minor')))"/>
	</create-subscription>		</create-subscription>
	</rpc>		</rpc>
	The following example illustrates selecting fault, state and config		The following example illustrates selecting state and config
	EventClasses which have severities of critical, major, or minor and		EventClasses or fault events that have severities of critical, major,
	come from card Ethernet0. The filtering criteria evaluation is as		or minor or come from card Ethernet0. The filtering criteria
	follows:		evaluation is as follows:
	((fault | state | config) & ((fault & severity=critical) | (fault &		(( state | config) & ((fault & severity=critical) | (fault &
	severity=major) | (fault & severity = minor) | (card=Ethernet0)))		severity=major) | (fault & severity = minor) | (fault &
			card=Ethernet0)))
	<rpc message-id="101"		<rpc message-id="101"
	xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">		xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
	<create-subscription>		<create-subscription>
	<netconf:filter type="xpath"		<netconf:filter type="xpath"
	select="((/neb:event[eventClasses/fault] or		select="((event[eventClasses/fault] or
	/neb:event[eventClasses/state] or		event[eventClasses/state] or
	/neb:event[eventClasses/config]) and		event[eventClasses/config]) and
	( (/neb:event[eventClasses/fault] and		((event[eventClasses/fault] and
	/neb:event[severity='critical']) or		event[severity='critical']) or
	(/neb:event[eventClasses/fault] and		(event[eventClasses/fault] and
	/neb:event[severity='major']) or		event[severity='major']) or
	(/neb:event[eventClasses/fault] and		(event[eventClasses/fault] and
	/neb:event[severity='minor']) or		event[severity='minor']) or
	/neb:event[card='Ethernet0']))"/>		event[eventClasses/fault/reportingElement/card='Ethernet0']))"/>
	</create-subscription>		</create-subscription>
	</rpc>		</rpc>
	6. Notification Replay		6. Notification Replay
	6.1. Overview		6.1. Overview
	Replay is the ability to create an event subscription that will		Replay is the ability to create an event subscription that will
	resend recently sent notifications. These notifications are sent the		resend recently sent notifications. These notifications are sent the
	same way as normal notifications.		same way as normal notifications.
	skipping to change at page 24, line 8		skipping to change at page 28, line 8
	matched. 'stopTime' specifies the latest date and time of interest		matched. 'stopTime' specifies the latest date and time of interest
	for event notifications being replayed. If it is not present, then		for event notifications being replayed. If it is not present, then
	notifications will continue to be sent until the subscription is		notifications will continue to be sent until the subscription is
	terminated.		terminated.
	Note that while a notification has three potential times associated		Note that while a notification has three potential times associated
	it - the time it was generated, the time it was logged and the time		it - the time it was generated, the time it was logged and the time
	it was sent out by the NETCONF server - the startTime and stopTime		it was sent out by the NETCONF server - the startTime and stopTime
	parameters are related to generation time.		parameters are related to generation time.
			In the event of an error with severity of warning, the subscription
			will still be created.
	Negative Response:		Negative Response:
	An <rpc-error> element is included in the <rpc-reply> if the		An <rpc-error> element is included in the <rpc-reply> if the
	startTime in replay request predates the oldest notification		startTime in replay request predates the oldest notification
	available to be replayed or if the stopTime is earlier then the		available to be replayed or if the stopTime is earlier then the
	startTime.		startTime.
	Error-tag: start-time-too-early		Error-tag: start-time-too-early
	Error-type: protocol		Error-type: protocol
	Error-severity: warning		Error-severity: warning
	Error-info: none		Error-info: <log-startime> : Timestamp of earliest event
			available for replay
	Error-message: Start time predates oldest available		Error-message: Start time predates oldest available
	notification to be replayed		notification to be replayed
	Error-tag: start-stop-time-mismatch		Error-tag: start-stop-time-mismatch
	Error-type: protocol		Error-type: protocol
	Error-severity: warning		Error-severity: error
	Error-info: none		Error-info: none
	Error-message: stopTime predates startTime.		Error-message: stopTime predates startTime.
	6.3. Replay Complete Notification		6.3. Replay Complete Notification
	The following notification is the last notification sent over a		The following notification is the last notification sent over a
	replay subscription. It indicates that replay is complete. This		replay subscription. It indicates that replay is complete. This
	notification will only be sent if a 'stopTime' was specified when the		notification will only be sent if a 'stopTime' was specified when the
	replay subscription was created.		replay subscription was created. After this notification is received
			the subscription is terminated and the session becomes a normal
			Netconf session.
			The replayCompleteNotifcation can not be filtered out. It will
			always be sent on a relay subscription that specified a stop time.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"		<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
	xmlns="urn:ietf:params:xml:ns:netconf:replayNotification:1.0"		xmlns="urn:ietf:params:xml:ns:netconf:replayNotification:1.0"
	targetNamespace=		targetNamespace=
	"urn:ietf:params:xml:ns:netconf:replayNotification:1.0">		"urn:ietf:params:xml:ns:netconf:replayNotification:1.0">
	<xs:element name="replayCompleteNotification" >		<xs:element name="replayCompleteNotification" >
	<xs:annotation>		<xs:annotation>
	<xs:documentation>		<xs:documentation>
	skipping to change at page 27, line 17		skipping to change at page 31, line 17
	Thanks to Gilbert Gagnon, Greg Wilbur and Kim Curran for providing		Thanks to Gilbert Gagnon, Greg Wilbur and Kim Curran for providing
	their input into the early work on this document. In addition, the		their input into the early work on this document. In addition, the
	editors would like to acknowledge input at the Vancouver editing		editors would like to acknowledge input at the Vancouver editing
	session from the following people: Orly Nicklass, James Balestriere,		session from the following people: Orly Nicklass, James Balestriere,
	Yoshifumi Atarashi, Glenn Waters, Alexander Clemm, Dave Harrington,		Yoshifumi Atarashi, Glenn Waters, Alexander Clemm, Dave Harrington,
	Dave Partain, Ray Atarashi and Dave Perkins and the following		Dave Partain, Ray Atarashi and Dave Perkins and the following
	additional people from the Montreal editing session: Balazs Lengyel,		additional people from the Montreal editing session: Balazs Lengyel,
	Phil Shafer, Rob Ennes, Andy Bierman, Dan Romascanu, Bert Wijnen,		Phil Shafer, Rob Ennes, Andy Bierman, Dan Romascanu, Bert Wijnen,
	Simon Leinen, Juergen Schoenwaelder, Hideki Okita, Vincent Cridlig,		Simon Leinen, Juergen Schoenwaelder, Hideki Okita, Vincent Cridlig,
	Martin Bjorklund, Olivier Festor, Radu State, Brian Trammell, William		Martin Bjorklund, Olivier Festor, Radu State, Brian Trammell, William
	Chow		Chow.
	9. Normative References		9. Normative References
	[NETCONF] Enns, R., "NETCONF Configuration Protocol",		[NETCONF] Enns, R., "NETCONF Configuration Protocol",
	ID draft-ietf-netconf-prot-12, February 2006.		ID draft-ietf-netconf-prot-12, February 2006.
	[RFC2026] Bradner, S., "The Internet Standards Process -- Revision		[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
	3", RFC 2026, BCP 9, October 1996.		3", RFC 2026, BCP 9, October 1996.
	[RFC2119] Bradner, s., "Key words for RFCs to Indicate Requirements		[RFC2119] Bradner, s., "Key words for RFCs to Indicate Requirements
	skipping to change at page 29, line 5		skipping to change at page 32, line 27
	RFC 2223, October 1997.		RFC 2223, October 1997.
	[XML] World Wide Web Consortium, "Extensible Markup Language		[XML] World Wide Web Consortium, "Extensible Markup Language
	(XML) 1.0", W3C XML, February 1998,		(XML) 1.0", W3C XML, February 1998,
	<http://www.w3.org/TR/1998/REC-xml-19980210>.		<http://www.w3.org/TR/1998/REC-xml-19980210>.
	[XML Schema]		[XML Schema]
	Fallside, D. and P. Walmsley, "XML Schema Part 0: Primer		Fallside, D. and P. Walmsley, "XML Schema Part 0: Primer
	Second Edition", W3C XML Schema, October 2004.		Second Edition", W3C XML Schema, October 2004.
			[XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath)
			Version 1.0",
			W3C http://www.w3.org/TR/1999/REC-xpath-19991116,
			November 1999.
	Authors' Addresses		Authors' Addresses
	Sharon Chisholm		Sharon Chisholm
	Nortel		Nortel
	3500 Carling Ave		3500 Carling Ave
	Nepean, Ontario K2H 8E9		Nepean, Ontario K2H 8E9
	Canada		Canada
	Email: schishol@nortel.com		Email: schishol@nortel.com
	skipping to change at page 30, line 7		skipping to change at page 34, line 7
	Cisco		Cisco
	Suite 400		Suite 400
	9155 E. Nichols Ave		9155 E. Nichols Ave
	Englewood, CO 80112		Englewood, CO 80112
	USA		USA
	Email: htrevino@cisco.com		Email: htrevino@cisco.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2007).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Intellectual Property		Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
End of changes. 49 change blocks.
	131 lines changed or deleted		260 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/