draft-ietf-netconf-notification-01.txt		draft-ietf-netconf-notification-02.txt
	Network Working Group S. Chisholm		Network Working Group S. Chisholm
	Internet-Draft K. Curran		Internet-Draft K. Curran
	Expires: October 30, 2006 Nortel		Expires: December 23, 2006 Nortel
	H. Trevino		H. Trevino
	Cisco		Cisco
	April 28, 2006		June 21, 2006
	NETCONF Event Notifications		NETCONF Event Notifications
	draft-ietf-netconf-notification-01.txt		draft-ietf-netconf-notification-02.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 36		skipping to change at page 1, line 36
	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 October 30, 2006.		This Internet-Draft will expire on December 23, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	This memo defines a framework for sending asynchronous messages, or		This memo defines a framework for sending asynchronous messages, or
	event notifications in NETCONF. It defines both the operations		event notifications in NETCONF. It defines both the operations
	necessary to support this concept, and also discusses implications		necessary to support this concept, and also discusses implications
	for the mapping to application protocols.		for the mapping to transport protocols.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1 Definition of Terms . . . . . . . . . . . . . . . . . . . 4		1.1 Definition of Terms . . . . . . . . . . . . . . . . . . . 4
	1.2 Event Notifications in NETCONF . . . . . . . . . . . . . . 5		1.2 Event Notifications in NETCONF . . . . . . . . . . . . . . 5
	2. Event-Related Operations . . . . . . . . . . . . . . . . . . . 6		1.3 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.1 Subscribing to receive Events . . . . . . . . . . . . . . 6		1.4 Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
	2.1.1 create-subscription . . . . . . . . . . . . . . . . . 6		1.5 Architecture . . . . . . . . . . . . . . . . . . . . . . . 7
	2.2 Sending Event Notifications . . . . . . . . . . . . . . . 7		2. Event-Related Operations . . . . . . . . . . . . . . . . . . . 8
	2.2.1 Event Notification . . . . . . . . . . . . . . . . . . 7		2.1 Subscribing to receive Events . . . . . . . . . . . . . . 8
	2.3 Changing the Subscription . . . . . . . . . . . . . . . . 8		2.1.1 create-subscription . . . . . . . . . . . . . . . . . 8
	2.3.1 modify-subscription . . . . . . . . . . . . . . . . . 9		2.2 Sending Event Notifications . . . . . . . . . . . . . . . 9
	2.4 Terminating the Subscription . . . . . . . . . . . . . . . 10		2.2.1 Event Notification . . . . . . . . . . . . . . . . . . 9
	2.4.1 cancel-subscription . . . . . . . . . . . . . . . . . 10		2.3 Changing the Subscription . . . . . . . . . . . . . . . . 10
	3. Supporting Concepts . . . . . . . . . . . . . . . . . . . . . 11		2.3.1 modify-subscription . . . . . . . . . . . . . . . . . 10
	3.1 Capabilities Exchange . . . . . . . . . . . . . . . . . . 11		2.4 Terminating the Subscription . . . . . . . . . . . . . . . 11
	3.2 Querying Subscription Properties . . . . . . . . . . . . . 11		2.4.1 cancel-subscription . . . . . . . . . . . . . . . . . 12
	3.3 One-way Notification Messages . . . . . . . . . . . . . . 16		3. Supporting Concepts . . . . . . . . . . . . . . . . . . . . . 13
	3.4 Filter Dependencies . . . . . . . . . . . . . . . . . . . 16		3.1 Capabilities Exchange . . . . . . . . . . . . . . . . . . 13
	3.4.1 Named Profiles . . . . . . . . . . . . . . . . . . . . 17		3.2 Subscriptions and Datastores . . . . . . . . . . . . . . . 13
	3.4.2 Filtering . . . . . . . . . . . . . . . . . . . . . . 17		3.3 Querying Subscription Properties . . . . . . . . . . . . . 13
	3.5 Event Classes . . . . . . . . . . . . . . . . . . . . . . 17		3.4 One-way Notification Messages . . . . . . . . . . . . . . 18
	3.6 Defining Event Notifications . . . . . . . . . . . . . . . 18		3.5 Filter Dependencies . . . . . . . . . . . . . . . . . . . 19
	3.7 Interleaving Messages . . . . . . . . . . . . . . . . . . 18		3.5.1 Named Profiles . . . . . . . . . . . . . . . . . . . . 19
	4. XML Schema for Event Notifications . . . . . . . . . . . . . . 20		3.5.2 Filtering . . . . . . . . . . . . . . . . . . . . . . 19
	5. Mapping to Application Protocols . . . . . . . . . . . . . . . 24		3.6 Event Classes . . . . . . . . . . . . . . . . . . . . . . 19
	5.1 SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 24		3.6.1 Initial Set of Event Classes . . . . . . . . . . . . . 20
	5.2 BEEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 25		3.7 Defining Event Notifications . . . . . . . . . . . . . . . 21
	5.2.1 One-way Notification Messages in Beep . . . . . . . . 25		3.8 Interleaving Messages . . . . . . . . . . . . . . . . . . 21
	5.3 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 26		4. XML Schema for Event Notifications . . . . . . . . . . . . . . 23
	5.3.1 A NETCONF over Soap over HTTP Example . . . . . . . . 26		5. Mapping to Transport Protocols . . . . . . . . . . . . . . . . 27
	6. Filtering examples . . . . . . . . . . . . . . . . . . . . . . 29		5.1 SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
	6.1 Event Classes . . . . . . . . . . . . . . . . . . . . . . 29		5.2 BEEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	6.2 Subtree Filtering . . . . . . . . . . . . . . . . . . . . 29		5.2.1 One-way Notification Messages in Beep . . . . . . . . 28
	6.3 XPATH filters . . . . . . . . . . . . . . . . . . . . . . 31		5.3 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	7. Additional Capabilities . . . . . . . . . . . . . . . . . . . 33		5.3.1 A NETCONF over Soap over HTTP Example . . . . . . . . 29
	7.1 Call-Home Notifications . . . . . . . . . . . . . . . . . 33		6. Filtering examples . . . . . . . . . . . . . . . . . . . . . . 32
	7.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . 33		6.1 Event Classes . . . . . . . . . . . . . . . . . . . . . . 32
	7.1.2 Dependencies . . . . . . . . . . . . . . . . . . . . . 34		6.2 Subtree Filtering . . . . . . . . . . . . . . . . . . . . 32
	7.1.3 Capability Identifier . . . . . . . . . . . . . . . . 34		6.3 XPATH filters . . . . . . . . . . . . . . . . . . . . . . 34
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 37		7. Additional Capabilities . . . . . . . . . . . . . . . . . . . 36
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38		7.1 Call-Home Notifications . . . . . . . . . . . . . . . . . 36
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39		7.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . 36
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 39		7.1.2 Dependencies . . . . . . . . . . . . . . . . . . . . . 37
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 40		7.1.3 Capability Identifier . . . . . . . . . . . . . . . . 37
	A. Design Alternatives . . . . . . . . . . . . . . . . . . . . . 41		8. Security Considerations . . . . . . . . . . . . . . . . . . . 41
	A.1 Suspend And Resume . . . . . . . . . . . . . . . . . . . . 41		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
	A.2 Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . 41		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43
	B. Event Notifications and Syslog . . . . . . . . . . . . . . . . 42		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
	B.1 Leveraging Syslog Field Definitions . . . . . . . . . . . 42		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 44
	B.1.1 Field Mapping . . . . . . . . . . . . . . . . . . . . 43		A. Design Alternatives . . . . . . . . . . . . . . . . . . . . . 45
	B.1.2 Severity Mapping . . . . . . . . . . . . . . . . . . . 44		A.1 Suspend And Resume . . . . . . . . . . . . . . . . . . . . 45
	B.2 Syslog within NETCONF Events . . . . . . . . . . . . . . . 44		A.2 Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . 45
	B.2.1 Motivation . . . . . . . . . . . . . . . . . . . . . . 44		B. Event Notifications and Syslog . . . . . . . . . . . . . . . . 46
	B.2.2 Embedding syslog messages in a NETCONF Event . . . . . 44		B.1 Leveraging Syslog Field Definitions . . . . . . . . . . . 46
	B.2.3 Supported Forwarding Options . . . . . . . . . . . . . 45		B.1.1 Field Mapping . . . . . . . . . . . . . . . . . . . . 47
	C. Example Configuration Notifications . . . . . . . . . . . . . 47		B.1.2 Severity Mapping . . . . . . . . . . . . . . . . . . . 48
	C.1 Types of Configuration Events . . . . . . . . . . . . . . 47		B.2 Syslog within NETCONF Events . . . . . . . . . . . . . . . 48
	C.2 Config Event Notification Structure . . . . . . . . . . . 48		B.2.1 Motivation . . . . . . . . . . . . . . . . . . . . . . 48
	C.3 Configuration Event Content . . . . . . . . . . . . . . . 50		B.2.2 Embedding syslog messages in a NETCONF Event . . . . . 48
	C.3.1 Target Datastore . . . . . . . . . . . . . . . . . . . 50		B.2.3 Supported Forwarding Options . . . . . . . . . . . . . 49
	C.3.2 User Info . . . . . . . . . . . . . . . . . . . . . . 50		C. Example Configuration Notifications . . . . . . . . . . . . . 51
	C.3.3 Data Source . . . . . . . . . . . . . . . . . . . . . 50		C.1 Types of Configuration Events . . . . . . . . . . . . . . 51
	C.3.4 Operation . . . . . . . . . . . . . . . . . . . . . . 50		C.2 Config Event Notification Structure . . . . . . . . . . . 52
	C.3.5 Context . . . . . . . . . . . . . . . . . . . . . . . 50		C.3 Configuration Event Content . . . . . . . . . . . . . . . 54
	C.3.6 Entered Command . . . . . . . . . . . . . . . . . . . 51		C.3.1 Target Datastore . . . . . . . . . . . . . . . . . . . 54
	C.3.7 New Config . . . . . . . . . . . . . . . . . . . . . . 51		C.3.2 User Info . . . . . . . . . . . . . . . . . . . . . . 54
	C.3.8 Old Config . . . . . . . . . . . . . . . . . . . . . . 51		C.3.3 Data Source . . . . . . . . . . . . . . . . . . . . . 54
	C.3.9 Non-netconf commands in configuration notifications . 51		C.3.4 Operation . . . . . . . . . . . . . . . . . . . . . . 54
	Intellectual Property and Copyright Statements . . . . . . . . 52		C.3.5 Context . . . . . . . . . . . . . . . . . . . . . . . 54
			C.3.6 Entered Command . . . . . . . . . . . . . . . . . . . 55
			C.3.7 New Config . . . . . . . . . . . . . . . . . . . . . . 55
			C.3.8 Old Config . . . . . . . . . . . . . . . . . . . . . . 55
			C.3.9 Non-netconf commands in configuration notifications . 55
			D. IP Address Schema . . . . . . . . . . . . . . . . . . . . . . 56
			Intellectual Property and Copyright Statements . . . . . . . . 58
	1. Introduction		1. Introduction
	NETCONF [NETCONF-PROTO] can be conceptually partitioned into four		NETCONF [NETCONF-PROTO] can be conceptually partitioned into four
	layers:		layers:
	Layer Example		Layer Example
	+-------------+ +----------------------------------------+		+-------------+ +----------------------------------------+
	| Content | | Configuration data |		| Content | | Configuration data |
	+-------------+ +----------------------------------------+		+-------------+ +----------------------------------------+
	skipping to change at page 4, line 31		skipping to change at page 4, line 31
	+-------------+ +-----------------------------+ |		+-------------+ +-----------------------------+ |
	| | |		| | |
	+-------------+ +------------------------------------------+		+-------------+ +------------------------------------------+
	| Application | | BEEP, SSH, SSL, console |		| Application | | BEEP, SSH, SSL, console |
	| Protocol | | |		| Protocol | | |
	+-------------+ +------------------------------------------+		+-------------+ +------------------------------------------+
	This document defines a framework for sending asynchronous messages,		This document defines a framework for sending asynchronous messages,
	or event notifications in NETCONF. It defines both the operations		or event notifications in NETCONF. It defines both the operations
	necessary to support this concept, and also discusses implications		necessary to support this concept, and also discusses implications
	for the mapping to application protocols.		for the mapping to transport protocols.
	Figure 1		Figure 1
	1.1 Definition of Terms		1.1 Definition of Terms
	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 RFC 2119 [3].		document are to be interpreted as described in RFC 2119 [3].
	Element: An XML Element[XML].		Element: An XML Element[XML].
	Managed Entity: A node, which supports NETCONF[NETCONF] and has		Managed Entity: A node, which supports NETCONF[NETCONF-PROTO] and has
	access to management instrumentation. This is also known as the		access to management instrumentation. This is also known as the
	NETCONF server.		NETCONF server.
	Managed Object: A collection of one of more Elements that define an		Managed Object: A collection of one of more Elements that define an
	abstract thing of interest.		abstract thing of interest.
	1.2 Event Notifications in NETCONF		1.2 Event Notifications in NETCONF
	An event is something that happens which may be of interest - a		An event is something that happens which may be of interest - a
	configuration change, a fault, a change in status, crossing a		configuration change, a fault, a change in status, crossing a
	skipping to change at page 6, line 5		skipping to change at page 5, line 28
	successful and, if it was successful, begins sending the event		successful and, if it was successful, begins sending the event
	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 an explicit command to		either the NETCONF session is terminated or an explicit command to
	cancel the subscription is sent. The event notification subscription		cancel the subscription is sent. 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, but can be modified later using a modify		subscription is created, but can be modified later using a modify
	subscription command.		subscription command.
			1.3 Motivation
			The motivation for this work is to enable the sending of asynchronous
			messages that are consistent with the data model (content) and
			security model used within a Netconf implementation.
			1.4 Requirements
			The requirements for this solution are as follows:
			o Initial release should ensure it supports notification in support
			of configuration operations
			o Data content must be use the same data model as used in
			configuration
			o solution should support structured hierarchical data
			o solution should be able to carry configuration fragments
			o solution should support a reasonable message size limit (syslog
			and SNMP are rather constrained in terms of message sizes)
			o solution should provide reliable delivery of notifications
			o solution should support preconfigured notification destinations
			o solution should support agent initiated connections
			o solution should provide a subscription mechanism
			o solution should support multiple subscriptions
			o solution should provide a filtering mechanism
			o solution should support notification names
			o solution should support notification timestamps
			o solution should support notification classes
			o solution should support notification info
			o solution should provide the ability to specify the content of
			notifications to ensure predictability
			o solution should send sufficient information in a notification so
			that it can be analyzed independent of the transport mechanism
			o solution should allow notifications to refer to prior
			configuration change RPCs
			o solution should not bind subscriptions to a connection
			o channels for configuration change notifications should share fate
			with a session that includes a configuration channel
			o solution should support replay of locally logged notifications
			o solution should support message chunking capability in cases
			channels carry mixed RPCs
			o solution should scale to 30.000-100.000 nodes which may emit
			notifications
			o solution should scale to order 30.000-100.000 nodes to send
			notifications [BL]
			See also the external website tracking requirements at
			http://www.eecs.iu-bremen.de/wiki/index.php/Netconf_notifications
			1.5 Architecture
			[Editor's Note: add pointers to the various architecture discussions
			in the document and identify what people view to be gaps in
			architecture discussion. The following may not be what people were
			looking for in this section, but should at least give people
			something to discuss]
			The following figure illustrates that the netconf implementation
			leverages protocol-neutral event management software within the box
			rather then re-invent everything in Netconf specific methods. The
			netconf client understands which notifications are of interest to it
			and creates a subscription that meets its requirements. The network
			elements accepts the subscription requests and creates a temporary
			subscription to meet those needs.
			----------------------------------------------
			| Network Element |
			| ------------ |
			| | Alarm | |
			| | Management | -------------- | --------------
			| ------------ |--->|Netconf Stack |<---------->| Netconf |
			| | | | | | | |
			| | | -------------- | --->| Client |
			| V | | | --------------
			| ------------ | | |
			| | Event |--->| ------------------ | |
			| | Management | | |Other Protocols | | |
			| ------------ |--->| | | |
			| ------------------ | |
			|--------------------------------------------- |
			|
			---------------------------------------------- |
			| Network Element | |
			| ------------ | |
			| | Alarm | | |
			| | Management | -------------- | |
			| ------------ |--->|Netconf Stack |<-------|
			| | | | | |
			| | | -------------- |
			| V | |
			| ------------ | |
			| | Event |--->| ------------------ |
			| | Management | | |Other Protocols | |
			| ------------ |--->| | |
			| ------------------ |
			|--------------------------------------------
	2. Event-Related Operations		2. Event-Related Operations
	2.1 Subscribing to receive Events		2.1 Subscribing to receive Events
	The event notification subscription is initiated by the NETCONF		The event notification subscription is initiated by the NETCONF
	client and responded to by the NETCONF server. When the event		client and responded to by the NETCONF server. When the event
	notification subscription is created, the events of interest are		notification subscription is created, the events of interest are
	specified.		specified.
	It is possible to create more than one event notification		It is possible to create more than one event notification
	skipping to change at page 6, line 28		skipping to change at page 8, line 28
	Content for an event notification subscription can be selected by		Content for an event notification subscription can be selected by
	specifying which event classes are of interest and /or by applying		specifying which event classes are of interest and /or by applying
	user-specified filters.		user-specified filters.
	2.1.1 create-subscription		2.1.1 create-subscription
	<create-subscription>		<create-subscription>
	Description:		Description:
	This command initiates an event notification subscription which		This operation initiates an event notification subscription which
	will send asynchronous event notifications to the initiator of the		will send asynchronous event notifications to the initiator of the
	command until the <cancel-subscription > command is sent.		command until the <cancel-subscription > command is sent.
	Parameters:		Parameters:
	Event Classes:		Event Classes:
	An optional parameter that indicates which event classes are of		An optional parameter that indicates which event classes are of
	interest. If not present, events of all classes will be sent.		interest. If not present, events of all classes will be sent.
	skipping to change at page 7, line 7		skipping to change at page 9, line 7
	possible events are of interest. The format of this parameter		possible events are of interest. The format of this parameter
	is the same as that of the filter parameter in the NETCONF		is the same as that of the filter parameter in the NETCONF
	protocol operations. If not present, all events not precluded		protocol operations. If not present, all events not precluded
	by other parameters will be sent. These filter parameters can		by other parameters will be sent. These filter parameters can
	only be modified using the modify-subscription command.		only be modified using the modify-subscription command.
	Named Profile		Named Profile
	An optional parameter that points to a separately defined		An optional parameter that points to a separately defined
	filter profile. The contents of the profile are specified in		filter profile. The contents of the profile are specified in
	the provided XML Schema. If not present, no additional		the provided XML Schema. If not present, no additional
	filtering will be applied. If the separate definition of these		filtering will be applied. Note that changes to the profile
	filters is updated, then these changes will be reflected in the		after the subscription has been created will have no effect
	filtered events on this subscription.		unless a modify subscription command is issued.
	Positive Response:		Positive Response:
	If the NETCONF server can satisfy the request, the server sends an		If the NETCONF server can satisfy the request, the server sends an
	<rpc-reply> element containing a <data> element containing the		<rpc-reply> element containing a <data> element containing the
	subscription ID.		subscription ID.
	Negative Response:		Negative Response:
	An <rpc-error> element is included within the <rpc-reply> if the		An <rpc-error> element is included within the <rpc-reply> if the
	request cannot be completed for any reason.		request cannot be completed for any reason. Subscription requests
			will fail if a filter with invalid syntax is provided or if the
			name of a non-existent profile is provided.
	2.2 Sending Event Notifications		2.2 Sending Event Notifications
	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.
	Notifications are tagged with event classes, subscription ID,		Notifications are tagged with event classes, subscription ID,
	sequence number, and date and time.		sequence number, and date and time.
	2.2.1 Event Notification		2.2.1 Event Notification
	skipping to change at page 8, line 20		skipping to change at page 10, line 20
	A sequentially increasing number to uniquely identify event		A sequentially increasing number to uniquely identify event
	notifications for this subscription. It starts at 0, always		notifications for this subscription. It starts at 0, always
	increases by just one and rolls back to 0 after its maximum		increases by just one and rolls back to 0 after its maximum
	value is reached.		value is reached.
	Date and Time:		Date and Time:
	The date and time that the event notification was sent by the		The date and time that the event notification was sent by the
	NETCONF server.		NETCONF server.
			Data:
			Contains event class and notification-specific tagged content.
	Positive Response:		Positive Response:
	No response.		No response.
	Negative Response:		Negative Response:
	No response.		No response.
	2.2.1.1 Event Notification
	The NETCONF Event notification structure is shown in the following
	figure.
	___________________________________________________________________
	|| Notification Header || Data |
	||__________________________________________________________||______|
	|| subscriptionId| eventClasses| sequenceNumber| dateAndTime|| |
	||_______________|_____________|_______________|____________||______|
	2.3 Changing the Subscription		2.3 Changing the Subscription
	After an event notification subscription has been established, the		After an event notification subscription has been established, the
	NETCONF client can initiate a request to change properties of the		NETCONF client can initiate a request to change properties of the
	event notification subscription. This prevents loss of event		event notification subscription. This prevents loss of event
	notifications that might otherwise occur during a cancelling and		notifications that might otherwise occur during a cancelling and
	recreation of the event notification subscription. This command is		recreation of the event notification subscription. This operation is
	responded to by the NETCONF server		responded to by the NETCONF server
	2.3.1 modify-subscription		2.3.1 modify-subscription
	<modify-subscription>		<modify-subscription>
	Description:		Description:
	Change properties of the event notification subscription.		Change properties of the event notification subscription.
	skipping to change at page 9, line 38		skipping to change at page 11, line 32
	filter used for other NETCONF commands. If not present, all		filter used for other NETCONF commands. If not present, all
	events not precluded by other parameters will be sent. These		events not precluded by other parameters will be sent. These
	filter parameters can only be modified using the modify-		filter parameters can only be modified using the modify-
	subscription command.		subscription command.
	Named Profile:		Named Profile:
	An optional parameter that points to separately defined filter		An optional parameter that points to separately defined filter
	profile. The contents of the profile are specified in provided		profile. The contents of the profile are specified in provided
	XML Schema. If not present, no additional filtering will be		XML Schema. If not present, no additional filtering will be
	applied. If the separate definition of these filters is		applied. Note that changes to the profile after the
	updated, then these changes will be reflected in the events		subscription has been created will have no effect unless a
	seen on this subscription.		modify subscription command is issued.
	Positive Response:		Positive Response:
	If the NETCONF server was able to satisfy the request, an <rpc-		If the NETCONF server was able to satisfy the request, an <rpc-
	reply> is sent that includes an <ok> element.		reply> is sent that includes an <ok> element.
	Negative Response:		Negative Response:
	An <rpc-error> element is included within the <rpc-reply> if the		An <rpc-error> element is included within the <rpc-reply> if the
	request cannot be completed for any reason.		request cannot be completed for any reason. Subscription requests
			will fail if a filter with invalid syntax is provided or if the
			name of a non-existent profile is provided.
	2.4 Terminating the Subscription		2.4 Terminating the Subscription
	Closing of the event notification subscription is initiated by the		Closing of the event notification subscription is initiated by the
	NETCONF client. The specific subscription to be closed is specified		NETCONF client. The specific subscription to be closed is specified
	using a subscription ID. The NETCONF server responds. Note that the		using a subscription ID. The NETCONF server responds. Note that the
	NETCONF session may also be torn down for other reasons and this will		NETCONF session may also be torn down for other reasons and this will
	also result in the subscription being cancelled, but is not subjected		also result in the subscription being cancelled, but is not subjected
	to the behaviour of this command.		to the behaviour of this operation.
	2.4.1 cancel-subscription		2.4.1 cancel-subscription
	<cancel-subscription>		<cancel-subscription>
	Description:		Description:
	Stop and delete the event notification subscription.		Stop and delete the event notification subscription.
	Parameters:		Parameters:
	skipping to change at page 11, line 31		skipping to change at page 13, line 31
	<capability>		<capability>
	urn:ietf:params:xml:ns:netconf:capability:startup:1.0		urn:ietf:params:xml:ns:netconf:capability:startup:1.0
	</capability>		</capability>
	<capability>		<capability>
	urn:ietf:params:xml:ns:netconf:notification:1.0		urn:ietf:params:xml:ns:netconf:notification:1.0
	</capability>		</capability>
	</capabilities>		</capabilities>
	<session-id>4</session-id>		<session-id>4</session-id>
	</hello>		</hello>
	3.2 Querying Subscription Properties		3.2 Subscriptions and Datastores
			Subscriptions are like Netconf sessions in that they don't exist
			Netconf datastores. The two exceptions to this are named profiles
			and the optional call-home notification feature.
			3.3 Querying Subscription Properties
	The following Schema can be used to retrieve information about active		The following Schema can be used to retrieve information about active
	event notification subscriptions		event notification subscriptions
	<xs:schema		<xs:schema
	xmlns:xs="http://www.w3.org/2001/XMLSchema"		xmlns:xs="http://www.w3.org/2001/XMLSchema"
	xmlns:nsub="urn:ietf:params:xml:ns:netconf:subscription:1.0"		xmlns:nsub="urn:ietf:params:xml:ns:netconf:subscription:1.0"
	targetNamespace= "urn:ietf:params:xml:ns:netconf:subscription:1.0"		targetNamespace= "urn:ietf:params:xml:ns:netconf:subscription:1.0"
	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:ncEvent= "urn:ietf:params:xml:ns:netconf:notification:1.0"
	xmlns:nm="urn:ietf:params:xml:ns:netconf:appInfo:1.0"		xmlns:nm="urn:ietf:params:xml:ns:netconf:appInfo:1.0"
	elementFormDefault="qualified" attributeFormDefault="unqualified"		elementFormDefault="qualified" attributeFormDefault="unqualified"
	xml:lang="en">		xml:lang="en">
	<xs:annotation>		<xs:annotation>
	<xs:documentation xml:lang="en">		<xs:documentation xml:lang="en">
	Schema for reporting on Event Subscriptions		Schema for reporting on Event Subscriptions
	</xs:documentation>		</xs:documentation>
	<xs:appinfo>		<xs:appinfo>
	<nm:identity		<nm:identity
	xmlns:nm="urn:ietf:params:xml:ns:netmod:base:1.0">		xmlns:nm="urn:ietf:params:xml:ns:netmod:base:1.0">
	<nm:Name>NetConfStateSchema</nm:Name>		<nm:Name>NetconfNotificationSchema</nm:Name>
	<nm:LastUpdated>2006-04-30T09:30:47-05:00		<nm:LastUpdated>2006-04-30T09:30:47-05:00
	</nm:LastUpdated>		</nm:LastUpdated>
	<nm:Organization>IETF</nm:Organization>		<nm:Organization>IETF</nm:Organization>
	<nm:Description>		<nm:Description>
	A schema that can be used to learn about current		A schema that can be used to learn about current
	NetConf Event subscriptions and creating named		NetConf Event subscriptions and creating named
	profiles		profiles
	</nm:Description>		</nm:Description>
	</nm:identity>		</nm:identity>
	</xs:appinfo>		</xs:appinfo>
	skipping to change at page 16, line 31		skipping to change at page 18, line 36
	<xs:element name="namedProfiles">		<xs:element name="namedProfiles">
	<xs:complexType>		<xs:complexType>
	<xs:sequence>		<xs:sequence>
	<xs:element ref="nsub:namedProfile" minOccurs="0"		<xs:element ref="nsub:namedProfile" minOccurs="0"
	maxOccurs="unbounded" />		maxOccurs="unbounded" />
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	</xs:element>		</xs:element>
	</xs:schema>		</xs:schema>
	3.3 One-way Notification Messages		3.4 One-way Notification Messages
	In order to support the concept that each individual event		In order to support the concept that each individual event
	notification is a well-defined XML-document that can be processed		notification is a well-defined XML-document that can be processed
	without waiting for all events to come in, it makes sense to define		without waiting for all events to come in, it makes sense to define
	events, not as an endless reply to a subscription command, but as		events, not as an endless reply to a subscription command, but as
	independent messages that originate from the NETCONF server. In		independent messages that originate from the NETCONF server. In
	order to support this model, this memo introduces the concept of		order to support this model, this memo introduces the concept of
	notifications, which are one-way messages.		notifications, which are one-way messages.
	A one-way message is similar to the two-way RPC message, except that		A one-way message is similar to the two-way RPC message, except that
	no response is expected to the command. In the case of event		no response is expected to the command. In the case of event
	notification, this message will originate from the NETCONF server,		notification, this message will originate from the NETCONF server,
	and not the NETCONF client.		and not the NETCONF client.
	3.4 Filter Dependencies		3.5 Filter Dependencies
	Note that when multiple filters are specified (Event Class, in-line		Note that when multiple filters are specified (Event Class, in-line
	Filter, Named Profiles), they are applied collectively, so event		Filter, Named Profiles), they are applied collectively, so event
	notifications needs to pass all specified filters in order to be sent		notifications needs to pass all specified filters in order to be sent
	to the subscriber. If a filter is specified to look for data of a		to the subscriber. If a filter is specified to look for data of a
	particular value, and the data item is not present within a		particular value, and the data item is not present within a
	particular event notification for its value to be checked against,		particular event notification for its value to be checked against,
	it will be filtered out. For example, if one were to check for		it will be filtered out. For example, if one were to check for
	'severity=critical' in a configuration event notification where this		'severity=critical' in a configuration event notification where this
	field was not supported, then the notification would be filtered out.		field was not supported, then the notification would be filtered out.
	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 or		at the time an event notification subscription is created or
	modified. Note that changes to the profile after the subscription		modified. Note that changes to the profile after the subscription
	has been created will have no effect unless a modify subscription		has been created will have no effect unless a modify subscription
	command is issued. Since named profiles exist outside of the		command is issued. Since named profiles exist outside of the
	subscription, they persist after the subscription has been cancelled.		subscription, they persist after the subscription has been cancelled.
	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. These filters can only be		notification subscription is created. These filters can only be
	changed using the modify subscription command. This is specified via		changed using the modify subscription command. This is specified via
	the Filter parameter. Filters only exist as parameters to the		the Filter parameter. Filters only exist as parameters to the
	subscription.		subscription.
	3.5 Event Classes		3.6 Event Classes
	Events can be broadly classified into one more event classes. Each		Events can be classified into one more event classes. Each event
	event class identifies a set of event notifications which share		class identifies a set of event notifications which
	important characteristics, such being generated from similar events
	or sharing much of the same content.
	The initial set of event classes is fault, configuration, state,		share similar content
			are generated from similar events
			The initial set of event classes is configuration, fault, state,
	audit, data, maintenance, metrics, security, information, heartbeat		audit, data, maintenance, metrics, security, information, heartbeat
	and syslog.		and syslogTunnel. See the IANA Considerations section for
			information on defining new event classes.
			All events shall carry the following data: list of event class,
			timestamp and sequence number of the notification. They may also
			carry additional data.
			___________________________________________________________________
			|| Notification Header || Data |
			||__________________________________________________________||______|
			|| subscriptionId| eventClasses| sequenceNumber| dateAndTime|| |
			||_______________|_____________|_______________|____________||______|
			3.6.1 Initial Set of Event Classes
			A configuration event, alternatively known as an inventory event, is
			used to indicate that hardware, software, or a service has been
			added, changed or removed. In keeping aligned with NETCONF protocol
			operations, configuration events may included copy configuration
			event, delete configuration event, or the edit configuration event
			(create, delete, merge, replace). As configuration notifications
			could potentially carry huge amounts of data in order to properly
			support functions such as security audit logs, so it is expected that
			netconf clients will engineer their subscriptions to meet their needs
			and to not overwhelm their capacity to process and store event
			notifications. Examples include hardware board removed, software
			module loaded or DNS server reconfigured. Changes are reported to
			all subscribed clients, not just to those clients whose actions
			triggered the changes.
	A fault event notification is generated when a fault condition (error		A fault event notification is generated when a fault condition (error
	or warning) occurs. A fault event may result in an alarm. Examples		or warning) occurs. A fault event may result in an alarm. Examples
	of fault events could be a communications alarm, environmental alarm,		of fault events could be a communications alarm, environmental alarm,
	equipment alarm, processing error alarm, quality of service alarm, or		equipment alarm, processing error alarm, quality of service alarm, or
	a threshold crossing event. See RFC3877 and RFC2819 for more		a threshold crossing event. See RFC3877 and RFC2819 for more
			information. The fault notification should carry the following data:
			severity, event source, probable cause, specific problem, additional
	information.		information.
	A configuration event, alternatively known as an inventory event, is
	used to notify that hardware, software, or a service has been added/
	changed/removed. In keeping aligned with NETCONF protocol
	operations, configuration events may included copy configuration
	event, delete configuration event, or the edit configuration event
	(create, delete, merge, replace).
	A state event indicates a change from one state to another, where a		A state event indicates a change from one state to another, where a
	state is a condition or stage in the existence of a managed entity.		state is a condition or stage in the existence of a managed entity.
	State change events are seen in many specifications. For Entity		State change events are seen in many specifications. For Entity
	state changes, see [Entity-State-MIB] for more information.		state changes, see [Entity-State-MIB] for more information. The
			notification shall identify the object who's state changed and the
			new state. Internal states of a node are important for supervision
			purposes and also effect how a node can be configured.
	Audit events provide event of very specific actions within a managed		Audit events provide event of very specific actions within a managed
	device. In isolation an audit events provides very limited data. A		device. In isolation an audit events provides very limited data. A
	collection of audit information forms an audit trail.		collection of audit information forms an audit trail.
	A data dump event is an asynchronous event containing information		A data dump event is an asynchronous event containing information
	about a system, its configuration, state, etc.		about a system, its configuration, state, etc.
	A maintenance event signals the beginning, process or end of an		A maintenance event signals the beginning, process or end of an
	action either generated by a manual or automated maintenance action.		action either generated by a manual or automated maintenance action.
			If the maintenance event is a direct result of a configuration
			management operation on this Netconf session then an rpc-reply
			notification should be used. This event class is intended instead
			for reporting on scheduled maintenance activities. Expected data
			includes a description of the maintenance process, the stage the
			process has reached, the manual action, automatic process that
			triggered the notification. Examples include automatic backup
			completed.
	A metrics event contains a metric or a collection of metrics. This		A metrics event contains a metric or a collection of metrics. This
	includes performance metrics.		includes performance metrics.
	A heart beat event is sent periodically to enable testing that the		A heart beat event is sent periodically to enable testing that the
	communications channel is still functional. It behaves much like the		communications channel is still functional. It behaves much like the
	other event classes, with the exception that implementations may not		other event classes, with the exception that implementations may not
	want to include an event log, if supported. Although widely used		want to include an event log, if supported. Although widely used
	throughout the industry, no current corresponding work within the		throughout the industry, no current corresponding work within the
	IETF. However, other standards bodies such as the TeleManagement		IETF. However, other standards bodies such as the TeleManagement
	Forum have similar definitions.		Forum have similar definitions.
	An Information event is something that happens of interest which is		An Information event is something that happens of interest which is
	within the expected operational behaviour and not otherwise covered		within the expected operational behaviour and not otherwise covered
	by another class.		by another class.
	The syslog event class is used to indicate tunneled syslog content.		syslogTunnel event is when syslog content is sent, unmodified, within
	The content and format of the message will be compliant to syslog		a Netconf event Notification. See appendix X.X for more
	standards.		information..
	3.6 Defining Event Notifications		3.7 Defining Event Notifications
	Event Notifications are defined ahead of time by defining an XML		Event Notifications are defined ahead of time by defining an XML
	element and assigning it to particular event classes. This will be		element and assigning it to particular event classes. This will be
	done using an "eventClasses" attribute.		done using an "eventClasses" attribute.
	3.7 Interleaving Messages		3.8 Interleaving Messages
	While each NETCONF message must be a complete XML document, the		While each NETCONF message must be a complete XML document, the
	design of the event system allows for the interleaving of complete		design of the event system allows for the interleaving of complete
	asynchronous event notifications with complete synchronous messages.		asynchronous event notifications with complete synchronous messages.
	It is possible to still send command-response type messages such as		It is possible to still send command-response type messages such as
	<modify-subscription> while events are being generated. The only		<modify-subscription> while events are being generated. The only
	restriction is that each message must be complete		restriction is that each message must be complete
	The following sequence diagram demonstrates an example NETCONF		The following sequence diagram demonstrates an example NETCONF
	session where after basic session establishment and capability		session where after basic session establishment and capability
	exchange, NETCONF client (C), subscribes to receive event		exchange, NETCONF client (C), subscribes to receive event
	notifications. The NETCONF server (S), starts sending event		notifications. The NETCONF server (S), starts sending event
	notifications as events of interest happen within the system. The		notifications as events of interest happen within the system. The
	NETCONF client decides to change the characteristics of their event		NETCONF client decides to change the characteristics of their event
	skipping to change at page 23, line 25		skipping to change at page 26, line 25
	<xs:element name="cancel-subscription"		<xs:element name="cancel-subscription"
	type="cancelSubscriptionType"		type="cancelSubscriptionType"
	substitutionGroup="netconf:rpcOperation"/>		substitutionGroup="netconf:rpcOperation"/>
	<!-- ************** One-way Operations ******************-->		<!-- ************** One-way Operations ******************-->
	<!--		<!--
	<Event> operation		<Event> operation
	-->		-->
	<xs:complexType name="NotificationType">		<xs:complexType name="NotificationType">
	<xs:complexContent>
	<xs:sequence>		<xs:sequence>
	<xs:element name="subscription-id"		<xs:element name="subscriptionId" type="SubscriptionID" />
	type="SubscriptionID"/>		<xs:element name="eventClasses" type="EventClasses" />
	<xs:element name="event-classes" type="EventClasses"/>		<xs:element name="sequenceNumber" type="SequenceNumber" />
	<xs:element name="sequence-number"		<xs:element name="dateAndTime" type="xs:dateTime">
	type="SequenceNumber"/>
	<xs:element name="date-time" type="xs:dateTime">
	<xs:annotation>		<xs:annotation>
	<xs:documentation>		<xs:documentation>
	The date and time that the event notification was		The date and time that the notification was sent
	sent by the netconf server.		by the netconf server.
	</xs:documentation>		</xs:documentation>
	</xs:annotation>		</xs:annotation>
	</xs:element>		</xs:element>
	</xs:sequence>		</xs:sequence>
	</xs:extension>
	</xs:complexContent>
	</xs:complexType>		</xs:complexType>
	<xs:element name="notification" type="NotificationType"/>		<xs:element name="notification" type="NotificationType"/>
	</xs:schema>		</xs:schema>
	5. Mapping to Application Protocols		5. Mapping to Transport Protocols
	Currently, the NETCONF family of specification allows for running		Currently, the NETCONF family of specification allows for running
	NETCONF over a number of application protocols, some of which support		NETCONF over a number of transport protocols, some of which support
	multiple configurations. Some of these options will be better suited		multiple configurations. Some of these options will be better suited
	for supporting event notifications then others.		for supporting event notifications then others.
	5.1 SSH		5.1 SSH
	Session establishment and two-way messages are based on the NETCONF		Session establishment and two-way messages are based on the NETCONF
	over SSH transport mapping [NETCONF-SSH]		over SSH transport mapping [NETCONF-SSH]
	One-way event messages are supported as follows: Once the session		One-way event messages are supported as follows: Once the session
	has been established and capabilities have been exchanged, the server		has been established and capabilities have been exchanged, the server
	skipping to change at page 25, line 9		skipping to change at page 28, line 9
	The NETCONF over SSH session to receive an event notification might		The NETCONF over SSH session to receive an event notification might
	look like the following. Note the event notification contents		look like the following. Note the event notification contents
	(delimited by <data> </data> tags) are not defined in this document		(delimited by <data> </data> tags) are not defined in this document
	and are provided herein simply for illustration purposes:		and are provided herein simply for illustration purposes:
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<notification		<notification
	xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">		xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
	<subscription-id>123456</subscription-id>		<subscription-id>123456</subscription-id>
	<event-class><configuration/><audit/></event-classes>		<eventClasses><configuration/><audit/></eventClasses>
	<sequence-number>2</sequence-number>		<sequenceNumber>2</sequenceNumber>
	<date-time>2000-01-12T12:13:14Z</date-time>		<dateAndTime>2000-01-12T12:13:14Z</dateAndTime>
	<data>		<data>
	<user>Fred Flinstone</user>		<user>Fred Flinstone</user>
	<operation>		<operation>
	<edit-config>		<edit-config>
	<target>		<target>
	<running/>		<running/>
	</target>		</target>
	<config>		<config>
	<top xmlns="http://example.com/schema/1.2/config">		<top xmlns="http://example.com/schema/1.2/config">
	<interface>		<interface>
	skipping to change at page 27, line 34		skipping to change at page 30, line 34
	S: Content-Type: application/soap+xml; charset=utf-8		S: Content-Type: application/soap+xml; charset=utf-8
	S: Content-Length: 917		S: Content-Length: 917
	S:		S:
	S: <?xml version="1.0" encoding="UTF-8"?>		S: <?xml version="1.0" encoding="UTF-8"?>
	S: <soapenv:Envelope		S: <soapenv:Envelope
	S: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">		S: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
	S: <soapenv:Body>		S: <soapenv:Body>
	S: <notification		S: <notification
	xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">		xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
	S: <subscriptionID>123456</subscriptionID>		S: <subscriptionID>123456</subscriptionID>
	S: <eventClass><configuration/><audit/></eventClass>		S: <eventClasses><configuration/><audit/></eventClasses>
	S: <sequenceNumber>2</sequenceNumber>		S: <sequenceNumber>2</sequenceNumber>
	S: <dateAndTime>2000-01-12T12:13:14Z</dateAndTime>		S: <dateAndTime>2000-01-12T12:13:14Z</dateAndTime>
	S: <data>		S: <data>
	S: <user>Fred Flinstone</user>		S: <user>Fred Flinstone</user>
	S: <operation>		S: <operation>
	S: <edit-config>		S: <edit-config>
	S: <target>		S: <target>
	S: <running/>		S: <running/>
	S: </target>		S: </target>
	S: <config>		S: <config>
	skipping to change at page 29, line 16		skipping to change at page 32, line 16
	The following section provides examples to illustrate the various		The following section provides examples to illustrate the various
	methods of filtering content on an event notification subscription.		methods of filtering content on an event notification subscription.
	6.1 Event Classes		6.1 Event Classes
	The following example illustrates selecting all event notifications		The following example illustrates selecting all event notifications
	for EventClasses fault, state or config		for EventClasses fault, state or config
	<rpc message-id="101"		<rpc message-id="101"
	xmlns="urn:ietf:params:xml:ns:netconf:event:1.0">		xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
	<create-subscription>		<create-subscription>
	<eventClasses>		<eventClasses>
	<fault/>		<fault/>
	<state/>		<state/>
	<config/>		<config/>
	</eventClasses>		</eventClasses>
	</create-subscription>		</create-subscription>
	</rpc>		</rpc>
	6.2 Subtree Filtering		6.2 Subtree Filtering
	skipping to change at page 30, line 5		skipping to change at page 33, line 5
	Nevertheless, it may be used for defining simple notification		Nevertheless, it may be used for defining simple notification
	forwarding filters as shown below.		forwarding filters as shown below.
	The following example illustrates selecting fault EventClass which		The following example illustrates selecting fault EventClass which
	have severities of critical, major, or minor. The filtering criteria		have severities of critical, major, or minor. The filtering criteria
	evaluation is as follows:		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:event:1.0">		xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
	<create-subscription>		<create-subscription>
	<eventClasses>		<eventClasses>
	<fault/>		<fault/>
	</eventClasses>		</eventClasses>
	<netconf:filter type="subtree">		<netconf:filter type="subtree">
	<neb xmlns="urn:ietf:params:xml:ns:netconf:event:1.0">		<neb
			xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
	<event>		<event>
	<severity>critical</severity>		<severity>critical</severity>
	</event>		</event>
	<event>		<event>
	<severity>major</severity>		<severity>major</severity>
	</event>		</event>
	<event>		<event>
	<severity>minor</severity>		<severity>minor</severity>
	</event>		</event>
	</neb>		</neb>
	skipping to change at page 31, line 5		skipping to change at page 34, line 5
	</rpc>		</rpc>
	The following example illustrates selecting fault, state, config		The following example illustrates selecting fault, state, config
	EventClasses which have severities of critical, major, or minor and		EventClasses which have severities of critical, major, or minor and
	come from card Ethernet0. The filtering criteria evaluation is as		come from card Ethernet0. The filtering criteria evaluation is as
	follows:		follows:
	((fault | state | config) & ((fault & severity=critical) | (fault &		((fault | state | config) & ((fault & severity=critical) | (fault &
	severity=major) | (fault & severity = minor) | (card=Ethernet0)))		severity=major) | (fault & severity = minor) | (card=Ethernet0)))
	<rpc message-id="101"		<rpc message-id="101"
	xmlns="urn:ietf:params:xml:ns:netconf:event:1.0">		xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
	<create-subscription>		<create-subscription>
	<eventClasses>		<eventClasses>
	<fault/>		<fault/>
	<state/>		<state/>
	<config/>		<config/>
	</eventClasses>		</eventClasses>
	<netconf:filter type="subtree">		<netconf:filter type="subtree">
	<neb xmlns="urn:ietf:params:xml:ns:netconf:event:1.0">		<neb
			xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
	<event>		<event>
	<eventClasses>fault</eventClasses>		<eventClasses>fault</eventClasses>
	<severity>critical</severity>		<severity>critical</severity>
	</event>		</event>
	<event>		<event>
	<eventClasses>fault</eventClasses>		<eventClasses>fault</eventClasses>
	<severity>major</severity>		<severity>major</severity>
	</event>		</event>
	<event>		<event>
	<eventClasses>fault</eventClasses>		<eventClasses>fault</eventClasses>
	skipping to change at page 32, line 5		skipping to change at page 35, line 5
	6.3 XPATH filters		6.3 XPATH filters
	The following example illustrates selecting fault EventClass which		The following example illustrates selecting fault EventClass which
	have severities of critical, major, or minor. The filtering criteria		have severities of critical, major, or minor. The filtering criteria
	evaluation is as follows:		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:event:1.0">		xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
	<create-subscription>		<create-subscription>
	<eventClasses>		<eventClasses>
	<fault/>		<fault/>
	</eventClasses>		</eventClasses>
	<netconf:filter type="xpath">		<netconf:filter type="xpath">
	(/event[eventClasses/fault] and		(/event[eventClasses/fault] and
	(/event[severity="critical"] or		(/event[severity="critical"] or
	/event[severity="major"] or /event[severity="minor"]))		/event[severity="major"] or /event[severity="minor"]))
	</netconf:filter>		</netconf:filter>
	</create-subscription>		</create-subscription>
	skipping to change at page 32, line 27		skipping to change at page 35, line 27
	The following example illustrates selecting fault, state, config		The following example illustrates selecting fault, state, config
	EventClasses which have severities of critical, major, or minor and		EventClasses which have severities of critical, major, or minor and
	come from card Ethernet0. The filtering criteria evaluation is as		come from card Ethernet0. The filtering criteria evaluation is as
	follows:		follows:
	((fault | state | config) & ((fault & severity=critical) | (fault &		((fault | state | config) & ((fault & severity=critical) | (fault &
	severity=major) | (fault & severity = minor) | (card=Ethernet0)))		severity=major) | (fault & severity = minor) | (card=Ethernet0)))
	<rpc message-id="101"		<rpc message-id="101"
	xmlns="urn:ietf:params:xml:ns:netconf:event:1.0">		xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
	<create-subscription>		<create-subscription>
	<eventClasses>		<eventClasses>
	<fault/>		<fault/>
	<state/>		<state/>
	<config/>		<config/>
	</eventClasses>		</eventClasses>
	<netconf:filter type="xpath">		<netconf:filter type="xpath">
	((/event[eventClasses/fault] or		((/event[eventClasses/fault] or
	/event[eventClasses/state] or		/event[eventClasses/state] or
	/event[eventClasses/config]) and		/event[eventClasses/config]) and
	skipping to change at page 33, line 33		skipping to change at page 36, line 33
	association with a Netconf client. Unlike normal subscriptions,		association with a Netconf client. Unlike normal subscriptions,
	which only exist when they are active, these subscriptions live while		which only exist when they are active, these subscriptions live while
	both dormant and active. When an event of interest happens on the		both dormant and active. When an event of interest happens on the
	managed resource, the Netconf server checks the list of dormant		managed resource, the Netconf server checks the list of dormant
	subscriptions and if the filtering parameters in the subscription		subscriptions and if the filtering parameters in the subscription
	indicate interest in the Notification resulting from the event, then		indicate interest in the Notification resulting from the event, then
	the Netconf server initiates the connection to the specific Netconf		the Netconf server initiates the connection to the specific Netconf
	client and sends the Notification. When the Notification has been		client and sends the Notification. When the Notification has been
	sent, the connection is terminated.		sent, the connection is terminated.
			A subscription is active when it is currently session between the
			Netconf client and server related to this subscription on which
			Notifications can be sent. A subscription is dormant when there is
			currently no session set up between the Netconf client and server
			related to this notification subscription.
	7.1.1.1 Session Lifecycle		7.1.1.1 Session Lifecycle
	In order to avoid situations in which a sessions is continuously		In order to avoid situations in which a sessions is continuously
	setup and torn down, an inactivity timer is configured on the server.		setup and torn down, an inactivity timer is configured on the server.
	The timeout interval value is the same for all sessions (i.e. system		The timeout interval value is the same for all sessions (i.e. system
	wide) and each session has its own timer. Upon expiration of the		wide) and each session has its own timer. Upon expiration of the
	inactivity timer, the connection is terminated, otherwise if activity		inactivity timer, the connection is terminated, otherwise if activity
	is detected, the timer is reset.		is detected, the timer is reset.
	[Editor's note: alternatives here were to either create and tear down		[Editor's note: alternatives here were to either create and tear down
	skipping to change at page 33, line 47		skipping to change at page 37, line 4
	The timeout interval value is the same for all sessions (i.e. system		The timeout interval value is the same for all sessions (i.e. system
	wide) and each session has its own timer. Upon expiration of the		wide) and each session has its own timer. Upon expiration of the
	inactivity timer, the connection is terminated, otherwise if activity		inactivity timer, the connection is terminated, otherwise if activity
	is detected, the timer is reset.		is detected, the timer is reset.
	[Editor's note: alternatives here were to either create and tear down		[Editor's note: alternatives here were to either create and tear down
	the session for each notification received or to have the server		the session for each notification received or to have the server
	somehow figure out that there are more notifications coming soon		somehow figure out that there are more notifications coming soon
	after it has sent a notification and therefore keeps the connection		after it has sent a notification and therefore keeps the connection
	up.]		up.]
	The session establishment procedure is as follows:		The session establishment procedure is as follows:
	1) The NETCONF server initiates a session using a recognized		1) The NETCONF server checks to ensure there isn't already a suitable
	application protocol (SSH, Beep, SOAP, etc). In order to "activate"		notification session open.
	this reverse behaviour a new SSH subsystem may need to be defined.
			2) The NETCONF server initiates a session using a recognized
			transport protocol (SSH, Beep, SOAP, etc). In order to "activate"
			this reverse behavior a new SSH subsystem may need to be defined.
	This is for further study. In addition, the NE hosting the NETCONF		This is for further study. In addition, the NE hosting the NETCONF
	server must support both client and server modes in the case of SSH.		server must support both client and server modes in the case of SSH.
	2) Client and server are authenticated according to the underlying		3) Client and server are authenticated according to the underlying
	application protocol (e.g. SSH, BEEP)		transport protocol (e.g. SSH, BEEP)
	3) If using BEEP, as described in [NETCONF-BEEP] either party may		4) If using BEEP, as described in [NETCONF-BEEP] either party may
	initiate the BEEP session. Once this occurs, the assumption is that		initiate the BEEP session. Once this occurs, the assumption is that
	both parties know their roles. At this point, the NETCONF client,		both parties know their roles. At this point, the NETCONF client,
	initiates NETCONF session establishment whether running SSH or BEEP.		initiates NETCONF session establishment whether running SSH or BEEP.
	7.1.2 Dependencies		7.1.2 Dependencies
	This feature is dependant on the named profiles concept from the		This feature is dependant on the named profiles concept from the
	normal subscription method as well as the definition of		normal subscription method as well as the definition of
	<notification>.		<notification>.
	skipping to change at page 34, line 38		skipping to change at page 37, line 45
	7.1.3.1 New Operations		7.1.3.1 New Operations
	7.1.3.1.1 New Data Model		7.1.3.1.1 New Data Model
	<xs:schema		<xs:schema
	xmlns:xs="http://www.w3.org/2001/XMLSchema"		xmlns:xs="http://www.w3.org/2001/XMLSchema"
	xmlns:nsub="urn:ietf:params:xml:ns:netconf:subscription:1.0"		xmlns:nsub="urn:ietf:params:xml:ns:netconf:subscription:1.0"
	targetNamespace=		targetNamespace=
	"urn:ietf:params:xml:ns:netconf:callHomeSubscription:1.0"		"urn:ietf:params:xml:ns:netconf:callHomeSubscription:1.0"
	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:event:1.0"		xmlns:ncEvent= "urn:ietf:params:xml:ns:netconf:notification:1.0"
	xmlns:nm="urn:ietf:params:xml:ns:netconf:appInfo:1.0"		xmlns:nm="urn:ietf:params:xml:ns:netconf:appInfo:1.0"
	elementFormDefault="qualified"		elementFormDefault="qualified"
	attributeFormDefault="unqualified" xml:lang="en">		attributeFormDefault="unqualified" xml:lang="en">
	<xs:annotation>		<xs:annotation>
	<xs:documentation xml:lang="en">		<xs:documentation xml:lang="en">
	Schema for reporting on dormant Call-Home Notification		Schema for reporting on dormant Call-Home Notification
	Subscriptions		Subscriptions
	</xs:documentation>		</xs:documentation>
	<xs:appinfo>		<xs:appinfo>
	<nm:identity		<nm:identity
	skipping to change at page 35, line 27		skipping to change at page 38, line 35
	<xs:element name="callHomeSubscription">		<xs:element name="callHomeSubscription">
	<xs:annotation>		<xs:annotation>
	<xs:appinfo>		<xs:appinfo>
	<nm:minAccess><read/></nm:minAccess>		<nm:minAccess><read/></nm:minAccess>
	<nm:maxAccess><read/></nm:maxAccess>		<nm:maxAccess><read/></nm:maxAccess>
	</xs:appinfo>		</xs:appinfo>
	</xs:annotation>		</xs:annotation>
	<xs:complexType>		<xs:complexType>
	<xs:sequence>		<xs:sequence>
	<xs:element name="subscriber" type="xs:string">		<xs:element name="subscriber" >
	<xs:annotation>		<xs:annotation>
	<xs:documentation>		<xs:documentation>
	This needs to be replaced with a more		The Netconf client that is subscribed to
	prescriptive data type		receive these notifications as part of
			the call-home subscription.
	</xs:documentation>		</xs:documentation>
	</xs:annotation>		</xs:annotation>
			<xs:complexType>
			<xs:sequence>
			<xs:element type="ip:IPAddressOrSysname"
			name="iPAddressOrSysname"/>
			<xs:element type="xs:integer" name="port"/>
			</xs:sequence>
			</xs:complexType>
	</xs:element>		</xs:element>
	<xs:element name="namedProfile"		<xs:element name="namedProfile"
	type="xs:string" minOccurs="0">		type="xs:string" minOccurs="0">
	<xs:annotation>		<xs:annotation>
	<xs:documentation xml:lang="en">		<xs:documentation xml:lang="en">
	The named profile associated with this		The named profile associated with this
	subscription. Note that the		subscription. Note that the
	contents of the named profile may have		contents of the named profile may have
	changed since it was last applied		changed since it was last applied
	</xs:documentation>		</xs:documentation>
	</xs:annotation>		</xs:annotation>
	skipping to change at page 39, line 5		skipping to change at page 42, line 10
	To be determined once specific aspects of this solution are better		To be determined once specific aspects of this solution are better
	understood. In particular, the access control framework and the		understood. In particular, the access control framework and the
	choice of transport will have a major impact on the security of the		choice of transport will have a major impact on the security of the
	solution		solution
	9. IANA Considerations		9. IANA Considerations
	Event Classes will likely be an IANA-managed resource. The initial		Event Classes will likely be an IANA-managed resource. The initial
	set of values is defined in this specification.		set of values is defined in this specification.
			In order for new event classes to be allocated, the following
			requirements must be met:
			o There must be working group consensus to add the new class
			o A detailed description of its purpose in the netconf protocol must
			be provided
			o A detailed description of all manager and agent implementation
			requirements associated with the event class must be provided
			o The description must make clear to developers how to determine
			when it is appropriate to choose this event classification for a
			new notification type
			list
	10. Acknowledgements		10. Acknowledgements
	Thanks to Gilbert Gagnon and Greg Wilbur for providing their input		Thanks to Gilbert Gagnon and Greg Wilbur for providing their input
	into the early work on this document. In addition, the editors would		into the early work on this document. In addition, the editors would
	like to acknowledge input at the Vancouver editing session from the		like to acknowledge input at the Vancouver editing session from the
	following people: Orly Nicklass, James Bakstrieve, Yoshifumi		following people: Orly Nicklass, James Bakstrieve, Yoshifumi
	Atarashi, Glenn Waters, Alexander Clemm, Dave Harrington, Dave		Atarashi, Glenn Waters, Alexander Clemm, Dave Harrington, Dave
	Partain, Ray Atarashi and Dave Perkins.		Partain, Ray Atarashi and Dave Perkins. In addition, they would like
			to thank Balazs Lengyel his contributions to the event class text.
	11. References		11. 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.
	[NETCONF BEEP]		[NETCONF BEEP]
	Lear, E. and K. Crozier, "Using the NETCONF Protocol over		Lear, E. and K. Crozier, "Using the NETCONF Protocol over
	Blocks Extensible Exchange Protocol (BEEP)",		Blocks Extensible Exchange Protocol (BEEP)",
	ID draft-ietf-netconf-beep-10, March 2006.		ID draft-ietf-netconf-beep-10, March 2006.
	skipping to change at page 52, line 5		skipping to change at page 56, line 5
	in which it wants the NETCONF server to issue the event notifications		in which it wants the NETCONF server to issue the event notifications
	at subscription time by specifying the appropriate namespace under		at subscription time by specifying the appropriate namespace under
	the Filter parameter in the <create-subscription> operation. An		the Filter parameter in the <create-subscription> operation. An
	example is provided below:		example is provided below:
	<netconf:filter>		<netconf:filter>
	<data-format:config-format-xml		<data-format:config-format-xml
	xmlns="http://www.example.com/xmlnetevents"/>		xmlns="http://www.example.com/xmlnetevents"/>
	</netconf:filter>		</netconf:filter>
			Appendix D. IP Address Schema
			<?xml version="1.0" encoding="UTF-8"?>
			<!-- IETF Netconf Working Group
			http://www.ietf.org/html.charters/netconf-charter.html
			-->
			<xs:schema elementFormDefault="qualified"
			attributeFormDefault="unqualified" version="0.2"
			xmlns:xs="http://www.w3.org/2001/XMLSchema"
			xmlns="urn:ietf:params:xml:ns:netmod:ipAddress:1.0"
			targetNamespace="urn:ietf:params:xml:ns:netmod:ipAddress:1.0">
			<xs:simpleType name = "ipV4Addr">
			<xs:annotation>
			<xs:documentation>
			An IP version 4 address in dotted notation decimal.
			Example: 15.13.120.22
			</xs:documentation>
			</xs:annotation>
			<xs:restriction base = "xs:string">
			<xs:pattern value =
			"[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}"/>
			</xs:restriction>
			</xs:simpleType>
			<xs:simpleType name = "ipV6Addr">
			<xs:annotation>
			<xs:documentation>
			An IP version 6 address in colon separated 2 byte
			block hexadecimal notation.
			Example: FEDC:AB19:12FE:0234:98EF:1178:8891:CAFF
			</xs:documentation>
			</xs:annotation>
			<xs:restriction base = "xs:string">
			<xs:pattern value =
			"[0-9a-fA-F]{4}:[0-9a-fA-F]{4}:[0-9a-fA-F]{4}:
			[0-9a-fA-F]{4}:[0-9a-fA-F]{4}:
			[0-9a-fA-F]{4}:[0-9a-fA-F]{4}:[0-9a-fA-F]{4}"/>
			</xs:restriction>
			</xs:simpleType>
			<xs:complexType name="IPAddressOrSysname">
			<xs:choice>
			<xs:element name="ipv4Address" type="ipV4Addr"/>
			<xs:element name="ipv6Address" type="ipV6Addr"/>
			<xs:element name="sysName" type="xs:string"/>
			</xs:choice>
			</xs:complexType>
			</xs:schema>
	Intellectual Property Statement		Intellectual Property Statement
	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
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
End of changes. 65 change blocks.
	158 lines changed or deleted		399 lines changed or added
This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/