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/ |