An event filter is a way to disable generation of specific notification event types from being added to the notification replay buffer.  This can be useful if some events are not of interest to the applications, so there is no reason to use replay buffer resources to store them.

The YANG module yumaworks-event-filter.yang contains the /event-filters definitions.

A client can configure event-filter list entries in the /event-filters/event-filter list to suppress generation of specific events.

Each entry is identified by the module name and the notification event name. An entry does not have to reference a valid module and/or notification name.  This allows filters to be present before modules are loaded into the server. If a module is loaded at run-time with the <load> or <load-bundle> operation, then the event filters will be checked and applied as needed at that time. For example, the foo-event1 notification in the acme-foo module might be defined as followed:

module acme-foo {
   namespace “”;
    prefix af;
   notification foo-event1 {
      leaf foo-count { type uint32; }
      leaf foo-msg { type string; }


To create an event filter, the client may send an <edit-config> operation request as follows:

<?xml version="1.0" encoding="UTF-8"?> 
<rpc message-id="1" trace-id="3" 
   <event-filters xmlns=""> 

Logging Event Drops

If the --log-event-drops CLI parameter is set to 'true' then a log entry will be generated each time an event is dropped because it is suppressed.  The default is 'false' (event drops due to an event filter are not logged).  Event drops due to other reasons are not affected by this CLI parameter.