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/