summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5277.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5277.txt')
-rw-r--r--doc/rfc/rfc5277.txt1963
1 files changed, 1963 insertions, 0 deletions
diff --git a/doc/rfc/rfc5277.txt b/doc/rfc/rfc5277.txt
new file mode 100644
index 0000000..ccbf69f
--- /dev/null
+++ b/doc/rfc/rfc5277.txt
@@ -0,0 +1,1963 @@
+
+
+
+
+
+
+Network Working Group S. Chisholm
+Request for Comments: 5277 Nortel
+Category: Standards Track H. Trevino
+ Cisco
+ July 2008
+
+
+ NETCONF Event Notifications
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ This document defines mechanisms that provide an asynchronous message
+ notification delivery service for the Network Configuration protocol
+ (NETCONF). This is an optional capability built on top of the base
+ NETCONF definition. This document defines the capabilities and
+ operations necessary to support this service.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chisholm & Trevino Standards Track [Page 1]
+
+RFC 5277 NETCONF Event Notifications July 2008
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 3
+ 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.3. Event Notifications in NETCONF . . . . . . . . . . . . . . 5
+ 2. Notification-Related Operations . . . . . . . . . . . . . . . 5
+ 2.1. Subscribing to Receive Event Notifications . . . . . . . . 5
+ 2.1.1. <create-subscription> . . . . . . . . . . . . . . . . 6
+ 2.2. Sending Event Notifications . . . . . . . . . . . . . . . 9
+ 2.2.1. <notification> . . . . . . . . . . . . . . . . . . . . 9
+ 2.3. Terminating the Subscription . . . . . . . . . . . . . . . 9
+ 3. Supporting Concepts . . . . . . . . . . . . . . . . . . . . . 10
+ 3.1. Capabilities Exchange . . . . . . . . . . . . . . . . . . 10
+ 3.1.1. Capability Identifier . . . . . . . . . . . . . . . . 10
+ 3.1.2. Capability Example . . . . . . . . . . . . . . . . . . 10
+ 3.2. Event Streams . . . . . . . . . . . . . . . . . . . . . . 10
+ 3.2.1. Event Stream Definition . . . . . . . . . . . . . . . 12
+ 3.2.2. Event Stream Content Format . . . . . . . . . . . . . 12
+ 3.2.3. Default Event Stream . . . . . . . . . . . . . . . . . 12
+ 3.2.4. Event Stream Sources . . . . . . . . . . . . . . . . . 12
+ 3.2.5. Event Stream Discovery . . . . . . . . . . . . . . . . 12
+ 3.3. Notification Replay . . . . . . . . . . . . . . . . . . . 15
+ 3.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 15
+ 3.3.2. Creating a Subscription with Replay . . . . . . . . . 16
+ 3.4. Notification Management Schema . . . . . . . . . . . . . . 16
+ 3.5. Subscriptions Data . . . . . . . . . . . . . . . . . . . . 20
+ 3.6. Filter Mechanics . . . . . . . . . . . . . . . . . . . . . 20
+ 3.6.1. Filtering . . . . . . . . . . . . . . . . . . . . . . 20
+ 3.7. Message Flow . . . . . . . . . . . . . . . . . . . . . . . 20
+ 4. XML Schema for Event Notifications . . . . . . . . . . . . . . 22
+ 5. Filtering Examples . . . . . . . . . . . . . . . . . . . . . . 26
+ 5.1. Subtree Filtering . . . . . . . . . . . . . . . . . . . . 28
+ 5.2. XPATH Filters . . . . . . . . . . . . . . . . . . . . . . 29
+ 6. Interleave Capability . . . . . . . . . . . . . . . . . . . . 30
+ 6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 30
+ 6.2. Dependencies . . . . . . . . . . . . . . . . . . . . . . . 30
+ 6.3. Capability Identifier . . . . . . . . . . . . . . . . . . 30
+ 6.4. New Operations . . . . . . . . . . . . . . . . . . . . . . 31
+ 6.5. Modifications to Existing Operations . . . . . . . . . . . 31
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31
+ 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
+ 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
+ 10. Normative References . . . . . . . . . . . . . . . . . . . . . 33
+
+
+
+
+
+
+
+Chisholm & Trevino Standards Track [Page 2]
+
+RFC 5277 NETCONF Event Notifications July 2008
+
+
+1. Introduction
+
+ [NETCONF] can be conceptually partitioned into four layers:
+
+ Layer Example
+ +-------------+ +-------------------------------------------+
+ | Content | | Configuration data |
+ +-------------+ +-------------------------------------------+
+ | |
+ +-------------+ +-------------------------------------------+
+ | Operations | |<get-config>, <edit-config>, <notification>|
+ +-------------+ +-------------------------------------------+
+ | | |
+ +-------------+ +-----------------------------+ |
+ | RPC | | <rpc>, <rpc-reply> | |
+ +-------------+ +-----------------------------+ |
+ | | |
+ +-------------+ +-------------------------------------------+
+ | Transport | | BEEP, SSH, SSL, console |
+ | Protocol | | |
+ +-------------+ +-------------------------------------------+
+
+ Figure 1
+
+ This document defines mechanisms that provide an asynchronous message
+ notification delivery service for the [NETCONF] protocol. This is an
+ optional capability built on top of the base NETCONF definition.
+ This memo defines the capabilities and operations necessary to
+ support this service.
+
+1.1. Definition of Terms
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+ Element: An [XML] Element.
+
+ Subscription: An agreement and method to receive event notifications
+ over a NETCONF session. A concept related to the delivery of
+ notifications (if there are any to send) involving destination and
+ selection of notifications. It is bound to the lifetime of a
+ session.
+
+
+
+
+
+
+
+
+Chisholm & Trevino Standards Track [Page 3]
+
+RFC 5277 NETCONF Event Notifications July 2008
+
+
+ Operation: This term is used to refer to NETCONF protocol operations
+ [NETCONF]. Within this document, operation refers to NETCONF
+ protocol operations defined in support of NETCONF notifications.
+
+ Event: An event is something that happens that may be of interest -
+ a configuration change, a fault, a change in status, crossing a
+ threshold, or an external input to the system, for example.
+ Often, this results in an asynchronous message, sometimes referred
+ to as a notification or event notification, being sent to
+ interested parties to notify them that this event has occurred.
+
+ Replay: The ability to send/re-send previously logged notifications
+ upon request. These notifications are sent asynchronously. This
+ feature is implemented by the NETCONF server and invoked by the
+ NETCONF client.
+
+ Stream: An event stream is a set of event notifications matching
+ some forwarding criteria and available to NETCONF clients for
+ subscription.
+
+ Filter: A parameter that indicates which subset of all possible
+ events are of interest. A filter is defined as one or more filter
+ elements [NETCONF], each of which identifies a portion of the
+ overall filter.
+
+1.2. Motivation
+
+ The motivation for this work is to enable the sending of asynchronous
+ messages that are consistent with the data model (content) and
+ security model used within a NETCONF implementation.
+
+ The scope of the work aims at meeting the following operational
+ needs:
+
+ o Initial release should ensure it supports notifications in support
+ of configuration operations.
+
+ o It should be possible to use the same data model for notifications
+ as for configuration operations.
+
+ o The solution should support a reasonable message size limit (i.e.,
+ not too short).
+
+ o The notifications should be carried over a connection-oriented
+ delivery mechanism.
+
+
+
+
+
+
+Chisholm & Trevino Standards Track [Page 4]
+
+RFC 5277 NETCONF Event Notifications July 2008
+
+
+ o A subscription mechanism for notifications should be provided.
+ This takes into account that a NETCONF server does not send
+ notifications before being asked to do so, and that it is the
+ NETCONF client who initiates the flow of notifications.
+
+ o A filtering mechanism for sending notifications should be put in
+ place within the NETCONF server.
+
+ o The information contained in a notification should be sufficient
+ so that it can be analyzed independent of the transport mechanism.
+ In other words, the data content fully describes a notification;
+ protocol information is not needed to understand a notification.
+
+ o The server should have the capability to replay locally logged
+ notifications.
+
+1.3. Event Notifications in NETCONF
+
+ This memo defines a mechanism whereby the NETCONF client indicates
+ interest in receiving event notifications from a NETCONF server by
+ creating a subscription to receive event notifications. The NETCONF
+ server replies to indicate whether the subscription request was
+ successful and, if it was successful, begins sending the event
+ notifications to the NETCONF client as the events occur within the
+ system. These event notifications will continue to be sent until
+ either the NETCONF session is terminated or the subscription
+ terminates for some other reason. The event notification
+ subscription allows a number of options to enable the NETCONF client
+ to specify which events are of interest. These are specified when
+ the subscription is created. Note that a subscription cannot be
+ modified once created.
+
+ The NETCONF server MUST accept and process the <close-session>
+ operation, even while the notification subscription is active. The
+ NETCONF server MAY accept and process other commands; otherwise, they
+ will be rejected and the server MUST send a 'resource-denied' error.
+ A NETCONF server advertises support of the ability to process other
+ commands via the :interleave capability.
+
+2. Notification-Related Operations
+
+2.1. Subscribing to Receive Event Notifications
+
+ The event notification subscription is initiated by the NETCONF
+ client and responded to by the NETCONF server. A subscription is
+ bound to a single stream for the lifetime of the subscription. When
+ the event notification subscription is created, the events of
+ interest are specified.
+
+
+
+Chisholm & Trevino Standards Track [Page 5]
+
+RFC 5277 NETCONF Event Notifications July 2008
+
+
+ Content for an event notification subscription can be selected by
+ applying user-specified filters.
+
+2.1.1. <create-subscription>
+
+ Description:
+
+ This operation initiates an event notification subscription that
+ will send asynchronous event notifications to the initiator of the
+ command until the subscription terminates.
+
+ Parameters:
+
+ Stream:
+
+ An optional parameter, <stream>, that indicates which stream of
+ events is of interest. If not present, events in the default
+ NETCONF stream will be sent.
+
+ Filter:
+
+ An optional parameter, <filter>, that indicates which subset of
+ all possible events is of interest. The format of this
+ parameter is the same as that of the filter parameter in the
+ NETCONF protocol operations. If not present, all events not
+ precluded by other parameters will be sent. See section 3.6
+ for more information on filters.
+
+ Start Time:
+
+ A parameter, <startTime>, used to trigger the replay feature
+ and indicate that the replay should start at the time
+ specified. If <startTime> is not present, this is not a replay
+ subscription. It is not valid to specify start times that are
+ later than the current time. If the <startTime> specified is
+ earlier than the log can support, the replay will begin with
+ the earliest available notification. This parameter is of type
+ dateTime and compliant to [RFC3339]. Implementations must
+ support time zones.
+
+
+
+
+
+
+
+
+
+
+
+
+Chisholm & Trevino Standards Track [Page 6]
+
+RFC 5277 NETCONF Event Notifications July 2008
+
+
+ Stop Time:
+
+ An optional parameter, <stopTime>, used with the optional
+ replay feature to indicate the newest notifications of
+ interest. If <stopTime> is not present, the notifications will
+ continue until the subscription is terminated. Must be used
+ with and be later than <startTime>. Values of <stopTime> in
+ the future are valid. This parameter is of type dateTime and
+ compliant to [RFC3339]. Implementations must support time
+ zones.
+
+ Positive Response:
+
+ If the NETCONF server can satisfy the request, the server sends an
+ <ok> element.
+
+ Negative Response:
+
+ An <rpc-error> element is included within the <rpc-reply> if the
+ request cannot be completed for any reason. Subscription requests
+ will fail if a filter with invalid syntax is provided or if the
+ name of a non-existent stream is provided.
+
+ If a <stopTime> is specified in a request without having specified
+ a <startTime>, the following error is returned:
+
+ Tag: missing-element
+
+ Error-type: protocol
+
+ Severity: error
+
+ Error-info: <bad-element>: startTime
+
+ Description: An expected element is missing.
+
+ If the optional replay feature is requested but it is not
+ supported by the NETCONF server, the following error is returned:
+
+ Tag: operation-failed
+
+ Error-type: protocol
+
+ Severity: error
+
+ Error-info: none
+
+
+
+
+
+Chisholm & Trevino Standards Track [Page 7]
+
+RFC 5277 NETCONF Event Notifications July 2008
+
+
+ Description: Request could not be completed because the
+ requested operation failed for some reason not covered by any
+ other error condition.
+
+ If a <stopTime> is requested that is earlier than the specified
+ <startTime>, the following error is returned:
+
+ Tag: bad-element
+
+ Error-type: protocol
+
+ Severity: error
+
+ Error-info: <bad-element>: stopTime
+
+ Description: An element value is not correct; e.g., wrong type,
+ out of range, pattern mismatch.
+
+ If a <startTime> is requested that is later than the current time,
+ the following error is returned:
+
+ Tag: bad-element
+
+ Error-type: protocol
+
+ Severity: error
+
+ Error-info: <bad-element>: startTime
+
+ Description: An element value is not correct; e.g., wrong type,
+ out of range, pattern mismatch.
+
+2.1.1.1. Usage Example
+
+ The following demonstrates creating a simple subscription. More
+ complex examples can be found in section 5.
+
+ <netconf:rpc message-id="101"
+ xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
+ <create-subscription
+ xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
+ </create-subscription>
+ </netconf:rpc>
+
+
+
+
+
+
+
+
+Chisholm & Trevino Standards Track [Page 8]
+
+RFC 5277 NETCONF Event Notifications July 2008
+
+
+2.2. Sending Event Notifications
+
+ Once the subscription has been set up, the NETCONF server sends the
+ event notifications asynchronously over the connection.
+
+2.2.1. <notification>
+
+ Description:
+
+ An event notification is sent to the client who initiated a
+ <create-subscription> command asynchronously when an event of
+ interest (i.e., meeting the specified filtering criteria) has
+ occurred. An event notification is a complete and well-formed XML
+ document. Note that <notification> is not a Remote Procedure Call
+ (RPC) method but rather the top-level element identifying the one-
+ way message as a notification.
+
+ Parameters:
+
+ eventTime
+
+ The time the event was generated by the event source. This
+ parameter is of type dateTime and compliant to [RFC3339].
+ Implementations must support time zones.
+
+ Also contains notification-specific tagged content, if any. With
+ the exception of <eventTime>, the content of the notification is
+ beyond the scope of this document.
+
+ Response:
+
+ No response. Not applicable.
+
+2.3. Terminating the Subscription
+
+ Closing of the event notification subscription can be done by using
+ the <close-session> operation from the subscriptions session or
+ terminating the NETCONF session ( <kill-session> ) or the underlying
+ transport session from another session. If a stop time is provided
+ when the subscription is created, the subscription will terminate
+ after the stop time is reached. In this case, the NETCONF session
+ will still be an active session.
+
+
+
+
+
+
+
+
+
+Chisholm & Trevino Standards Track [Page 9]
+
+RFC 5277 NETCONF Event Notifications July 2008
+
+
+3. Supporting Concepts
+
+3.1. Capabilities Exchange
+
+ The ability to process and send event notifications is advertised
+ during the capability exchange between the NETCONF client and server.
+
+3.1.1. Capability Identifier
+
+ "urn:ietf:params:netconf:capability:notification:1.0"
+
+3.1.2. Capability Example
+
+ <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
+ <capabilities>
+ <capability>
+ urn:ietf:params:xml:ns:netconf:base:1.0
+ </capability>
+ <capability>
+ urn:ietf:params:netconf:capability:startup:1.0
+ </capability>
+ <capability>
+ urn:ietf:params:netconf:capability:notification:1.0
+ </capability>
+ </capabilities>
+ <session-id>4</session-id>
+ </hello>
+
+3.2. Event Streams
+
+ An event stream is defined as a set of event notifications matching
+ some forwarding criteria.
+
+ Figure 2 illustrates the notification flow and concepts identified in
+ this document. It does not mandate and/or preclude an
+ implementation. The following is observed from the diagram below:
+ System components (c1..cn) generate event notifications that are
+ passed to a central component for classification and distribution.
+ The central component inspects each event notification and matches
+ the event notification against the set of stream definitions. When a
+ match occurs, the event notification is considered to be a member of
+ that event stream (stream 1..stream n). An event notification may be
+ part of multiple event streams.
+
+
+
+
+
+
+
+
+Chisholm & Trevino Standards Track [Page 10]
+
+RFC 5277 NETCONF Event Notifications July 2008
+
+
+ At some point after the NETCONF server receives the internal event
+ from a stream, it is converted to an appropriate XML encoding by the
+ server, and a <notification> element is ready to send to all NETCONF
+ sessions subscribed to that stream.
+
+ After generation of the <notification> element, access control is
+ applied by the server. If a session does not have permission to
+ receive the <notification>, then it is discarded for that session,
+ and processing of the internal event is completed for that session.
+
+ When a NETCONF client subscribes to a given event stream, user-
+ defined filter elements, if applicable, are applied to the event
+ stream and matching event notifications are forwarded to the NETCONF
+ server for distribution to subscribed NETCONF clients. A filter is
+ transferred from the client to the server during the <create-
+ subscription> operation and applied against each <notification>
+ element generated by the stream. For more information on filtering,
+ see Section 3.6.
+
+ A notification-logging service may also be available, in which case,
+ the central component logs notifications. The NETCONF server may
+ later retrieve logged notifications via the optional replay feature.
+ For more information on replay, see section 3.3.
+
+ +----+
+ | c1 |----+ available streams
+ +----+ | +---------+
+ +----+ | |central |-> stream 1
+ | c2 | +--->|event |-> stream 2 filter +-------+
+ +----+ | |processor|-> NETCONF stream ----->|NETCONF|
+ ... | | |-> stream n |server |
+ System | +---------+ +-------+
+ Components| | /\
+ ... | | ||
+ +----+ | | (------------) ||
+ | cn |----+ | (notification) ||
+ +----+ +-----> ( logging ) ||
+ ( service ) ||
+ (------------) ||
+ ||
+ ||
+ \/
+ +-------+
+ |NETCONF|
+ |client |
+ +-------+
+
+ Figure 2
+
+
+
+Chisholm & Trevino Standards Track [Page 11]
+
+RFC 5277 NETCONF Event Notifications July 2008
+
+
+3.2.1. Event Stream Definition
+
+ Event streams are predefined on the managed device. The
+ configuration of event streams is outside the scope of this document.
+ However, it is envisioned that event streams are either pre-
+ established by the vendor (pre-configured), user configurable (e.g.,
+ part of the device's configuration), or both. Device vendors may
+ allow event stream configuration via the NETCONF protocol (i.e.,
+ <edit-config> operation).
+
+3.2.2. Event Stream Content Format
+
+ 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 XML.
+
+3.2.3. Default Event Stream
+
+ A NETCONF server implementation supporting the notification
+ capability MUST support the "NETCONF" notification event stream.
+ This stream contains all NETCONF XML event notifications supported by
+ the NETCONF server. The exact string "NETCONF" is used during the
+ advertisement of stream support during the <get> operation on
+ <streams> and during the <create-subscription> operation. Definition
+ of the event notifications and their contents, beyond the inclusion
+ of <eventTime>, for this event stream is outside the scope of this
+ document.
+
+3.2.4. Event Stream Sources
+
+ With the exception of the default event stream (NETCONF),
+ specification of additional event stream sources (e.g., Simple
+ Network Management Protocol (SNMP), syslog) is outside the scope of
+ this document. NETCONF server implementations may leverage any
+ desired event stream source in the creation of supported event
+ streams.
+
+3.2.5. Event Stream Discovery
+
+ A NETCONF client retrieves the list of supported event streams from a
+ NETCONF server using the <get> operation.
+
+3.2.5.1. Name Retrieval Using <get> Operation
+
+ The list of available event streams is retrieved by requesting the
+ <streams> subtree via a <get> operation. Available event streams for
+ the requesting session are returned in the reply containing the
+ <name> and <description> elements, where the <name> element is
+
+
+
+Chisholm & Trevino Standards Track [Page 12]
+
+RFC 5277 NETCONF Event Notifications July 2008
+
+
+ mandatory, and its value is unique within the scope of a NETCONF
+ server. An empty reply is returned if there are no available event
+ streams, due to user-specified filters on the <get> operation.
+
+ Additional information available about a stream includes whether
+ notification replay is available and, if so, the timestamp of the
+ earliest possible notification to replay.
+
+ The following example shows retrieving the list of available event
+ stream list using the <get> operation.
+
+ <rpc message-id="101"
+ xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
+ <get>
+ <filter type="subtree">
+ <netconf xmlns="urn:ietf:params:xml:ns:netmod:notification">
+ <streams/>
+ </netconf>
+ </filter>
+ </get>
+ </rpc>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chisholm & Trevino Standards Track [Page 13]
+
+RFC 5277 NETCONF Event Notifications July 2008
+
+
+ The NETCONF server returns a list of event streams available for
+ subscription: NETCONF, SNMP, and syslog-critical in this example.
+
+ <rpc-reply message-id="101"
+ xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
+ <data>
+ <netconf xmlns="urn:ietf:params:xml:ns:netmod:notification">
+ <streams>
+ <stream>
+ <name>NETCONF</name>
+ <description>default NETCONF event stream
+ </description>
+ <replaySupport>true</replaySupport>
+ <replayLogCreationTime>
+ 2007-07-08T00:00:00Z
+ </replayLogCreationTime>
+ </stream>
+ <stream>
+ <name>SNMP</name>
+ <description>SNMP notifications</description>
+ <replaySupport>false</replaySupport>
+ </stream>
+ <stream>
+ <name>syslog-critical</name>
+ <description>Critical and higher severity
+ </description>
+ <replaySupport>true</replaySupport>
+ <replayLogCreationTime>
+ 2007-07-01T00:00:00Z
+ </replayLogCreationTime>
+ </stream>
+ </streams>
+ </netconf>
+ </data>
+ </rpc-reply>
+
+3.2.5.2. Event Stream Subscription
+
+ A NETCONF client may request from the NETCONF server the list of
+ event streams available to this session and then issue a <create-
+ subscription> request with the desired event stream name. Omitting
+ the event stream name from the <create-subscription> request results
+ in subscription to the default NETCONF event stream.
+
+
+
+
+
+
+
+
+Chisholm & Trevino Standards Track [Page 14]
+
+RFC 5277 NETCONF Event Notifications July 2008
+
+
+3.2.5.2.1. Filtering Event Stream Contents
+
+ The set of event notifications delivered in an event stream may be
+ further refined by applying a user-specified filter supplied at
+ subscription creation time ( <create-subscription> ). This is a
+ transient filter associated with the event notification subscription
+ and does not modify the event stream configuration. The filter
+ element is applied against the contents of the <notification> wrapper
+ and not the wrapper itself. See section 5 for examples. Either
+ subtree or XPATH filtering can be used.
+
+ XPATH support for the Notification capability is advertised as part
+ of the normal XPATH capability advertisement. If XPATH support is
+ advertised via the XPATH capability, then XPATH is supported for
+ notification filtering. If this capability is not advertised, XPATH
+ is not supported for notification filtering.
+
+3.3. Notification Replay
+
+3.3.1. Overview
+
+ Replay is the ability to create an event subscription that will
+ resend recently generated notifications, or in some cases send them
+ for the first time to a particular NETCONF client. These
+ notifications are sent the same way as normal notifications.
+
+ A replay of notifications is specified by including the optional
+ <startTime> parameter to the subscription command, which indicates
+ the start time of the replay. The end time is specified using the
+ optional <stopTime> parameter. If not present, notifications will
+ continue to be sent until the subscription is terminated.
+
+ A notification stream that supports replay is not expected to have an
+ unlimited supply of saved notifications available to accommodate any
+ replay request. Clients can query <replayLogCreationTime> and
+ <replayLogAgedTime> to learn about the availability of notifications
+ for replay.
+
+ The actual number of stored notifications available for retrieval at
+ any given time is a NETCONF server implementation-specific matter.
+ Control parameters for this aspect of the feature are outside the
+ scope of this document.
+
+ Replay is dependent on a notification stream supporting some form of
+ notification logging, although it puts no restrictions on the size or
+ form of the log, or where it resides within the device. Whether or
+ not a stream supports replay can be discovered by doing a <get>
+ operation on the <streams> element of the Notification Management
+
+
+
+Chisholm & Trevino Standards Track [Page 15]
+
+RFC 5277 NETCONF Event Notifications July 2008
+
+
+ Schema and looking at the value of the <replaySupport> object. This
+ schema also provides the <replayLogCreationTime> element to indicate
+ the earliest available logged notification.
+
+3.3.2. Creating a Subscription with Replay
+
+ This feature uses optional parameters to the <create-subscription>
+ command called <startTime> and <stopTime>. <startTime> identifies the
+ earliest date and time of interest for event notifications being
+ replayed and also indicates that a subscription will be providing
+ replay of notifications. Events generated before this time are not
+ matched. <stopTime> specifies the latest date and time of interest
+ for event notifications being replayed. If it is not present, then
+ notifications will continue to be sent until the subscription is
+ terminated.
+
+ Note that <startTime> and <stopTime> are associated with the time an
+ event was generated by the event source.
+
+ A <replayComplete> notification is sent to indicate that all of the
+ replay notifications have been sent and must not be sent for any
+ other reason. If this subscription has a stop time, then this
+ session becomes a normal NETCONF session again. The NETCONF server
+ will then accept <rpc> operations even if the server did not
+ previously accept such operations due to lack of interleave support.
+ In the case of a subscription without a stop time, after the
+ <replayComplete> notification has been sent, it can be expected that
+ any notifications generated since the start of the subscription
+ creation will be sent, followed by notifications as they arise
+ naturally within the system.
+
+ The <replayComplete> and <notificationComplete> notifications cannot
+ be filtered out. They will always be sent on a replay subscription
+ that specified a <startTime> and <stopTime>, respectively.
+
+3.4. Notification Management Schema
+
+ This Schema is used to learn about the event streams supported on the
+ system. It also contains the definition of the <replayComplete> and
+ <notificationComplete> notifications, which are sent to indicate that
+ an event replay has sent all applicable notifications and that the
+ subscription has terminated, respectively.
+
+
+
+
+
+
+
+
+
+Chisholm & Trevino Standards Track [Page 16]
+
+RFC 5277 NETCONF Event Notifications July 2008
+
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
+ xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"
+ xmlns:ncEvent="urn:ietf:params:xml:ns:netconf:notification:1.0"
+ xmlns:manageEvent="urn:ietf:params:xml:ns:netmod:notification"
+ targetNamespace="urn:ietf:params:xml:ns:netmod:notification"
+ elementFormDefault="qualified"
+ attributeFormDefault="unqualified"
+ xml:lang="en" version="1.0">
+ <xs:annotation>
+ <xs:documentation xml:lang="en">
+ A schema that can be used to learn about current
+ event streams. It also contains the replayComplete
+ and notificationComplete notification.
+ </xs:documentation>
+ </xs:annotation>
+
+ <xs:import namespace="http://www.w3.org/XML/1998/namespace"
+ schemaLocation="http://www.w3.org/2001/xml.xsd"/>
+ <xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"
+ schemaLocation="netconf.xsd"/>
+ <xs:import namespace=
+ "urn:ietf:params:xml:ns:netconf:notification:1.0"
+ schemaLocation="notification.xsd"/>
+
+ <xs:element name="netconf" type="manageEvent:Netconf"/>
+
+ <xs:complexType name="Netconf">
+ <xs:sequence>
+ <xs:element name="streams" >
+ <xs:annotation>
+ <xs:documentation>
+ The list of event streams supported by the
+ system. When a query is issued, the returned
+ set of streams is determined based on user
+ privileges.
+ </xs:documentation>
+ </xs:annotation>
+ <xs:complexType>
+ <xs:sequence minOccurs="1" maxOccurs="unbounded">
+ <xs:element name="stream">
+ <xs:annotation>
+ <xs:documentation>
+ Stream name, description, and other information.
+ </xs:documentation>
+ </xs:annotation>
+ <xs:complexType>
+ <xs:sequence>
+
+
+
+Chisholm & Trevino Standards Track [Page 17]
+
+RFC 5277 NETCONF Event Notifications July 2008
+
+
+ <xs:element name="name"
+ type="ncEvent:streamNameType">
+ <xs:annotation>
+ <xs:documentation>
+ The name of the event stream. If this is
+ the default NETCONF stream, this must have
+ the value "NETCONF".
+ </xs:documentation>
+ </xs:annotation>
+ </xs:element>
+ <xs:element name="description"
+ type="xs:string">
+ <xs:annotation>
+ <xs:documentation>
+ A description of the event stream, including
+ such information as the type of events that
+ are sent over this stream.
+ </xs:documentation>
+ </xs:annotation>
+ </xs:element>
+ <xs:element name="replaySupport"
+ type="xs:boolean">
+ <xs:annotation>
+ <xs:documentation>
+ An indication of whether or not event replay
+ is available on this stream.
+ </xs:documentation>
+ </xs:annotation>
+ </xs:element>
+ <xs:element name="replayLogCreationTime"
+ type="xs:dateTime" minOccurs="0">
+ <xs:annotation>
+ <xs:documentation>
+ The timestamp of the creation of the log
+ used to support the replay function on
+ this stream.
+ Note that this might be earlier then
+ the earliest available
+ notification in the log. This object
+ is updated if the log resets
+ for some reason. This
+ object MUST be present if replay is
+ supported.
+ </xs:documentation>
+ </xs:annotation>
+ </xs:element>
+ <xs:element name="replayLogAgedTime"
+ type="xs:dateTime" minOccurs="0">
+
+
+
+Chisholm & Trevino Standards Track [Page 18]
+
+RFC 5277 NETCONF Event Notifications July 2008
+
+
+ <xs:annotation>
+ <xs:documentation>
+ The timestamp of the last notification
+ aged out of the log. This
+ object MUST be present if replay is
+ supported and any notifications
+ have been aged out of the log.
+ </xs:documentation>
+ </xs:annotation>
+ </xs:element>
+ </xs:sequence>
+ </xs:complexType>
+ </xs:element>
+ </xs:sequence>
+ </xs:complexType>
+ </xs:element>
+ </xs:sequence>
+ </xs:complexType>
+
+ <xs:complexType name="ReplayCompleteNotificationType">
+ <xs:complexContent>
+ <xs:extension base="ncEvent:NotificationContentType"/>
+ </xs:complexContent>
+ </xs:complexType>
+
+ <xs:element name="replayComplete"
+ type="manageEvent:ReplayCompleteNotificationType"
+ substitutionGroup="ncEvent:notificationContent">
+ <xs:annotation>
+ <xs:documentation>
+ This notification is sent to signal the end of a replay
+ portion of a subscription.
+ </xs:documentation>
+ </xs:annotation>
+ </xs:element>
+
+ <xs:complexType name="NotificationCompleteNotificationType">
+ <xs:complexContent>
+ <xs:extension base="ncEvent:NotificationContentType"/>
+ </xs:complexContent>
+ </xs:complexType>
+
+ <xs:element name="notificationComplete"
+ type="manageEvent:NotificationCompleteNotificationType"
+ substitutionGroup="ncEvent:notificationContent">
+ <xs:annotation>
+ <xs:documentation>
+ This notification is sent to signal the end of a
+
+
+
+Chisholm & Trevino Standards Track [Page 19]
+
+RFC 5277 NETCONF Event Notifications July 2008
+
+
+ notification subscription. It is sent in the case
+ that stopTime was specified during the creation of
+ the subscription.
+ </xs:documentation>
+ </xs:annotation>
+ </xs:element>
+
+ </xs:schema>
+
+3.5. Subscriptions Data
+
+ Subscriptions are non-persistent state information, and their
+ lifetime is defined by their session or by the <stopTime> parameter.
+
+3.6. Filter Mechanics
+
+ If a filter element is specified to look for data of a particular
+ value, and the data item is not present within a particular event
+ notification for its value to be checked against, the notification
+ will be filtered out. For example, if one were to check for
+ 'severity=critical' in a configuration event notification where this
+ field was not supported, then the notification would be filtered out.
+
+ For subtree filtering, a non-empty node set means that the filter
+ matches. For XPath filtering, the mechanisms defined in [XPATH]
+ should be used to convert the returned value to boolean.
+
+3.6.1. Filtering
+
+ Filtering is explicitly stated when the event notification
+ subscription is created. This is specified via the 'filter'
+ parameter. A Filter only exists as a parameter to the subscription.
+
+3.7. Message Flow
+
+ The following figure depicts message flow between a NETCONF client
+ (C) and NETCONF server (S) in order to create a subscription and
+ begin the flow of notifications. This subscription specifies a
+ <startTime>, so the server starts by replaying logged notifications.
+ It is possible that many rpc/rpc-reply sequences occur before the
+ subscription is created, but this is not depicted in the figure.
+
+
+
+
+
+
+
+
+
+
+Chisholm & Trevino Standards Track [Page 20]
+
+RFC 5277 NETCONF Event Notifications July 2008
+
+
+ C S
+ | |
+ | capability exchange |
+ |-------------------------->|
+ |<------------------------->|
+ | |
+ | <create-subscription> | (startTime)
+ |-------------------------->|
+ |<--------------------------|
+ | <rpc-reply> |
+ | |
+ | <notification> |
+ |<--------------------------|
+ | |
+ | <notification> |
+ |<--------------------------|
+ | <notification> | (replayComplete)
+ |<--------------------------|
+ | |
+ | |
+ | |
+ | <notification> |
+ |<--------------------------|
+ | |
+ | |
+ | <notification> |
+ |<--------------------------|
+ | |
+ | |
+
+ Figure 3
+
+ The following figure depicts message flow between a NETCONF client
+ (C) and NETCONF server (S) in order to create a subscription and
+ begin the flow of notifications. This subscription specified a
+ <startTime> and <stopTime> so it starts by replaying logged
+ notifications and then returns to be a normal command-response
+ NETCONF session after the <replayComplete> and <notificationComplete>
+ notifications are sent and it is available to process <rpc> requests.
+ It is possible that many rpc/rpc-reply sequences occur before the
+ subscription is created, but this is not depicted in the figure.
+
+
+
+
+
+
+
+
+
+
+Chisholm & Trevino Standards Track [Page 21]
+
+RFC 5277 NETCONF Event Notifications July 2008
+
+
+ C S
+ | |
+ | capability exchange |
+ |-------------------------->|
+ |<------------------------->|
+ | |
+ | <create-subscription> | (startTime,
+ |-------------------------->| stopTime)
+ |<--------------------------|
+ | <rpc-reply> |
+ | |
+ | <notification> |
+ |<--------------------------|
+ | |
+ | <notification> |
+ |<--------------------------|
+ | <notification> | (replayComplete)
+ |<--------------------------|
+ | <notification> |(notificationComplete)
+ |<--------------------------|
+ | |
+ | |
+ | |
+ | <rpc> |
+ |-------------------------->|
+ |<--------------------------|
+ | <rpc-reply> |
+ | |
+
+
+ Figure 4
+
+4. XML Schema for Event Notifications
+
+ The following [XMLSchema] defines NETCONF Event Notifications.
+
+<?xml version="1.0" encoding="UTF-8"?>
+ <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
+ xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"
+ xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"
+ targetNamespace=
+ "urn:ietf:params:xml:ns:netconf:notification:1.0"
+ elementFormDefault="qualified"
+ attributeFormDefault="unqualified"
+ xml:lang="en">
+
+
+
+
+
+
+Chisholm & Trevino Standards Track [Page 22]
+
+RFC 5277 NETCONF Event Notifications July 2008
+
+
+ <!-- import standard XML definitions -->
+
+ <xs:import namespace="http://www.w3.org/XML/1998/namespace"
+ schemaLocation="http://www.w3.org/2001/xml.xsd">
+ <xs:annotation>
+ <xs:documentation>
+ This import accesses the xml: attribute groups for the
+ xml:lang as declared on the error-message element.
+ </xs:documentation>
+ </xs:annotation>
+ </xs:import>
+
+ <!-- import base netconf definitions -->
+ <xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"
+ schemaLocation="netconf.xsd"/>
+
+<!-- ************** Symmetrical Operations ********************-->
+
+ <!-- <create-subscription> operation -->
+
+ <xs:complexType name="createSubscriptionType">
+ <xs:complexContent>
+ <xs:extension base="netconf:rpcOperationType">
+ <xs:sequence>
+ <xs:element name="stream"
+ type="streamNameType" minOccurs="0">
+ <xs:annotation>
+ <xs:documentation>
+ An optional parameter that indicates
+ which stream of events is of interest.
+ If not present, then events in the
+ default NETCONF stream will be sent.
+ </xs:documentation>
+ </xs:annotation>
+ </xs:element>
+ <xs:element name="filter"
+ type="netconf:filterInlineType"
+ minOccurs="0">
+ <xs:annotation>
+ <xs:documentation>
+ An optional parameter that indicates
+ which subset of all possible events
+ is of interest. The format of this
+ parameter is the same as that of the
+ filter parameter in the NETCONF
+ protocol operations. If not
+ present, all events not precluded
+ by other parameters will be sent.
+
+
+
+Chisholm & Trevino Standards Track [Page 23]
+
+RFC 5277 NETCONF Event Notifications July 2008
+
+
+ </xs:documentation>
+ </xs:annotation>
+ </xs:element>
+ <xs:element name="startTime" type="xs:dateTime"
+ minOccurs="0" >
+ <xs:annotation>
+ <xs:documentation>
+ A parameter used to trigger the replay
+ feature indicating that the replay
+ should start at the time specified. If
+ start time is not present, this is not a
+ replay subscription.
+ </xs:documentation>
+ </xs:annotation>
+ </xs:element>
+ <xs:element name="stopTime" type="xs:dateTime"
+ minOccurs="0" >
+ <xs:annotation>
+ <xs:documentation>
+ An optional parameter used with the
+ optional replay feature to indicate the
+ newest notifications of interest. If
+ stop time is not present, the
+ notifications will continue until the
+ subscription is terminated. Must be
+ used with startTime.
+ </xs:documentation>
+ </xs:annotation>
+ </xs:element>
+ </xs:sequence>
+ </xs:extension>
+ </xs:complexContent>
+ </xs:complexType>
+ <xs:simpleType name="streamNameType">
+ <xs:annotation>
+ <xs:documentation>
+ The name of an event stream.
+ </xs:documentation>
+ </xs:annotation>
+ <xs:restriction base="xs:string"/>
+ </xs:simpleType>
+
+
+
+
+
+
+
+
+
+
+Chisholm & Trevino Standards Track [Page 24]
+
+RFC 5277 NETCONF Event Notifications July 2008
+
+
+ <xs:element name="create-subscription"
+ type="createSubscriptionType"
+ substitutionGroup="netconf:rpcOperation">
+ <xs:annotation>
+ <xs:documentation>
+ The command to create a notification subscription. It
+ takes as argument the name of the notification stream
+ and filter. Both of those options
+ limit the content of the subscription. In addition,
+ there are two time-related parameters, startTime and
+ stopTime, which can be used to select the time interval
+ of interest to the notification replay feature.
+ </xs:documentation>
+ </xs:annotation>
+ </xs:element>
+
+<!-- ************** One-way Operations ******************-->
+
+ <!-- <Notification> operation -->
+ <xs:complexType name="NotificationContentType"/>
+
+ <xs:element name="notificationContent"
+ type="NotificationContentType" abstract="true"/>
+
+ <xs:complexType name="NotificationType">
+ <xs:sequence>
+ <xs:element name="eventTime" type="xs:dateTime">
+ <xs:annotation>
+ <xs:documentation>
+ The time the event was generated by the event source.
+ </xs:documentation>
+ </xs:annotation>
+ </xs:element>
+ <xs:element ref="notificationContent"/>
+ </xs:sequence>
+ </xs:complexType>
+
+ <xs:element name="notification" type="NotificationType"/>
+ </xs:schema>
+
+
+
+
+
+
+
+
+
+
+
+
+Chisholm & Trevino Standards Track [Page 25]
+
+RFC 5277 NETCONF Event Notifications July 2008
+
+
+5. Filtering Examples
+
+ The following section provides examples to illustrate the various
+ methods of filtering content on an event notification subscription.
+
+ In order to illustrate the use of filter expressions, it is necessary
+ to assume some of the event notification content. The examples below
+ assume that the event notification schema definition has an <event>
+ element at the top level consisting of the event class (e.g., fault,
+ state, config), reporting entity, and either severity or operational
+ state.
+
+ Examples in this section are generated from the following fictional
+ Schema.
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <xs:schema targetNamespace="http://example.com/event/1.0"
+ xmlns="http://example.com/event/1.0"
+ elementFormDefault="qualified"
+ xmlns:xs="http://www.w3.org/2001/XMLSchema"
+ xmlns:ncEvent="urn:ietf:params:xml:ns:netconf:notification:1.0">
+
+ <xs:import namespace=
+ "urn:ietf:params:xml:ns:netconf:notification:1.0"
+ schemaLocation="notification.xsd"/>
+
+ <xs:complexType name="eventType">
+ <xs:complexContent>
+ <xs:extension base="ncEvent:NotificationContentType">
+ <xs:sequence>
+ <xs:element name="eventClass" />
+ <xs:element name="reportingEntity">
+ <xs:complexType>
+ <xs:sequence>
+ <xs:any namespace="##any"
+ processContents="lax"/>
+ </xs:sequence>
+ </xs:complexType>
+ </xs:element>
+ <xs:choice>
+ <xs:element name="severity"/>
+ <xs:element name="operState"/>
+ </xs:choice>
+ </xs:sequence>
+ </xs:extension>
+ </xs:complexContent>
+ </xs:complexType>
+
+
+
+
+Chisholm & Trevino Standards Track [Page 26]
+
+RFC 5277 NETCONF Event Notifications July 2008
+
+
+ <xs:element name="event"
+ type="eventType"
+ substitutionGroup="ncEvent:notificationContent"/>
+
+ </xs:schema>
+
+ The above fictional notification definition could result in the
+ following sample notification list, which is used in the examples in
+ this section.
+
+ <notification
+ xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
+ <eventTime>2007-07-08T00:01:00Z</eventTime>
+ <event xmlns="http://example.com/event/1.0">
+ <eventClass>fault</eventClass>
+ <reportingEntity>
+ <card>Ethernet0</card>
+ </reportingEntity>
+ <severity>major</severity>
+ </event>
+ </notification>
+
+ <notification
+ xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
+ <eventTime>2007-07-08T00:02:00Z</eventTime>
+ <event xmlns="http://example.com/event/1.0">
+ <eventClass>fault</eventClass>
+ <reportingEntity>
+ <card>Ethernet2</card>
+ </reportingEntity>
+ <severity>critical</severity>
+ </event>
+ </notification>
+
+ <notification
+ xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
+ <eventTime>2007-07-08T00:04:00Z</eventTime>
+ <event xmlns="http://example.com/event/1.0">
+ <eventClass>fault</eventClass>
+ <reportingEntity>
+ <card>ATM1</card>
+ </reportingEntity>
+ <severity>minor</severity>
+ </event>
+ </notification>
+
+
+
+
+
+
+Chisholm & Trevino Standards Track [Page 27]
+
+RFC 5277 NETCONF Event Notifications July 2008
+
+
+ <notification
+ xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
+ <eventTime>2007-07-08T00:10:00Z</eventTime>
+ <event xmlns="http://example.com/event/1.0">
+ <eventClass>state</eventClass>
+ <reportingEntity>
+ <card>Ethernet0</card>
+ </reportingEntity>
+ <operState>enabled</operState>
+ </event>
+ </notification>
+
+5.1. Subtree Filtering
+
+ XML subtree filtering is not well-suited for creating elaborate
+ filter definitions given that it only supports equality comparisons
+ and application of the logical OR operators (e.g., in an event
+ subtree, give me all event notifications that have severity=critical,
+ severity=major, or severity=minor). Nevertheless, it may be used for
+ defining simple event notification forwarding filters as shown below.
+
+ The following example illustrates how to select fault events which
+ have severities of critical, major, or minor. The filtering criteria
+ evaluation is as follows:
+
+ ((fault & severity=critical) | (fault & severity=major) | (fault &
+ severity=minor))
+
+ <netconf:rpc netconf:message-id="101"
+ xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
+ <create-subscription
+ xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
+ <filter netconf:type="subtree">
+ <event xmlns="http://example.com/event/1.0">
+ <eventClass>fault</eventClass>
+ <severity>critical</severity>
+ </event>
+ <event xmlns="http://example.com/event/1.0">
+ <eventClass>fault</eventClass>
+ <severity>major</severity>
+ </event>
+ <event xmlns="http://example.com/event/1.0">
+ <eventClass>fault</eventClass>
+ <severity>minor</severity>
+ </event>
+ </filter>
+ </create-subscription>
+ </netconf:rpc>
+
+
+
+Chisholm & Trevino Standards Track [Page 28]
+
+RFC 5277 NETCONF Event Notifications July 2008
+
+
+ The following example illustrates how to select state or config
+ EventClasses or fault events that are related to card Ethernet0. The
+ filtering criteria evaluation is as follows:
+
+ ( state | config | ( fault & ( card=Ethernet0)))
+
+<netconf:rpc netconf:message-id="101"
+ xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
+ <create-subscription
+ xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
+ <filter netconf:type="subtree">
+ <event xmlns="http://example.com/event/1.0">
+ <eventClass>state</eventClass>
+ </event>
+ <event xmlns="http://example.com/event/1.0">
+ <eventClass>config</eventClass>
+ </event>
+ <event xmlns="http://example.com/event/1.0">
+ <eventClass>fault</eventClass>
+ <reportingEntity>
+ <card>Ethernet0</card>
+ </reportingEntity>
+ </event>
+ </filter>
+ </create-subscription>
+</netconf:rpc>
+
+5.2. XPATH Filters
+
+ The following [XPATH] example illustrates how to select fault
+ EventClass notifications that have severities of critical, major, or
+ minor. The filtering criteria evaluation is as follows:
+
+ ((fault) & ((severity=critical) | (severity=major) | (severity =
+ minor)))
+
+ <netconf:rpc netconf:message-id="101"
+ xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
+ <create-subscription
+ xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
+ <filter netconf:type="xpath"
+ xmlns:ex="http://example.com/event/1.0"
+ select="/ex:event[ex:eventClass='fault' and
+ (ex:severity='minor' or ex:severity='major'
+ or ex:severity='critical')]"/>
+ </create-subscription>
+ </netconf:rpc>
+
+
+
+
+Chisholm & Trevino Standards Track [Page 29]
+
+RFC 5277 NETCONF Event Notifications July 2008
+
+
+ The following example illustrates how to select state and config
+ EventClasses or fault events of any severity that come from card
+ Ethernet0. The filtering criteria evaluation is as follows:
+
+ ( state | config | (fault & card=Ethernet0))
+
+ <netconf:rpc message-id="101"
+ xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
+ <create-subscription
+ xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
+ <filter netconf:type="xpath"
+ xmlns:ex="http://example.com/event/1.0"
+ select="/ex:event[
+ (ex:eventClass='state' or ex:eventClass='config') or
+ ((ex:eventClass='fault' and ex:card='Ethernet0'))]"/>
+ </create-subscription>
+ </netconf:rpc>
+
+6. Interleave Capability
+
+6.1. Description
+
+ The :interleave capability indicates that the NETCONF peer supports
+ the ability to interleave other NETCONF operations within a
+ notification subscription. This means the NETCONF server MUST
+ receive, process, and respond to NETCONF requests on a session with
+ an active notification subscription. This capability helps
+ scalability by reducing the total number of NETCONF sessions required
+ by a given operator or management application.
+
+6.2. Dependencies
+
+ This capability is dependent on the notification capability being
+ supported.
+
+6.3. Capability Identifier
+
+ The :interleave capability is identified by the following capability
+ string:
+
+ urn:ietf:params:netconf:capability:interleave:1.0
+
+
+
+
+
+
+
+
+
+
+Chisholm & Trevino Standards Track [Page 30]
+
+RFC 5277 NETCONF Event Notifications July 2008
+
+
+6.4. New Operations
+
+ None.
+
+6.5. Modifications to Existing Operations
+
+ When a <create-subscription> is sent while another subscription is
+ active on that session, the following error will be returned:
+
+ Tag: operation-failed
+
+ Error-type: protocol
+
+ Severity: error
+
+ Error-info: none
+
+ Description: Request could not be completed because the requested
+ operation failed for some reason not covered by any other error
+ condition.
+
+7. Security Considerations
+
+ The security considerations from the base [NETCONF] document also
+ apply to the Notification capability.
+
+ The access control framework and the choice of transport will have a
+ major impact on the security of the solution.
+
+ The <notification> elements are never sent before the transport layer
+ and the NETCONF layer, including capabilities exchange, have been
+ established and the manager has been identified and authenticated.
+
+ It is recommended that care be taken to secure execution:
+
+ o <create-subscription> invocation
+
+ o <get> on read-only data models
+
+ o <notification> content
+
+ Secure execution means ensuring that a secure transport is used as
+ well as ensuring that the user has sufficient authorization to
+ perform the function they are requesting against the specific subset
+ of NETCONF content involved. When a <get> is received that refers to
+ the content defined in this memo, clients should only be able to view
+ the content for which they have sufficient privileges. A create
+ <create-subscription> operation can be considered like a deferred
+
+
+
+Chisholm & Trevino Standards Track [Page 31]
+
+RFC 5277 NETCONF Event Notifications July 2008
+
+
+ <get>, and the content that different users can access may vary.
+ This different access is reflected in the <notification> that
+ different users are able to subscribe to.
+
+ One potential security issue is the transport of data from non-
+ NETCONF streams, such as syslog and SNMP. This data may be more
+ vulnerable (or less 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. The NETCONF server is responsible for applying access
+ control to stream content.
+
+ The contents of notifications, as well as the names of event streams,
+ may contain sensitive information and care should be taken to ensure
+ that they are viewed only by authorized users. The NETCONF server
+ MUST NOT include any content in a notification that the user is not
+ authorized to view.
+
+ If a subscription is created with a <stopTime>, the NETCONF session
+ will return to being a normal command-response NETCONF session when
+ the replay is completed. It is the responsibility of the NETCONF
+ client to close this session when it is no longer of use.
+
+ If a malicious or buggy NETCONF client sends a number of <create-
+ subscription> requests, then these subscriptions accumulate and may
+ use up system resources. In such a situation, subscriptions can be
+ terminated by terminating the suspect underlying NETCONF sessions
+ using the <kill-session> operation.
+
+8. IANA Considerations
+
+ This document registers three URIs for the NETCONF XML namespace in
+ the IETF XML registry [RFC3688].
+
+ Following the format in RFC 3688, IANA has made the following
+ registration. Note that the capability URNs are also compliant to
+ section 10.3 of [NETCONF].
+
+ +--------------------+----------------------------------------------+
+ | Index | Capability Identifier |
+ +--------------------+----------------------------------------------+
+ | :notification | urn:ietf:params:netconf:capability: |
+ | | notification:1.0 |
+ | | |
+ | :interleave | urn:ietf:params:netconf:capability: |
+ | | interleave:1.0 |
+ +--------------------+----------------------------------------------+
+
+
+
+
+Chisholm & Trevino Standards Track [Page 32]
+
+RFC 5277 NETCONF Event Notifications July 2008
+
+
+ URI: urn:ietf:params:xml:ns:netmod:notification
+
+ URI: urn:ietf:params:xml:ns:netconf:notification:1.0
+
+ Registrant Contact: The IESG.
+
+ XML: N/A, the requested URI is an XML namespace.
+
+ In addition, IANA registered the XML Schema defined in Section 4.
+
+9. Acknowledgements
+
+ Thanks to Gilbert Gagnon, Greg Wilbur, and Kim Curran for providing
+ their input into the early work on this document. In addition, the
+ editors would like to acknowledge input at the Vancouver editing
+ session from the following people: Orly Nicklass, James Balestriere,
+ Yoshifumi Atarashi, Glenn Waters, Alexander Clemm, Dave Harrington,
+ Dave Partain, Ray Atarashi, David Perkins, and the following
+ additional people from the Montreal editing session: Balazs Lengyel,
+ Phil Shafer, Rob Enns, Andy Bierman, Dan Romascanu, Bert Wijnen,
+ Simon Leinen, Juergen Schoenwaelder, Hideki Okita, Vincent Cridlig,
+ Martin Bjorklund, Olivier Festor, Radu State, Brian Trammell, and
+ William Chow. We would also like to thank Li Yan for his numerous
+ reviews, as well as Suresh Krishnan for his gen-art review of the
+ document.
+
+10. Normative References
+
+ [NETCONF] Enns, R., Ed., "NETCONF Configuration Protocol",
+ RFC 4741, December 2006.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
+ Internet: Timestamps", RFC 3339, July 2002.
+
+ [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
+ January 2004.
+
+ [XML] World Wide Web Consortium, "Extensible Markup Language
+ (XML) 1.0", W3C XML, February 1998,
+ <http://www.w3.org/TR/1998/REC-xml-19980210>.
+
+ [XMLSchema] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
+ "XML Schema Part 1: Structures Second Edition", W3C http
+ ://www.w3.org/TR/2004/REC-xmlschema-1-20041028/
+ structures.html, October 2004.
+
+
+
+Chisholm & Trevino Standards Track [Page 33]
+
+RFC 5277 NETCONF Event Notifications July 2008
+
+
+ [XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath)
+ Version 1.0",
+ W3C http://www.w3.org/TR/1999/REC-xpath-19991116,
+ November 1999.
+
+Authors' Addresses
+
+ Sharon Chisholm
+ Nortel
+ 3500 Carling Ave
+ Nepean, Ontario K2H 8E9
+ Canada
+
+ EMail: schishol@nortel.com
+
+
+ Hector Trevino
+ Cisco
+ Suite 400
+ 9155 E. Nichols Ave
+ Englewood, CO 80112
+ USA
+
+ EMail: htrevino@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chisholm & Trevino Standards Track [Page 34]
+
+RFC 5277 NETCONF Event Notifications July 2008
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2008).
+
+ 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, THE IETF TRUST 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
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ 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
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Chisholm & Trevino Standards Track [Page 35]
+