Subject: notification map vs. filter

From: ad <[email-masked]>
Date: Wed, 7 Mar 2001 10:11:45 -0500 (EST)

For some reason this bounced.

---------- Forwarded message ----------
To: <[email-masked]>
Cc: <[email-masked]>
From: <[email-masked]>

Hi,

The GSMP MIB is now under IESG review and a comment had been made on how
we handle the GSMP event to SNMP notification mapping.

In draft-ietf-gsmp-mib-04.txt we proposed to use a function called
NotificationMap which provides configuration option or the controller
or switch to control which defines whether a corresponding SNMP
notification should be sent if a GSMP event is received or sent
by the GSMP entity. The default value is to issue SNMP notifications
for the GSMP event sessionDown, sessionUp, sendFailureIndication and
receivedFailureIndication.

This is partly duplicating the generic support already in the SNMP
Application Notification Originators defined by RFC2573. Here there
exist a filter mechanism to define which (group of) SNMP notifications
to send to which (groups) of managers. The default here is (as far as I
have understood it) to not filter, e.g send all notifications.

The question is if we should remove the NotificationMap in the GSMP mib
and rely soly on RFC2573, or if the NotificationMaps should remain.

For this decision we need WG input. Please.

Regards
/// Hasse

Some SNMP trivia for the lazy that doesn't bother reading the whole draft
and RFC. Included are the object of draft-ietf-gsmp-mib-04.txt and the
text of section 6. Notification Filtering in RFC 2573.

Internet Draft                   GSMP MIB                  December 2000

    gsmpControllerNotificationMap OBJECT-TYPE
        SYNTAX        BITS {
                              sessionDown(0),
                              sessionUp(1),
                              sendFailureIndication(2),
                              receivedFailureIndication(3),
                              portUpEvent(4),
                              portDownEvent(5),
                              invalidLabelEvent(6),
                              newPortEvent(7),
                              deadPortEvent(8),
                              adjacencyUpdateEvent(9)
                           }
        MAX-ACCESS    read-create
        STATUS        current
        DESCRIPTION
            "This bitmap defines whether a corresponding SNMP
            notification should be sent if a GSMP event is received
            by the Switch Controller. If the bit is set to 1 a
            notification should be sent."
        DEFVAL {{ sessionDown, sessionUp,
               sendFailureIndication, receivedFailureIndication }}
        ::= { gsmpControllerEntry 10 }
and

    gsmpSwitchNotificationMap OBJECT-TYPE
        SYNTAX        BITS {
                              sessionDown(0),
                              sessionUp(1),
                              sendFailureIndication(2),
                              receivedFailureIndication(3),
                              portUpEvent(4),
                              portDownEvent(5),
                              invalidLabelEvent(6),
                              newPortEvent(7),
                              deadPortEvent(8),
                              adjacencyUpdateEvent(9)
                           }
        MAX-ACCESS    read-create
        STATUS        current
        DESCRIPTION
            "This bitmap defines whether a corresponding SNMP
            notification should be sent if an GSMP event is sent
            by the Switch Entity. If the bit is set to 1 a
            notification should be sent."
        DEFVAL {{ sessionDown, sessionUp,
               sendFailureIndication, receivedFailureIndication }}
        ::= { gsmpSwitchEntry 10 }

RFC 2573                   SNMP Applications                  April 1999

6.  Notification Filtering

   This section describes the mechanisms used by a notification
   originator application when using the MIB module described in this
   document to filter generation of notifications.

   A notification originator uses the snmpNotifyFilterTable to filter
   notifications.  A notification filter profile may be associated with
   a particular entry in the snmpTargetParamsTable.  The associated
   filter profile is identified by an entry in the
   snmpNotifyFilterProfileTable whose index is equal to the index of the
   entry in the snmpTargetParamsTable.  If no such entry exists in the
   snmpNotifyFilterProfileTable, no filtering is performed for that
   management target.

   If such an entry does exist, the value of snmpNotifyFilterProfileName
   of the entry is compared with the corresponding portion of the index
   of all active entries in the snmpNotifyFilterTable.  All such entries
   for which this comparison results in an exact match are used for
   filtering a notification generated using the associated
   snmpTargetParamsEntry.  If no such entries exist, no filtering is
   performed, and a notification may be sent to the management target.

   Otherwise, if matching entries do exist, a notification may be sent
   if the NOTIFICATION-TYPE OBJECT IDENTIFIER of the notification (this
   is the value of the element of the variable bindings whose name is
   snmpTrapOID.0, i.e., the second variable binding) is specifically
   included, and none of the object instances to be included in the
   variable-bindings of the notification are specifically excluded by
   the matching entries.

   Each set of snmpNotifyFilterTable entries is divided into two
   collections of filter subtrees:  the included filter subtrees, and
   the excluded filter subtrees.  The snmpNotifyFilterType object
   defines the collection to which each matching entry belongs.

   To determine whether a particular notification name or object
   instance is excluded by the set of matching entries, compare the
   notification name's or object instance's OBJECT IDENTIFIER with each
   of the matching entries.  For a notification name, if none match,
   then the notification name is considered excluded, and the
   notification should not be sent to this management target.  For an
   object instance, if none match, the object instance is considered
   included, and the notification may be sent to this management target.
   If one or more match, then the notification name or object instance
   is included or excluded, according to the value of
   snmpNotifyFilterType in the entry whose value of
   snmpNotifyFilterSubtree has the most sub-identifiers.  If multiple
   entries match and have the same number of sub-identifiers, then the
   lexicographically greatest instance of snmpNotifyFilterType among
   those which match determines the inclusion or exclusion.

   A notification name or object instance's OBJECT IDENTIFIER X matches
   an entry in the snmpNotifyFilterTable when the number of sub-
   identifiers in X is at least as many as in the value of
   snmpNotifyFilterSubtree for the entry, and each sub-identifier in the
   value of snmpNotifyFilterSubtree matches its corresponding sub-
   identifier in X.  Two sub-identifiers match either if the
   corresponding bit of snmpNotifyFilterMask is zero (the 'wild card'
   value), or if the two sub-identifiers are equal.