draft-ietf-netconf-notification-03.txt   draft-ietf-netconf-notification-04.txt 
Network Working Group S. Chisholm Network Working Group S. Chisholm
Internet-Draft Nortel Internet-Draft Nortel
Expires: March 18, 2007 H. Trevino Intended status: Standards Track H. Trevino
Cisco Expires: April 25, 2007 Cisco
September 14, 2006 October 22, 2006
NETCONF Event Notifications NETCONF Event Notifications
draft-ietf-netconf-notification-03.txt draft-ietf-netconf-notification-04.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 March 18, 2007. This Internet-Draft will expire on April 25, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This memo defines a framework for sending asynchronous messages, or This document defines mechanisms which provide an asynchronous
event notifications in NETCONF. It defines both the operations message notification delivery service for the NETCONF protocol. This
necessary to support this concept, and also discusses implications is an optional capability built on top of the base NETCONF
for the mapping to transport protocols. definition. This document defines the capabilities, operations,
transport mappings, and data models necessary to support this
service.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Definition of Terms . . . . . . . . . . . . . . . . . . . 4 1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 4
1.2 Event Notifications in NETCONF . . . . . . . . . . . . . . 5 1.2. Event Notifications in NETCONF . . . . . . . . . . . . . . 5
1.3 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 1.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
2. Notification-Related Operations . . . . . . . . . . . . . . . 7 2. Notification-Related Operations . . . . . . . . . . . . . . . 7
2.1 Subscribing to receive Event Notifications . . . . . . . . 7 2.1. Subscribing to receive Event Notifications . . . . . . . . 7
2.1.1 create-subscription . . . . . . . . . . . . . . . . . 7 2.1.1. <create-subscription> . . . . . . . . . . . . . . . . 7
2.2 Sending Event Notifications . . . . . . . . . . . . . . . 8 2.1.2. Filter Dependencies . . . . . . . . . . . . . . . . . 8
2.2.1 Event Notification . . . . . . . . . . . . . . . . . . 8 2.2. Sending Event Notifications . . . . . . . . . . . . . . . 8
2.3 Terminating the Subscription . . . . . . . . . . . . . . . 9 2.2.1. <notification> . . . . . . . . . . . . . . . . . . . . 8
2.3. Terminating the Subscription . . . . . . . . . . . . . . . 9
3. Supporting Concepts . . . . . . . . . . . . . . . . . . . . . 10 3. Supporting Concepts . . . . . . . . . . . . . . . . . . . . . 10
3.1 Capabilities Exchange . . . . . . . . . . . . . . . . . . 10 3.1. Capabilities Exchange . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . 17 3.2.6. Event Stream Subscription . . . . . . . . . . . . . . 15
3.3 Subscriptions and Datastores . . . . . . . . . . . . . . . 17 3.3. Subscriptions not Configuration Data . . . . . . . . . . . 15
3.4 Querying Subscription Properties . . . . . . . . . . . . . 18 3.4. Querying Subscription Properties . . . . . . . . . . . . . 16
3.5 One-way Notification Messages . . . . . . . . . . . . . . 22 3.5. Filter Dependencies . . . . . . . . . . . . . . . . . . . 20
3.6 Filter Dependencies . . . . . . . . . . . . . . . . . . . 22 3.5.1. Named Profiles . . . . . . . . . . . . . . . . . . . . 21
3.6.1 Named Profiles . . . . . . . . . . . . . . . . . . . . 23 3.5.2. Filtering . . . . . . . . . . . . . . . . . . . . . . 21
3.6.2 Filtering . . . . . . . . . . . . . . . . . . . . . . 23 3.6. Message Flow . . . . . . . . . . . . . . . . . . . . . . . 21
3.7 Message Flow . . . . . . . . . . . . . . . . . . . . . . . 23 4. XML Schema for Event Notifications . . . . . . . . . . . . . . 23
4. XML Schema for Event Notifications . . . . . . . . . . . . . . 25 5. Mapping to Transport Protocols . . . . . . . . . . . . . . . . 25
5. Mapping to Transport Protocols . . . . . . . . . . . . . . . . 27 5.1. SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.1 SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.2. BEEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2 BEEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.2.1. One-way Notification Messages in Beep . . . . . . . . 26
5.2.1 One-way Notification Messages in Beep . . . . . . . . 28 5.3. SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.3 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.3.1. A NETCONF over Soap over HTTP Example . . . . . . . . 27
5.3.1 A NETCONF over Soap over HTTP Example . . . . . . . . 29 6. Filtering examples . . . . . . . . . . . . . . . . . . . . . . 30
6. Filtering examples . . . . . . . . . . . . . . . . . . . . . . 32 6.1. Subtree Filtering . . . . . . . . . . . . . . . . . . . . 30
6.1 Subtree Filtering . . . . . . . . . . . . . . . . . . . . 32 6.2. XPATH filters . . . . . . . . . . . . . . . . . . . . . . 31
6.2 XPATH filters . . . . . . . . . . . . . . . . . . . . . . 33 7. Notification Replay Capability . . . . . . . . . . . . . . . . 33
7. Notification Replay Capability . . . . . . . . . . . . . . . . 35 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 35 7.2. Dependencies . . . . . . . . . . . . . . . . . . . . . . . 33
7.2 Dependencies . . . . . . . . . . . . . . . . . . . . . . . 35 7.3. Capability Identifier . . . . . . . . . . . . . . . . . . 33
7.3 Capability Identifier . . . . . . . . . . . . . . . . . . 35 7.4. New Operations . . . . . . . . . . . . . . . . . . . . . . 34
7.4 New Operations . . . . . . . . . . . . . . . . . . . . . . 35 7.5. Modifications to Existing Operations . . . . . . . . . . . 34
7.5 Modifications to Existing Operations . . . . . . . . . . . 36 7.5.1. create-subscription . . . . . . . . . . . . . . . . . 34
7.5.1 create-subscription . . . . . . . . . . . . . . . . . 36 7.5.2. Interactions with Other Capabilities . . . . . . . . . 34
7.5.2 Interactions with Other Capabilities . . . . . . . . . 36 7.6. Replay Complete Notification . . . . . . . . . . . . . . . 34
8. Security Considerations . . . . . . . . . . . . . . . . . . . 37 8. Security Considerations . . . . . . . . . . . . . . . . . . . 36
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 10. Normative References . . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
Intellectual Property and Copyright Statements . . . . . . . . 40 Intellectual Property and Copyright Statements . . . . . . . . . . 40
1. Introduction 1. Introduction
NETCONF [NETCONF-PROTO] can be conceptually partitioned into four [NETCONF] can be conceptually partitioned into four layers:
layers:
Layer Example Layer Example
+-------------+ +----------------------------------------+ +-------------+ +----------------------------------------+
| Content | | Configuration data | | Content | | Configuration data |
+-------------+ +----------------------------------------+ +-------------+ +----------------------------------------+
| | | |
+-------------+ +-------------------------------------------+ +-------------+ +-------------------------------------------+
| Operations | | <get-config>, <edit-config> <notification>| | Operations | | <get-config>, <edit-config> <notification>|
+-------------+ +-------------------------------------------+ +-------------+ +-------------------------------------------+
| | | | | |
+-------------+ +-----------------------------+ | +-------------+ +-----------------------------+ |
| RPC | | <rpc>, <rpc-reply> | | | RPC | | <rpc>, <rpc-reply> | |
+-------------+ +-----------------------------+ | +-------------+ +-----------------------------+ |
| | | | | |
+-------------+ +------------------------------------------+ +-------------+ +------------------------------------------+
| Transport | | BEEP, SSH, SSL, console | | Transport | | BEEP, SSH, SSL, console |
| Protocol | | | | Protocol | | |
+-------------+ +------------------------------------------+ +-------------+ +------------------------------------------+
This document defines a framework for sending asynchronous messages, This document defines mechanisms which provide an asynchronous
or event notifications in NETCONF. It defines both the operations message notification delivery service for the [NETCONF] protocol.
necessary to support this concept, and also discusses implications This is an optional capability built on top of the base NETCONF
for the mapping to transport protocols. definition. This memo defines the capabilities, operations,
transport mappings, and data models necessary to support this
service.
Figure 1 Figure 1
1.1 Definition of Terms 1.1. Definition of Terms
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3]. document are to be interpreted as described in [RFC2119].
Element: An XML Element[XML].
Managed Entity: A node, which supports NETCONF[NETCONF-PROTO] and has Element: An [XML] Element.
access to management instrumentation. This is also known as the
NETCONF server.
Managed Object: A collection of one of more Elements that define an Managed Object: A collection of one of more Elements that define an
abstract thing of interest. abstract thing of interest.
Subscription: A concept related to the delivery of notifications (if Subscription: A concept related to the delivery of notifications (if
any to send) involving destination and selection of notifications. any to send) involving destination and selection of notifications.
It is bound to the lifetime of a session. It is bound to the lifetime of a session.
1.2 Event Notifications in NETCONF Operation: This term is used to refer to NETCONF protocol
operations. Specifically within this document, operation refers
to NETCONF protocol operations defined in support of NETCONF
notifications.
1.2. Event Notifications in NETCONF
An event is something that happens which may be of interest - a An event is something that happens which may be of interest - a
configuration change, a fault, a change in status, crossing a configuration change, a fault, a change in status, crossing a
threshold, or an external input to the system, for example. Often threshold, or an external input to the system, for example. Often
this results in an asynchronous message, sometimes referred to as a this results in an asynchronous message, sometimes referred to as a
notification or event notification, being sent out to interested notification or event notification, being sent out to interested
parties to notify them that this event has occurred. parties to notify them that this event has occurred.
This memo defines a mechanism whereby the NETCONF client indicates This memo defines a mechanism whereby the NETCONF client indicates
interest in receiving event notifications from a NETCONF server by interest in receiving event notifications from a NETCONF server by
skipping to change at page 5, line 31 skipping to change at page 5, line 32
server replies to indicate whether the subscription request was server replies to indicate whether the subscription request was
successful and, if it was successful, begins sending the event successful and, if it was successful, begins sending the event
notifications to the NETCONF client as the events occur within the notifications to the NETCONF client as the events occur within the
system. These event notifications will continue to be sent until system. These event notifications will continue to be sent until
either the NETCONF session is terminated or some event, outside the either the NETCONF session is terminated or some event, outside the
scope of this specification, causes the subscription to terminate. scope of this specification, causes the subscription to terminate.
The event notification subscription allows a number of options to The event notification subscription allows a number of options to
enable the NETCONF client to specify which events are of interest. enable the NETCONF client to specify which events are of interest.
These are specified when the subscription is created. These are specified when the subscription is created.
An agent is not required to process RPC requests until the An NETCONF server is not required to process RPC requests on the
notification stream is done. A capability may be defined to announce session associated with the subscription until the notification
that a server is able to process RPCs while a notification stream is stream is done. A capability may be advertised to announce that a
active on a session. server is able to 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 requirements for this solution are as follows: The following requirements have been addressed by the solution:
o Initial release should ensure it supports notification in support o Initial release should ensure it supports notification in support
of configuration operations of configuration operations
o Data content must not preclude the use of the same data model as o Data content must not preclude the use of the same data model as
used in configuration used in configuration
o solution should support a reasonable message size limit (syslog o solution should support a reasonable message size limit (syslog
and SNMP are rather constrained in terms of message sizes) and SNMP are rather constrained in terms of message sizes)
o solution should provide reliable delivery of notifications o solution should provide reliable delivery of notifications
o solution should support agent initiated connections o solution should provide a subscription mechanism (A NETCONF server
does not send notifications before asked to do so and the NETCONF
o solution should provide a subscription mechanism (An agent does client initiates the flow of notifications)
not send notifications before asked to do so and the manager
initiates the flow of notifications)
o solution should provide a filtering mechanism o solution should provide a filtering mechanism within the Netconf
server
o solution should send sufficient information in a notification so o solution should send sufficient information in a notification so
that it can be analyzed independent of the transport mechanism that it can be analyzed independent of the transport mechanism
(data content fully describes a notification; protocol information (data content fully describes a notification; protocol information
is not needed to understand a notification) is not needed to understand a notification)
o solution should not bind subscriptions to a connection
o channels for configuration change notifications should share fate
with a session that includes a configuration channel
o solution should support replay of locally logged notifications o solution should support replay of locally logged notifications
2. Notification-Related Operations 2. Notification-Related Operations
2.1 Subscribing to receive Event Notifications 2.1. Subscribing to receive Event Notifications
The event notification subscription is initiated by the NETCONF The event notification subscription is initiated by the NETCONF
client and responded to by the NETCONF server. When the event client and responded to by the NETCONF server. When the event
notification subscription is created, the events of interest are notification subscription is created, the events of interest are
specified. specified.
Content for an event notification subscription can be selected by Content for an event notification subscription can be selected by
applying user-specified filters. applying user-specified filters.
2.1.1 create-subscription 2.1.1. <create-subscription>
<create-subscription>
Description: Description:
This operation initiates an event notification subscription which This operation initiates an event notification subscription which
will send asynchronous event notifications to the initiator of the will send asynchronous event notifications to the initiator of the
command until the NETCONF session terminates or some event, command until the NETCONF session terminates or some event,
outside the scope of this specification, causes the subscription outside the scope of this specification, causes the subscription
to terminate. to terminate.
Parameters: Parameters:
Stream: Streams:
An optional parameter that indicates which stream(s) of events An optional parameter that indicates which stream(s) of events
are of interest. If not present, then events in the default are of interest. If not present, then events in the default
NETCONF stream will be sent. NETCONF stream will be sent.
Filter: Filter:
An optional parameter that indicates which subset of all An optional parameter that indicates which subset of all
possible events are of interest. The format of this parameter possible events are of interest. The format of this parameter
is the same as that of the filter parameter in the NETCONF is the same as that of the filter parameter in the NETCONF
protocol operations. If not present, all events not precluded protocol operations. If not present, all events not precluded
by other parameters will be sent. by other parameters will be sent.
Named Profile Named Profile:
An optional parameter that points to a separately defined An optional parameter that points to a separately defined
filter profile. The contents of the profile are specified in filter profile. The contents of the profile are specified in
the provided XML Schema. If not present, no additional the provided [XML Schema]. If not present, no additional
filtering will be applied. Note that changes to the profile filtering will be applied. Note that changes to the profile
after the subscription has been created will have no effect. after the subscription has been created will have no effect.
Start Time:
A parameter used with the optional replay capability to signals
that this is a replay subscription and that the replay should
start at the time specified. If start time is not present,
this is not a replay subscription. Stop time for replay is
implicitly defined to be the time the create-subscription
command was received by the Netconf server.
Positive Response: Positive Response:
If the NETCONF server can satisfy the request, the server sends an If the NETCONF server can satisfy the request, the server sends an
<rpc-reply> element containing a <data> element containing the <ok> element.
subscription ID.
Negative Response: Negative Response:
An <rpc-error> element is included within the <rpc-reply> if the An <rpc-error> element is included within the <rpc-reply> if the
request cannot be completed for any reason. Subscription requests request cannot be completed for any reason. Subscription requests
will fail if a filter with invalid syntax is provided or if the will fail if a filter with invalid syntax is provided or if the
name of a non-existent profile or stream is provided. name of a non-existent profile or stream is provided.
2.2 Sending Event Notifications 2.1.2. Filter Dependencies
When multiple filters are specified (in-line Filter, Named Profiles),
they are applied collectively (i.e. logical AND operation). That is,
event notifications must pass all specified filters in order to be
sent to the subscriber.
2.2. Sending Event Notifications
Once the subscription has been set up, the NETCONF server sends the Once the subscription has been set up, the NETCONF server sends the
event notifications asynchronously along the connection. event notifications asynchronously along the connection.
2.2.1 Event Notification 2.2.1. <notification>
<notification>
Description: Description:
An event notification is sent to the initiator of an <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. occurred. An event notification is a complete XML document. Note
that <notification> is not an RPC method but rather the top level
element identifying the one way message as a notification.
Parameters: Parameters:
Subscription Id:
A unique identifier for this event subscription
Data: Data:
Contains notification-specific tagged content. Contains notification-specific tagged content.
Positive Response: Response:
No response.
Negative Response:
No response. No response. Not applicable.
2.3 Terminating the Subscription 2.3. Terminating the Subscription
Closing of the event notification subscription is done by terminating Closing of the event notification subscription is done by terminating
the Netconf session ( <kill-session> )or via some action outside the the Netconf session ( <kill-session> )or via some action outside the
scope of this specification. scope of this specification.
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.
"urn:ietf:params:xml:ns:netconf:notification:1.0" "urn:ietf:params:xml:ns:netconf:capability:notification:1.0"
For Example For Example
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities> <capabilities>
<capability> <capability>
urn:ietf:params:xml:ns:netconf:base:1.0 urn:ietf:params:xml:ns:netconf:base:1.0
</capability> </capability>
<capability> <capability>
urn:ietf:params:xml:ns:netconf:capability:startup:1.0 urn:ietf:params:xml:ns:netconf:capability:startup:1.0
</capability> </capability>
<capability> <capability>
urn:ietf:params:xml:ns:netconf:notification:1.0 urn:ietf:params:xml:ns:netconf:capability:notification:1.0
</capability> </capability>
</capabilities> </capabilities>
<session-id>4</session-id> <session-id>4</session-id>
</hello> </hello>
3.2 Event Streams 3.2. Event Streams
An event stream is defined herein as a set of event notifications An event stream is defined herein as a set of event notifications
matching some forwarding criteria. matching some forwarding criteria.
System components generate event notifications which are passed to a System components generate event notifications which are passed to a
central component for classification and distribution. The central central component for classification and distribution. The central
component inspects each event notification and matches the event component inspects each event notification and matches the event
notification against the set of stream definitions. When a match notification against the set of stream definitions. When a match
occurs, the event notification is considered to be a member of that occurs, the event notification is considered to be a member of that
event stream. An event notification may be part of multiple event event stream. An event notification may be part of multiple event
skipping to change at page 11, line 26 skipping to change at page 11, line 26
| cn |---+ | (notification) | cn |---+ | (notification)
+----+ +-----> ( logging ) +----+ +-----> ( logging )
( service ) ( service )
(------------) (------------)
+-------+ +-------+ +-------+ +-------+
|netconf|<--->|netconf| |netconf|<--->|netconf|
-> |server | |client | -> |server | |client |
+-------+ +-------+ +-------+ +-------+
3.2.1 Event Stream Definition 3.2.1. Event Stream Definition
Event streams are pre-defined on the managed device. The Event streams are predefined on the managed device. The
configuration of event streams is outside the scope of this document. configuration of event streams is outside the scope of this document.
However, it is envisioned that event streams are either pre- However, it is envisioned that event streams are either pre-
established by the vendor (pre-configured) or user configurable (e.g. established by the vendor (pre-configured) or user configurable (e.g.
part of the device's configuration) or both. Device vendors may part of the device's configuration) or both. Device vendors may
allow event stream configuration via NETCONF protocol (i.e. edit- allow event stream configuration via NETCONF protocol (i.e. edit-
config operation) config operation)
3.2.2 Event Stream Content Format 3.2.2. Event Stream Content Format
The contents of all event streams made available to a NETCONF client The contents of all event streams made available to a NETCONF client
(i.e. the notification sent by the NETCONF server) must be encoded in (i.e. the notification sent by the NETCONF server) must be encoded in
XML. XML.
3.2.3 Default Event Stream 3.2.3. Default Event Stream
A NETCONF server implementation supporting the notification A NETCONF server implementation supporting the notification
capability must support the "NETCONF" notification event stream. capability must support the "NETCONF" notification event stream.
This stream contains all NETCONF XML event notifications supported by This stream contains all NETCONF XML event notifications supported by
the NETCONF server. The definition of the event notification and the NETCONF server. The definition of the event notification and
their contents for this event stream is outside the scope of this their contents for this event stream is outside the scope of this
document. document.
3.2.4 Event Stream Sources 3.2.4. Event Stream Sources
With the exception of the default event stream (NETCONF With the exception of the default event stream (NETCONF
notifications) specification of additional event stream sources (e.g. notifications) specification of additional event stream sources (e.g.
SNMP, syslog, etc.) is outside the scope of this document. NETCONF SNMP, syslog, etc.) is outside the scope of this document. NETCONF
server implementations may leverage any desired event stream source server implementations may leverage any desired event stream source
in the creation of supported event streams. in the creation of supported event streams.
3.2.5 Event Stream Discovery 3.2.5. Event Stream Discovery
A NETCONF client retrieves the list of supported event streams from a A NETCONF client retrieves the list of supported event streams from a
NETCONF server using the <get> or <get-config> RPC request. NETCONF server using the <get> RPC request.
3.2.5.1 Name Retrieval using get, get-config RPC 3.2.5.1. Name Retrieval using <get> operation
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> or <get-config> operation. <eventStreams> subtree via a <get>operation. Available event streams
Available event streams for the requesting session are returned in for the requesting session are returned in the reply containing
the reply containing <name> and <description> elements, where <name> and <description> elements, where <name> element is mandatory
<name> element is mandatory and its value is unique [Editor's Note: and its value is unique [Editor's Note: should we then define it as a
should we then define it as a key?]. The returned list must only key?]. The returned list must only include the names of those event
include the names of those event streams for which the NETCONF streams for which the NETCONF sessions has sufficient privileges.
sessions has sufficient privileges. The NETCONF session privileges The NETCONF session privileges are determined via access control
are determined via access control mechanisms which are beyond the mechanisms which are beyond the scope of this document. An empty
scope of this document. An empty reply is returned if there are no reply is returned if there are no available event streams.
available event streams.
Retrieving available event stream list using <get-config> operation:
<get-config> Retrieving available event stream list using <get> operation:
<source>
<running/>
</source>
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<sessionEventStream>
<eventStreams/>
</sessionEventStream>
</top>
</filter>
</get-config>
</rpc>
<rpc-reply 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">
<data>
<top xmlns="http://example.com/schema/1.2/config">
<sessionEventStream>
<eventStreams>
<stream>
<name>NETCONF</name>
<description>Default netconf event stream
</description>
</stream>
<stream>
<name>snmp</name>
<description>SNMP notifications</description>
</stream>
<stream>
<name>syslog-critical</name>
<description>Critical and higher severity
</description>
</stream>
</sessionEventStreams>
</eventStreams>
</top>
</data>
</rpc-reply>
Retrieving available event stream list using <get> operation:
<get> <get>
<filter type="subtree"> <filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config"> <top xmlns="urn:ietf:params:xml:ns:netmod:base:1.0">
<sessionEventStreams>
<eventStreams/> <eventStreams/>
</sessionEventStreams>
</top> </top>
</filter> </filter>
</get> </get>
</rpc> </rpc>
<rpc-reply message-id="101" <rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data> <data>
<top xmlns="http://example.com/schema/1.2/config"> <top ="urn:ietf:params:xml:ns:netmod:base:1.0">
<sessionEventStreams>
<eventStreams> <eventStreams>
<stream> <stream>
<name>NETCONF</name> <name>NETCONF</name>
<description>Default netconf event stream <description>Default netconf event stream
</description> </description>
</stream> </stream>
<stream> <stream>
<name>snmp</name> <name>snmp</name>
<description>SNMP notifications</description> <description>SNMP notifications</description>
</stream> </stream>
<stream> <stream>
<name>syslog-critical</name> <name>syslog-critical</name>
<description>Critical and higher severity <description>Critical and higher severity
</description> </description>
</stream> </stream>
</eventStreams> </eventStreams>
</sessionEventStreams>
</top> </top>
</data> </data>
</rpc-reply> </rpc-reply>
3.2.5.2 Device Supported Event Streams (System) 3.2.5.2. Device Supported Event Streams (System)
The list of all event streams configured on a device may be retrieved The list of all event streams configured on a device may be retrieved
over a NETCONF session with sufficient privileges (e.g. over a NETCONF session with sufficient privileges (e.g.
administrator). The information is retrieved by requesting the administrator). The information is retrieved by requesting the
<systemEventStreams> subtree via a <get> or <get-config> <eventStreams> subtree via a <get> operation.
operation.
<get-config>
<source>
<running/>
</source>
<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config">
<systemEventStreams/>
</top>
</filter>
</get-config>
</rpc>
<rpc-reply message-id="101" 3.2.5.3. Stream Retrieval Schema
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<top xmlns="http://example.com/schema/1.2/config">
<systemEventStreams>
<stream>
<name>NETCONF</name>
<description>Default netconf event stream
</description>
</stream>
<stream>
<name>snmp</name>
<description>SNMP notifications
</description>
</stream>
<stream>
<name>syslog-critical</name>
<description>Critical and higher severity
</description>
</stream>
</systemEventStreams>
</top>
</data>
</rpc-reply>
3.2.5.3 Stream Retrieval 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"
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 Schema for event streams
</xs:documentation> </xs:documentation>
<xs:appinfo> <xs:appinfo>
skipping to change at page 16, line 26 skipping to change at page 14, line 29
<nm:Name> <nm:Name>
NetconfNotificationSchema NetconfNotificationSchema
</nm:Name> </nm:Name>
<nm:LastUpdated> <nm:LastUpdated>
2006-09-06T09:30:47-05:00 2006-09-06T09:30:47-05:00
</nm:LastUpdated> </nm:LastUpdated>
<nm:Organization>IETF <nm:Organization>IETF
</nm:Organization> </nm:Organization>
<nm:Description> <nm:Description>
A schema that can be used to learn about current A schema that can be used to learn about current
NetConf Event subscriptions and creating named event streams.
profiles
</nm:Description> </nm:Description>
</nm:identity> </nm:identity>
</xs:appinfo> </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="./draft-ietf-netconf-prot-12.xsd"/>
<xs:element name="sessionEventStreams"> <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>
<xs:sequence maxOccurs="unbounded"> <xs:sequence maxOccurs="unbounded">
<xs:element name="stream"> <xs:element name="stream">
skipping to change at page 17, line 20 skipping to change at page 15, line 22
<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: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> </xs:schema>
3.2.6 Event Stream Subscription 3.2.6. Event Stream Subscription
A NETCONF client may request from the NETCONF server the list of A NETCONF client may request from the NETCONF server the list of
available event streams to this session and then issue a <create- available event streams to this session and then issue a <create-
subscription> request with the desired event stream name. Omitting subscription> request with the desired event stream name. Omitting
the event stream name from the <create-subscription> request results the event stream name from the <create-subscription> request results
in subscription to the default NETCONF event stream. in subscription to the default NETCONF event stream.
3.2.6.1 Filtering Event Stream Contents 3.2.6.1. Filtering Event Stream Contents
The set of event notifications delivered in an event stream may be The set of event notifications delivered in an event stream may be
further refined by applying a user-specified filter at subscription further refined by applying a user-specified filter at subscription
creation time ( <create-subscription> ). This is a transient filter creation time ( <create-subscription> ). This is a transient filter
associated with the event notification subscription and does not associated with the event notification subscription and does not
modify the event stream configuration. modify the event stream configuration.
3.2.6.2 Subscription to Multiple Event Streams 3.2.6.2. Subscription to Multiple Event Streams
Multiple event streams may be configured on a device and a NETCONF Multiple event streams may be configured on a device and a NETCONF
client may subscribe to one or more of the available event streams. client may subscribe to one or more of the available event streams.
A NETCONF client subscribing to multiple event streams must do so by
either establishing a new NETCONF session or opening a new channel on
an existing NETCONF session.
3.3 Subscriptions and Datastores 3.3. Subscriptions not Configuration Data
Subscriptions are like NETCONF sessions in that they don't exist in While it is possible to retrieve information about subscriptions via
NETCONF datastores. The exception to this is the named profiles a get operation, subscriptions are not stored configuration. They
feature. are non-persistent state information. In this respect, they are
comparable to NETCONF sessions.
3.4 Querying Subscription Properties Named profiles, if used, are considered configuration data.
3.4. Querying Subscription Properties
The following Schema can be used to retrieve information about active The following Schema can be used to retrieve information about active
event notification subscriptions event notification subscriptions
<xs:schema <xs:schema
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:nsub="urn:ietf:params:xml:ns:netconf:subscription:1.0" xmlns:nsub="urn:ietf:params:xml:ns:netconf:subscription:1.0"
targetNamespace="urn:ietf:params:xml:ns:netconf:subscription:1.0" targetNamespace="urn:ietf:params:xml:ns:netconf:subscription:1.0"
xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:ncEvent="urn:ietf:params:xml:ns:netconf:notification:1.0" xmlns:ncEvent="urn:ietf:params:xml:ns:netconf:notification:1.0"
skipping to change at page 18, line 34 skipping to change at page 16, line 32
</xs:documentation> </xs:documentation>
<xs:appinfo> <xs:appinfo>
<nm:identity <nm:identity
xmlns:nm="urn:ietf:params:xml:ns:netmod:base:1.0"> xmlns:nm="urn:ietf:params:xml:ns:netmod:base:1.0">
<nm:Name>NetconfNotificationSchema</nm:Name> <nm:Name>NetconfNotificationSchema</nm:Name>
<nm:LastUpdated>2006-09-13T09:30:47-05:00 <nm:LastUpdated>2006-09-13T09:30:47-05:00
</nm:LastUpdated> </nm:LastUpdated>
<nm:Organization>IETF</nm:Organization> <nm:Organization>IETF</nm:Organization>
<nm:Description> <nm:Description>
A schema that can be used to learn about current A schema that can be used to learn about current
NetConf Event subscriptions and creating named NETCONF Event subscriptions and creating named
profiles profiles
</nm:Description> </nm:Description>
</nm:identity> </nm:identity>
</xs:appinfo> </xs:appinfo>
</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 <xs:import
namespace="urn:ietf:params:xml:ns:netconf:notification:1.0" namespace="urn:ietf:params:xml:ns:netconf:notification:1.0"
schemaLocation= schemaLocation=
"urn:ietf:params:xml:ns:netconf:notification:1.0"/> "urn:ietf:params:xml:ns:netconf:notification:1.0"/>
<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="urn:ietf:params:xml:ns:netconf:base:1.0"/> schemaLocation="urn:ietf:params:xml:ns:netconf:base:1.0"/>
<!-- Associations --> <!-- Associations -->
<xs:element name="associatedNamedProfile" type="xs:string"/>
<xs:element name="associatedNamedProfile" type="xs:string"/>
<xs:element name="relationships"> <xs:element name="relationships">
<xs:keyref name="subscriptionToNamedProfile" <xs:keyref name="subscriptionToNamedProfile"
refer="nsub:namedProfileKey"> refer="nsub:namedProfileKey">
<xs:selector xpath=".//netconfSubscription"/> <xs:selector xpath=".//netconfSubscription"/>
<xs:field xpath="nsub:associatedNamedProfile"/> <xs:field xpath="nsub:associatedNamedProfile"/>
</xs:keyref> </xs:keyref>
<!-- Keys --> <!-- Keys -->
<xs:key name="namedProfileKey"> <xs:key name="namedProfileKey">
skipping to change at page 19, line 35 skipping to change at page 17, line 33
<nm:maxAccess><read/></nm:maxAccess> <nm:maxAccess><read/></nm:maxAccess>
</xs:appinfo> </xs:appinfo>
</xs:annotation> </xs:annotation>
<xs:complexType> <xs:complexType>
<xs:sequence > <xs:sequence >
<xs:element name="session-id" <xs:element name="session-id"
type="netconf:SessionId" > type="netconf:SessionId" >
<xs:annotation> <xs:annotation>
<xs:documentation xml:lang="en"> <xs:documentation xml:lang="en">
The session id associated with this subscription. The session id associated with this
subscription.
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
</xs:element> </xs:element>
<xs:element name="subscriptionID" <xs:element name="streams"
type="ncEvent:SubscriptionID" > type="ncEvent:StreamsList" minOccurs="0">
<xs:annotation> <xs:annotation>
<xs:documentation xml:lang="en"> <xs:documentation xml:lang="en">
The subscription id associated with this A list of event streams associated with this
subscription. subscription.
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
</xs:element> </xs:element>
<xs:element name="filter" <xs:element name="filter"
type="netconf:filterInlineType" minOccurs="0"> type="netconf:filterInlineType" minOccurs="0">
<xs:annotation> <xs:annotation>
<xs:documentation xml:lang="en"> <xs:documentation xml:lang="en">
The filters associated with this subscription. The filters associated with this subscription.
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
</xs:element> </xs:element>
<xs:element ref="nsub:associatedNamedProfile" minOccurs="0"> <xs:element ref="nsub:associatedNamedProfile"
minOccurs="0">
<xs:annotation> <xs:annotation>
<xs:documentation xml:lang="en"> <xs:documentation xml:lang="en">
The named profile associated with this subscription. The named profile associated with this
Note that the contents of the named profile may subscription. Note that the contents of the
have changed since it was last applied. named profile may have changed since it was
last applied.
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
</xs:element> </xs:element>
<xs:element name="lastModified" <xs:element name="lastModified"
type="xs:dateTime" > type="xs:dateTime" >
<xs:annotation> <xs:annotation>
<xs:documentation xml:lang="en"> <xs:documentation xml:lang="en">
The last time this subscription was modified. If it The last time this subscription was modified. If
has not been modified since creation, this is the it has not been modified since creation, this is
time of subscription creation. the time of subscription creation.
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
</xs:element> </xs:element>
<xs:element name="messagesSent" <xs:element name="messagesSent"
type="xs:integer" minOccurs="0"> type="xs:unsignedInt" minOccurs="0">
<xs:annotation> <xs:annotation>
<xs:documentation xml:lang="en"> <xs:documentation xml:lang="en">
A count of event notifications sent along A count of event notifications sent along
this connection since the subscription was this connection since the subscription was
created. created.
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
</xs:element> </xs:element>
<xs:element name="key"> <xs:element name="key">
<xs:key name="uniqueSubscription"> <xs:key name="uniqueSubscription">
<xs:selector xpath=".//subscription"/> <xs:selector xpath=".//subscription"/>
<xs:field xpath="session-id"/> <xs:field xpath="session-id"/>
<xs:field xpath="subscriptionID"/>
</xs:key> </xs:key>
</xs:element> </xs:element>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name="netconfSubscriptions"> <xs:element name="netconfSubscriptions">
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element ref="nsub:netconfSubscription" <xs:element ref="nsub:netconfSubscription"
skipping to change at page 21, line 27 skipping to change at page 19, line 28
<xs:element name="namedProfile"> <xs:element name="namedProfile">
<xs:annotation> <xs:annotation>
<xs:appinfo> <xs:appinfo>
<nm:minAccess><read/></nm:minAccess> <nm:minAccess><read/></nm:minAccess>
<nm:maxAccess><read/> <write/> <create/> <delete/> <nm:maxAccess><read/> <write/> <create/> <delete/>
</nm:maxAccess> </nm:maxAccess>
</xs:appinfo> </xs:appinfo>
</xs:annotation> </xs:annotation>
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element name="name"/> <xs:element name="name"/>
<xs:element name="streams"
type="ncEvent:streamsList" minOccurs="0">
<xs:annotation>
<xs:documentation xml:lang="en">
The event streams associated with this named
profile.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="filter" <xs:element name="filter"
type="netconf:filterInlineType" minOccurs="0"> type="netconf:filterInlineType" minOccurs="0">
<xs:annotation> <xs:annotation>
<xs:documentation xml:lang="en"> <xs:documentation xml:lang="en">
The filters associated with this named The filters associated with this named
profile. profile.
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
</xs:element> </xs:element>
<xs:element name="lastModified" type="xs:dateTime"> <xs:element name="lastModified" type="xs:dateTime">
<xs:annotation> <xs:annotation>
<xs:documentation> <xs:documentation>
The timestamp of the last modification to this The timestamp of the last modification to this
named Profile. Note that modification of the named Profile. Note that modification of the
profile does not cause an immediate update profile does not cause an immediate update
to all applicable subscription. Therefore, this to all applicable subscription. Therefore,
time should be compared with the last this time should be compared with the last
modified time associated with the subscription. modified time associated with the
If this time is earlier, then the subscription subscription. If this time is earlier, then
is using the exact set of parameters associated the subscription is using the exact set of
with this named profile. If this time is parameters associated with this named profile.
later, then the subscription is using an earlier If this time is later, then the subscription
version of this named profile and the exact is using an earlier version of this named
parameters may not match. profile and the exact parameters may not
match.
</xs:documentation> </xs:documentation>
<xs:appinfo> <xs:appinfo>
<nm:minAccess><read/></nm:minAccess> <nm:minAccess><read/></nm:minAccess>
<nm:maxAccess><read/> </nm:maxAccess> <nm:maxAccess><read/> </nm:maxAccess>
</xs:appinfo> </xs:appinfo>
</xs:annotation> </xs:annotation>
</xs:element> </xs:element>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
skipping to change at page 22, line 27 skipping to change at page 20, line 41
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element ref="nsub:namedProfile" minOccurs="0" <xs:element ref="nsub:namedProfile" minOccurs="0"
maxOccurs="unbounded" /> maxOccurs="unbounded" />
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:schema> </xs:schema>
3.5 One-way Notification Messages 3.5. Filter Dependencies
In order to support the concept that each individual event
notification is a well-defined XML-document that can be processed
without waiting for all events to come in, it makes sense to define
events, not as an endless reply to a subscription command, but as
independent messages that originate from the NETCONF server. In
order to support this model, this memo introduces the concept of
notifications, which are one-way messages.
A one-way message is similar to the two-way RPC message, except that
no response is expected to the command. In the case of event
notification, this message will originate from the NETCONF server,
and not the NETCONF client.
3.6 Filter Dependencies
Note that when multiple filters are specified (in-line Filter, Named Note that when multiple filters are specified (in-line Filter, Named
Profiles), they are applied collectively, so event notifications need Profiles), they are applied collectively, so event notifications need
to pass all specified filters in order to be sent to the subscriber. to pass all specified filters in order to be sent to the subscriber.
If a filter is specified to look for data of a particular value, and If a filter is specified to look for data of a particular value, and
the data item is not present within a particular event notification the data item is not present within a particular event notification
for its value to be checked against, it will be filtered out. For for its value to be checked against, it will be filtered out. For
example, if one were to check for 'severity=critical' in a example, if one were to check for 'severity=critical' in a
configuration event notification where this field was not supported, configuration event notification where this field was not supported,
then the notification would be filtered out. then the 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.6.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.6.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.7 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 25, line 15 skipping to change at page 23, line 15
4. XML Schema for Event Notifications 4. XML Schema for 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 -->
-->
<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:annotation> <xs:annotation>
<xs:documentation> <xs:documentation>
This import accesses the xml: attribute groups for the This import accesses the xml: attribute groups for the
xml:lang as declared on the error-message element. xml:lang as declared on the error-message element.
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
</xs:import> </xs:import>
<!-- import base netconf definitions --> <!-- import base netconf definitions -->
<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="urn:ietf:params:xml:ns:netconf:base:1.0" /> schemaLocation="urn:ietf:params:xml:ns:netconf:base:1.0" />
<!-- ************** Type definitions ***********************--> <!-- ******************** Type definitions ***********************-->
<xs:simpleType name="SubscriptionID">
<xs:annotation>
<xs:documentation>
The unique identifier for this particular subscription within
the session.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string"/>
</xs:simpleType>
<xs:simpleType name="SequenceNumber"> <xs:complexType name="StreamsList">
<xs:annotation> <xs:annotation>
<xs:documentation> <xs:documentation>
A monotonically increasing integer. Starts at 0. A list of event streams.
Always increases by just one. Roll back to 0 after maximum
value is reached.
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
<xs:restriction base="xs:integer"/> <xs:sequence>
</xs:simpleType> <xs:element name="stream" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!-- ************** Symmetrical Operations ********************--> <!-- ************** Symmetrical Operations ********************-->
<!-- <!-- <create-subscription> operation -->
<create-subscription> operation
-->
<xs:complexType name="createSubscriptionType"> <xs:complexType name="createSubscriptionType">
<xs:complexContent> <xs:complexContent>
<xs:extension base="netconf:rpcOperationType"> <xs:extension base="netconf:rpcOperationType">
<xs:sequence> <xs:sequence>
</xs:element> <xs:element name="streams"
type="StreamsList" minOccurs="0"/>
<xs:element name="filter" <xs:element name="filter"
type="netconf:filterInlineType" minOccurs="0"/> type="netconf:filterInlineType" minOccurs="0"/>
<xs:element name="named-profile" <xs:element name="named-profile"
type="xs:string" minOccurs="0"/> type="xs:string" minOccurs="0"/>
<xs:element name="startTime" type="xs:dateTime" <xs:element name="startTime" type="xs:dateTime"
minOccurs="0" /> minOccurs="0" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
skipping to change at page 26, line 28 skipping to change at page 24, line 19
<xs:element name="filter" <xs:element name="filter"
type="netconf:filterInlineType" minOccurs="0"/> type="netconf:filterInlineType" minOccurs="0"/>
<xs:element name="named-profile" <xs:element name="named-profile"
type="xs:string" minOccurs="0"/> type="xs:string" minOccurs="0"/>
<xs:element name="startTime" type="xs:dateTime" <xs:element name="startTime" type="xs:dateTime"
minOccurs="0" /> minOccurs="0" />
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:element name="create-subscription" <xs:element name="create-subscription"
type="createSubscriptionType" type="createSubscriptionType"
substitutionGroup="netconf:rpcOperation"/> substitutionGroup="netconf:rpcOperation"/>
<!-- ************** One-way Operations ******************--> <!-- ************** One-way Operations ******************-->
<!-- <!-- <Event> operation -->
<Event> operation
-->
<xs:complexType name="NotificationType"> <xs:complexType name="NotificationType">
<xs:sequence> <xs:sequence>
<xs:element name="subscriptionId" type="SubscriptionID" /> <xs:element name="data" type="netconf:dataInlineType" />
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<xs:element name="notification" type="NotificationType"/> <xs:element name="notification" type="NotificationType"/>
</xs:schema> </xs:schema>
5. Mapping to Transport Protocols 5. Mapping to Transport Protocols
Currently, the NETCONF family of specification allows for running Currently, the NETCONF family of specification allows for running
NETCONF over a number of transport protocols, some of which support NETCONF over a number of transport protocols, some of which support
multiple configurations. Some of these options will be better suited multiple configurations. Some of these options will be better suited
for supporting event notifications then others. for supporting event notifications then others.
skipping to change at page 27, line 12 skipping to change at page 25, line 12
</xs:schema> </xs:schema>
5. Mapping to Transport Protocols 5. Mapping to Transport Protocols
Currently, the NETCONF family of specification allows for running Currently, the NETCONF family of specification allows for running
NETCONF over a number of transport protocols, some of which support NETCONF over a number of transport protocols, some of which support
multiple configurations. Some of these options will be better suited multiple configurations. Some of these options will be better suited
for supporting event notifications then others. for supporting event notifications then others.
5.1 SSH 5.1. SSH
Session establishment and two-way messages are based on the NETCONF Session establishment and two-way messages are based on the NETCONF
over SSH transport mapping [NETCONF-SSH] over SSH transport mapping [NETCONF SSH]
One-way event messages are supported as follows: Once the session has One-way event messages are supported as follows: Once the session has
been established and capabilities have been exchanged, the server may been established and capabilities have been exchanged, the server may
send complete XML documents to the NETCONF client containing send complete XML documents to the NETCONF client containing
notification elements. No response is expected from the NETCONF notification elements. No response is expected from the NETCONF
client. client.
As the examples in [NETCONF-SSH] illustrate, a special character As the examples in [NETCONF SSH] illustrate, a special character
sequence, MUST be sent by both the client and the server after each sequence, MUST be sent by both the client and the server after each
XML document in the NETCONF exchange. This character sequence cannot XML document in the NETCONF exchange. This character sequence cannot
legally appear in an XML document, so it can be unambiguously used to legally appear in an XML document, so it can be unambiguously used to
identify the end of the current document in the event notification of identify the end of the current document in the event notification of
an XML syntax or parsing error, allowing resynchronization of the an XML syntax or parsing error, allowing resynchronization of the
NETCONF exchange. NETCONF exchange.
The NETCONF over SSH session to receive an event notification might The NETCONF over SSH session to receive an event notification might
look like the following. Note the event notification contents look like the following. In the example below the event notification
(delimited by <data> </data> tags) are not defined in this document contents (delimited by <data> </data> tags) are not defined in this
and are provided herein simply for illustration purposes: document and are provided herein simply for illustration purposes.
The sample notification shows a configuration change on the running
configuration as a result of an <edit-config> operation. It has one
containment node ( <interfaces> ), with one element <interface> and
two changed attributes (<name> and <mtu>) (Note that this does not
refer to XML attributes). The same example is used in the BEEP and
SOAP transport mapping sections.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<notification <notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<subscription-id>123456</subscription-id> <data xmlns="http://example.com/event/1.0">
<data> <severity>notice</severity>
<eventClasses><configuration/><audit/></eventClasses> <eventClasses><configuration/><audit/></eventClasses>
<sequenceNumber>2</sequenceNumber> <sequenceNumber>2</sequenceNumber>
<dateAndTime>2000-01-12T12:13:14Z</dateAndTime> <dateAndTime>2000-01-12T12:13:14Z</dateAndTime>
<user>Fred Flinstone</user> <user>Fred Flinstone</user>
<operation> <operation>
<edit-config> <edit-config>
<target> <target>
<running/> <running/>
</target> </target>
<config> <edit-config>
<top xmlns="http://example.com/schema/1.2/config"> <top xmlns="http://example.com/schema/1.2/config">
<interfaces>
<interface> <interface>
<name>Ethernet0/0</name> <name>Ethernet0/0</name>
<mtu>1500</mtu> <mtu>1500</mtu>
</interface> </interface>
</interfaces>
</top> </top>
</config> </config>
</edit-config> </edit-config>
</operation> </operation>
</data> </data>
</event>
</data>
</notification> </notification>
]]> ]]>]]>
]]>
5.2 BEEP 5.2. BEEP
Session establishment and two-way messages are based on the NETCONF Session establishment and two-way messages are based on the NETCONF
over BEEP transport mapping NETCONF-BEEP over BEEP transport mapping [NETCONF BEEP]
5.2.1 One-way Notification Messages in Beep 5.2.1. One-way Notification Messages in Beep
One-way notification messages can be supported either by mapping to One-way notification messages can be supported either by mapping to
the existing one-to-many BEEP construct or by creating a new one-to- the existing one-to-many BEEP construct or by creating a new one-to-
none construct. none construct.
This area is for future study. This area is for future study.
5.2.1.1 One-way messages via the One-to-many Construct 5.2.1.1. One-way messages via the One-to-many Construct
Messages in one-to-many exchanges: "rpc", "notification", "rpc-reply" Messages in one-to-many exchanges: "rpc", "notification", "rpc-reply"
Messages in positive replies: "rpc-reply", "rpc-one-way" Messages in positive replies: "rpc-reply"
5.2.1.2 One-way notification messages via the One-to-none Construct 5.2.1.2. One-way notification messages via the One-to-none Construct
Note that this construct would need to be added to an extension or Note that this construct would need to be added to an extension or
update to 'The Blocks Extensible Exchange Protocol Core' RFC 3080. update to 'The Blocks Extensible Exchange Protocol Core' [RFC3080].
MSG/NoANS: the client sends a "MSG" message, the server, sends no MSG/NoANS: the client sends a "MSG" message, the server, sends no
reply. reply.
In one-to-none exchanges, no reply to the "MSG" message is expected. In one-to-none exchanges, no reply to the "MSG" message is expected.
5.3 SOAP 5.3. SOAP
Session management and message exchange are based on the NETCONF over Session management and message exchange are based on the NETCONF over
SOAP transport mapping NETCONF-SOAP SOAP transport mapping [NETCONF SOAP]
Note that the use of "persistent connections" "chunked transfer- Note that the use of "persistent connections" "chunked transfer-
coding" when using HTTP becomes even more important in the supporting coding" when using HTTP becomes even more important in the supporting
of event notifications of event notifications
5.3.1 A NETCONF over Soap over HTTP Example 5.3.1. A NETCONF over Soap over HTTP Example
C: POST /netconf HTTP/1.1 C: POST /netconf HTTP/1.1
C: Host: netconfdevice C: Host: netconfdevice
C: Content-Type: text/xml; charset=utf-8 C: Content-Type: text/xml; charset=utf-8
C: Accept: application/soap+xml, text/* C: Accept: application/soap+xml, text/*
C: Cache-Control: no-cache C: Cache-Control: no-cache
C: Pragma: no-cache C: Pragma: no-cache
C: Content-Length: 465 C: Content-Length: 465
C: C:
C: <?xml version="1.0" encoding="UTF-8"?> C: <?xml version="1.0" encoding="UTF-8"?>
skipping to change at page 29, line 46 skipping to change at page 28, line 4
C: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"> C: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
C: <soapenv:Body> C: <soapenv:Body>
C: <rpc message-id="101" C: <rpc message-id="101"
C: xmlns= C: xmlns=
"xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> "xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
C: <create-subscription> C: <create-subscription>
C: </create-subscription> C: </create-subscription>
C: </rpc> C: </rpc>
C: </soapenv:Body> C: </soapenv:Body>
C: </soapenv:Envelope> C: </soapenv:Envelope>
The response: The response:
S: HTTP/1.1 200 OK S: HTTP/1.1 200 OK
S: Content-Type: application/soap+xml; charset=utf-8 S: Content-Type: application/soap+xml; charset=utf-8
S: Content-Length: 917 S: Content-Length: 917
S: S:
S: <?xml version="1.0" encoding="UTF-8"?> S: <?xml version="1.0" encoding="UTF-8"?>
S: <soapenv:Envelope S: <soapenv:Envelope
S: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"> S: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
S: <soapenv:Body> S: <soapenv:Body>
S: <rpc-reply message-id="101" S: <rpc-reply message-id="101"
S: xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> S: xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
S: <data> S: <data>
S: <top xmlns= S: <top xmlns=
"http://example.com/schema/1.2/notification"> "http://example.com/schema/1.2/notification">
S: <subscriptionId>123456</subscriptionId>
S: </top> S: </top>
S: </data> S: </data>
S: </rpc-reply> S: </rpc-reply>
S: </soapenv:Body> S: </soapenv:Body>
S: </soapenv:Envelope> S: </soapenv:Envelope>
And then some time later And then some time later
S: HTTP/1.1 200 OK S: HTTP/1.1 200 OK
S: Content-Type: application/soap+xml; charset=utf-8 S: Content-Type: application/soap+xml; charset=utf-8
S: Content-Length: 917 S: Content-Length: 917
S: S:
S: <?xml version="1.0" encoding="UTF-8"?> S: <?xml version="1.0" encoding="UTF-8"?>
S: <soapenv:Envelope S: <soapenv:Envelope
S: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"> S: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
S: <soapenv:Body> S: <soapenv:Body>
S: <notification S: <notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
S: <subscriptionID>123456</subscriptionID>
S: <data> S: <data>
S: <eventClasses><configuration/><audit/></eventClasses> S: <eventClasses><configuration/><audit/></eventClasses>
S: <sequenceNumber>2</sequenceNumber> S: <sequenceNumber>2</sequenceNumber>
S: <dateAndTime>2000-01-12T12:13:14Z</dateAndTime> S: <dateAndTime>2000-01-12T12:13:14Z</dateAndTime>
S: <user>Fred Flinstone</user> S: <user>Fred Flinstone</user>
S: <operation> S: <operation>
S: <edit-config> S: <edit-config>
S: <target> S: <target>
S: <running/> S: <running/>
S: </target> S: </target>
S: <config> S: <config>
S: <top xmlns="http://example.com/schema/1.2/config"> S: <top xmlns="http://example.com/schema/1.2/config">
S: <interface> S: <interfaces>
<interface>
S: <name>Ethernet0/0</name> S: <name>Ethernet0/0</name>
S: <mtu>1500</mtu> S: <mtu>1500</mtu>
S: </interface> </interface>
S: </interfaces>
S: </top> S: </top>
S: </config> S: </config>
S: </edit-config> S: </edit-config>
S: </operation> S: </operation>
S: </data> S: </data>
S: </notification> S: </notification>
S: </soapenv:Body> S: </soapenv:Body>
S: </soapenv:Envelope> S: </soapenv:Envelope>
6. Filtering examples 6. Filtering examples
The following section provides examples to illustrate the various The following section provides examples to illustrate the various
methods of filtering content on an event notification subscription. methods of filtering content on an event notification subscription.
6.1 Subtree Filtering 6.1. Subtree Filtering
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 (only for example to assume some of the event notification content (only for example
purposes). The examples herein assume that the event notification purposes). The examples herein assume that the event notification
schema definition has an <eventClasses> element identifying the schema definition has an <eventClasses> element identifying the event
event category (e.g. fault, state, config, etc.) and events have a category (e.g. fault, state, config, etc.) and events have a
<severity> element <severity> element
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
<netconf:filter type="subtree">
<neb
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<event> <filter type="subtree">
<event xmlns="http://example.com/event/1.0">
<severity>critical</severity> <severity>critical</severity>
</event> </event>
<event> <event xmlns="http://example.com/event/1.0">
<severity>major</severity> <severity>major</severity>
</event> </event>
<event> <event xmlns="http://example.com/event/1.0">
<severity>minor</severity> <severity>minor</severity>
</event> </event>
</neb>
</netconf:filter> </netconf:filter>
</create-subscription> </create-subscription>
</rpc> </rpc>
The following example illustrates selecting fault, state, config The following example illustrates selecting fault, state, config
EventClasses or events which are related to card Ethernet0. The EventClasses or events which are related to card Ethernet0. The
filtering criteria evaluation is as follows: filtering criteria evaluation is as follows:
(fault | state | config | card=Ethernet0) (fault | state | config | card=Ethernet0)
<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>
<netconf:filter type="subtree"> <netconf:filter type="subtree">
<neb <top
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<event> <event>
<eventClasses>fault</eventClasses> <eventClasses>fault</eventClasses>
</event> </event>
<event> <event>
<eventClasses>state</eventClasses> <eventClasses>state</eventClasses>
</event> </event>
<event> <event>
<eventClasses>config</eventClasses> <eventClasses>config</eventClasses>
</event> </event>
<event> <event>
<card>Ethernet0</card> <card>Ethernet0</card>
</event> </event>
</neb> </top>
</netconf:filter> </netconf:filter>
</create-subscription> </create-subscription>
</rpc> </rpc>
6.2 XPATH filters 6.2. XPATH filters
The following example illustrates selecting fault EventClass The following example illustrates selecting fault EventClass
notifications that have severities of critical, major, or minor. The notifications that have severities of critical, major, or minor. The
filtering criteria evaluation is as follows: 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="urn:ietf:params:xml:ns:netconf:notification:1.0">
<create-subscription> <create-subscription>
skipping to change at page 35, line 7 skipping to change at page 33, line 7
/event[severity="major"]) or /event[severity="major"]) or
(/event[eventClasses/fault] and (/event[eventClasses/fault] and
/event[severity="minor"]) or /event[severity="minor"]) or
/event[card="Ethernet0"])) /event[card="Ethernet0"]))
</netconf:filter> </netconf:filter>
</create-subscription> </create-subscription>
</rpc> </rpc>
7. Notification Replay Capability 7. Notification Replay Capability
7.1 Overview 7.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.
A replay of notifications is specified by including an optional A replay of notifications is specified by including an optional
parameter to the subscription command that indicates the start time parameter to the subscription command that indicates the start time
of the replay. The end time of the replay is implicitly defined to of the replay. The end time of the replay is implicitly defined to
be the time the replay request was initiated. be the time the replay request was initiated.
An implementation that supports replay is not expected to have an An implementation that supports replay is not expected to have an
unlimited supply of saved notifications available to accommodate any unlimited supply of saved notifications available to accommodate any
replay request. If a client requests a replay of notifications that replay request. If a client requests a replay of notifications that
predate the oldest notification available, then the NETCONF server predate the oldest notification available, then the NETCONF server
must return an warning message in the RPC reply and start replaying must return a warning message in the RPC reply and start replaying
the notifications it does have available, within the other the notifications it does have available, within the other
constraints, such as filtering, that the client has provided. constraints, such as filtering, that the client has provided. The
warning message enables the NETCONF client to differentiate between
the case that there were no notifications generated within a given
time period from the case that no notifications are currently in the
log from that period.
The actual number of stored notifications available for retrieval at The actual number of stored notifications available for retrieval at
any given time is an agent implementation specific matter. Control any given time is an NETCONF server implementation specific matter.
parameters for this aspect of the feature are outside the scope of Control parameters for this aspect of the feature are outside the
the current work. scope of the current work.
A given subscription is either a replay subscription or a normal A given subscription is either a replay subscription or a normal
subscription, which sends event notifications as they happen. A subscription, which sends event notifications as they happen. A
replay subscription terminates once the it has completed replaying replay subscription terminates once the it has completed replaying
past events. past events.
7.2 Dependencies 7.2. Dependencies
This capability is dependent on the notification capability being This capability is dependent on the notification capability being
supported. It also requires that the device support some form of supported. It also requires that the device supporting the Netconf
notification logging, although it puts no restrictions on the size or server also support some form of notification logging, although it
form of the log. puts no restrictions on the size or form of the log, nor where it
resides within the device.
7.3 Capability Identifier 7.3. Capability Identifier
The Event Notification Replay capability is identified by following The Event Notification Replay capability is identified by following
capability string: capability string:
http://ietf.org/netconf/notificationReplay/1.0 http://ietf.org/netconf/notificationReplay/1.0
7.4 New Operations 7.4. New Operations
None None
7.5 Modifications to Existing Operations 7.5. Modifications to Existing Operations
7.5.1 create-subscription 7.5.1. create-subscription
This capability adds an optional parameter to the <create- This capability adds an optional parameter to the <create-
subscription> command called 'startTime'. This identifies the subscription> command called 'startTime'. This identifies the
earliest date and time of interest for event notifications being earliest date and time of interest for event notifications being
replayed. Events generated before this time are not matched. replayed. Events generated before this time are not matched.
7.5.2 Interactions with Other Capabilities 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 was sent out by the NETCONF server - the startTime parameter is
related to generation time.
Negative Response:
An <rpc-error> element is included in the <rpc-reply> if the
startTime in replay request predates the oldest notification
available to be replayed.
Error-tag: start-time-value
Error-type: protocol
Error-severity: warning
Error-info: none
Error-message: Start time predates oldest available
notification to be replayed
7.5.2. Interactions with Other Capabilities
[Edtitor's Note: If this capability does not interact with other [Edtitor's Note: If this capability does not interact with other
capabilities, this section may be omitted.] capabilities, this section may be omitted.]
7.6. Replay Complete Notification
The following notification is the last notification sent over a
replay subscription. It indicates that replay is complete.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:netconf:replayNotification:1.0"
targetNamespace=
"urn:ietf:params:xml:ns:netconf:replayNotification:1.0">
<xs:element name="replayCompleteNotification" >
<xs:annotation>
<xs:documentation>
This notification is sent to signal the end of a replay
subscription.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="eventClass" default="informational">
<xs:annotation>
<xs:documentation>
The event classification of this notification.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="timeGenerated" type="xs:dateTime"/>
<xs:element name="numberEventsReplayed" type="xs:integer"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
8. Security Considerations 8. Security Considerations
To be determined once specific aspects of this solution are better The access control framework and the choice of transport will have a
understood. In particular, the access control framework and the major impact on the security of the solution.
choice of transport will have a major impact on the security of the
solution Note that the <notification> elements are never sent before the
transport layer and the netconf layer (capabilities exchange) have
been established, and the manager has been identified and
authenticated.
It is recommended that care be taken to ensure the secure operation
of the following commands:
o <create-subscription> invocation
o use of <kill-session>
o read-only data models
o read-write data models
o notification content
One issue related to the notifications draft is the transport of data
from non-netconf streams, such as syslog and SNMP. Note that this
data may be more vulnerable (or is not more vulnerable) when being
transported over netconf than when being transported using the
protocol normally used for transporting it, depending on the security
credentials of the two subsystems.
9. Acknowledgements 9. Acknowledgements
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 Simon Leinen, Juergen Schoenwaelder, Hideki Okita, Vincent Cridlig,
Cridlig, Martin Bjorklund, Olivier Festor, Radu State, Brian Martin Bjorklund, Olivier Festor, Radu State, Brian Trammell, William
Trammell, William Chow Chow
10. References 10. 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.
[NETCONF BEEP] [NETCONF BEEP]
Lear, E. and K. Crozier, "Using the NETCONF Protocol over Lear, E. and K. Crozier, "Using the NETCONF Protocol over
Blocks Extensible Exchange Protocol (BEEP)", Blocks Extensible Exchange Protocol (BEEP)",
ID draft-ietf-netconf-beep-10, March 2006. ID draft-ietf-netconf-beep-10, March 2006.
[NETCONF Datamodel] [NETCONF Datamodel]
skipping to change at page 38, line 44 skipping to change at page 38, line 30
[NETCONF SOAP] [NETCONF SOAP]
Goddard, T., "Using the Network Configuration Protocol Goddard, T., "Using the Network Configuration Protocol
(NETCONF) Over the Simple Object Access Protocol (SOAP)", (NETCONF) Over the Simple Object Access Protocol (SOAP)",
ID draft-ietf-netconf-soap-08, March 2006. ID draft-ietf-netconf-soap-08, March 2006.
[NETCONF SSH] [NETCONF SSH]
Wasserman, M. and T. Goddard, "Using the NETCONF Wasserman, M. and T. Goddard, "Using the NETCONF
Configuration Protocol over Secure Shell (SSH)", Configuration Protocol over Secure Shell (SSH)",
ID draft-ietf-netconf-ssh-06.txt, March 2006. ID draft-ietf-netconf-ssh-06.txt, March 2006.
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[XML] World Wide Web Consortium, "Extensible Markup Language
(XML) 1.0", W3C XML, February 1998,
<http://www.w3.org/TR/1998/REC-xml-19980210>.
[refs.RFC2026]
Bradner, S., "The Internet Standards Process -- Revision
3", RFC 2026, BCP 9, October 1996. 3", RFC 2026, BCP 9, October 1996.
[refs.RFC2119] [RFC2119] Bradner, s., "Key words for RFCs to Indicate Requirements
Bradner, s., "Key words for RFCs to Indicate Requirements
Levels", RFC 2119, March 1997. Levels", RFC 2119, March 1997.
[refs.RFC2223] [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors",
Postel, J. and J. Reynolds, "Instructions to RFC Authors",
RFC 2223, October 1997. RFC 2223, October 1997.
[refs.RFC3080] [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
Rose, M., "The Blocks Extensible Exchange Protocol Core",
RFC 3080, March 2001. RFC 3080, March 2001.
[XML] World Wide Web Consortium, "Extensible Markup Language
(XML) 1.0", W3C XML, February 1998,
<http://www.w3.org/TR/1998/REC-xml-19980210>.
[XML Schema]
Fallside, D. and P. Walmsley, "XML Schema Part 0: Primer
Second Edition", W3C XML Schema, October 2004.
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
Hector Trevino Hector Trevino
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
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 40, line 29 skipping to change at page 40, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 156 change blocks. 
408 lines changed or deleted 402 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/