The NETCONF notification delivery system allows for multiple event streams. Each event stream has its own subscriptions and its own notification queue (replay buffer). The server will always setup the NETCONF event stream. The notifications defined in ietf-netconf-notifications.yang are sent to this event stream.

Event streams can be used to group notification events for different reasons, such as by topic, or frequency, or severity..

The --event-stream parameter is used to configure an additional event stream.

The --event-stream-map parameter is used to assign all notifications defined in a specific module to an event stream.

Example: create the ‘hardware’ event stream and 2 event-stream-map entries:

> netconfd-pro --event-stream=hardware \
         --event-stream-map=ietf-hardware@hardware \
Note that if you are using custom stream the server will send notification only to the subscription with that stream. Your SIL code notification callback will have to queue notification with help of the following API in order to send the notification only to that stream; otherwise they will be sent to default NETCONF stream:

agt_not_queue_notification_stream((const xmlChar *)"hardware", notif);

Normally an event generated by internal YANG instrumentation will be sent to the NETCONF event stream. There are two ways for notifications to be sent to a configured stream:

  1. New Server API: The instrumentation can specify the event stream name. If this is configured it will be used for the queued notification. If the specified event stream is not found or  no event stream is specified  in the API call, then the server will check for an event-stream-map parameter for the module containing the notification.
  2. --event-stream-map CLI parameter: The user can configure module to event stream mappings. If no     event stream is specified by the event generator (e.g., SIL instrumentation) then the server will use the event-stream-map parameter to find a mapping. If no mapping is found then the default event stream NETCONF is used.

Event Stream Monitoring

The event streams that are enabled on the server can be monitored using the notification.yang module, which contains a top-level container called /netconf.

Example: /netconf/streams/stream list contains ‘NETCONF’ and ‘hardware’ streams.

andy@localhost> sget /netconf

Filling container /netconf:
RPC Data Reply 2 for session 3 [default]: 

rpc-reply {
  data {
    netconf {
      streams {
        stream  NETCONF {
          name NETCONF
          description 'default NETCONF event stream'
          replaySupport true
          replayLogCreationTime 2019-08-30T00:20:32Z
        stream  hardware {
          name hardware
          description 'vendor event stream'
          replaySupport true
          replayLogCreationTime 2019-08-30T00:20:32Z