NETCONF Event Notifications
Extracted elements (25)
Access control is applied after <notification> element generation per session: if a session lacks permission to receive the notification, it is silently discarded for that session. This defers authorization to per-session evaluation rather than at stream definition time.
Subscriptions are bound to a single NETCONF session and are non-persistent state; their lifetime is defined by session lifetime or the <stopTime> parameter. This design ensures that notification content fully describes an event without requiring protocol context, enabling independent analysis.
The filter element is a transient parameter applied against <notification> wrapper contents (not the wrapper itself) at subscription creation time and does not modify the underlying event stream configuration, keeping stream definitions independent of subscriber preferences.
When a <create-subscription> is sent while another subscription is already active on that session (without :interleave), the server returns an 'operation-failed' protocol error. The :interleave capability must be present to allow multiple subscriptions or interleaved RPCs.
XPATH support for notification filtering is tied to advertisement of the existing NETCONF XPATH capability. If the XPATH capability is not advertised, XPATH is not supported for notification filtering.
A NETCONF server implementation supporting the notification capability MUST support the 'NETCONF' notification event stream, which contains all NETCONF XML event notifications supported by the server.
The contents of all event streams made available to a NETCONF client MUST be encoded in XML.
The NETCONF server MUST accept and process the <close-session> operation even while a notification subscription is active. Other commands MAY be accepted; otherwise they will be rejected and the server MUST send a 'resource-denied' error.
The NETCONF server MUST NOT include any content in a notification that the user is not authorized to view.
The <replayComplete> and <notificationComplete> notifications cannot be filtered out; they will always be sent on a replay subscription that specified <startTime> and <stopTime>, respectively.
The <replayLogCreationTime> element MUST be present if replay is supported. The <replayLogAgedTime> element MUST be present if replay is supported and any notifications have been aged out of the log.
When the :interleave capability is supported, the NETCONF server MUST receive, process, and respond to NETCONF requests on a session with an active notification subscription.
Event streams are predefined sets of event notifications matching forwarding criteria. Each stream is described by <name> (mandatory, unique), <description>, <replaySupport> (boolean), and optionally <replayLogCreationTime> and <replayLogAgedTime>.
Stream discovery uses a <get> operation on the <streams> subtree under namespace urn:ietf:params:xml:ns:netmod:notification. The returned list reflects only streams available to the requesting session based on user privileges.
The <create-subscription> operation initiates an event notification subscription that sends asynchronous event notifications to the initiator until the subscription terminates. Parameters include optional stream, filter, startTime, and stopTime elements.
The notification capability is advertised using capability identifier 'urn:ietf:params:netconf:capability:notification:1.0' during the NETCONF <hello> capabilities exchange.
The <notification> element is the top-level element for one-way asynchronous event notification messages sent from server to client. It contains a mandatory <eventTime> field (dateTime, RFC3339-compliant) and notification-specific content.
The <replayComplete> notification signals the end of the replay portion of a subscription. The <notificationComplete> notification signals that a bounded subscription (with <stopTime>) has ended. Neither can be filtered out.
This document registers two NETCONF capability URNs in the IETF XML registry: urn:ietf:params:netconf:capability:notification:1.0 (:notification) and urn:ietf:params:netconf:capability:interleave:1.0 (:interleave), plus two XML namespace URIs and the XML Schema from Section 4.
A malicious or buggy NETCONF client sending many <create-subscription> requests could exhaust system resources through accumulation of subscriptions. Mitigation is to terminate suspect NETCONF sessions using <kill-session>.
Notifications are never sent before the transport layer, NETCONF layer, capabilities exchange, and manager authentication have been completed. Access control must be applied to <create-subscription>, <get> on notification data models, and <notification> content.
Transporting data from non-NETCONF streams (e.g., syslog, SNMP) over NETCONF may expose data with different security properties than its native transport; the NETCONF server is responsible for applying access control to stream content.
A subscription session transitions from normal NETCONF session → active subscription (on <create-subscription> success) → replay phase (if <startTime> specified, ends with <replayComplete>) → live notification phase → terminated (on <close-session>, <kill-session>, transport close, or <stopTime> reached, followed by <notificationComplete> if stopTime was set).
The <create-subscription> XML element carries optional child elements: <stream> (streamNameType string), <filter> (netconf:filterInlineType), <startTime> (xs:dateTime), and <stopTime> (xs:dateTime). All four children have minOccurs='0'.
The <notification> XML element contains a mandatory <eventTime> child of type xs:dateTime followed by an abstract <notificationContent> element reference, encoded under namespace urn:ietf:params:xml:ns:netconf:notification:1.0.