MIB Smithy

  1. Up to Table of Contents


Notification Groups, like Object Groups, serve two purposes in MIB design: first, they can be used to describe a relationship amongst different notifications in a MIB module, such that (for example) all of the notifications in the group must be implemented in conjunction with another. Second, notifications groups are also useful in describing levels of conformance through the use of MODULE-COMPLIANCE and AGENT-CAPABILITIES statements.

    NOTIFICATIONS  { notification ?, notification ...? }
    STATUS         statusKeyword
    DESCRIPTION    "text"
   ?REFERENCE      "text"?
    ::= { OIDValue }

Notification Groups can only be defined in SMIv2, can only reference NOTIFICATION-TYPEs defined in the same module as the group its self. Further, every notification defined in an SMIv2 module is required to be listed in at least one group in order to be conformant.

Notification Groups are not supported by COPS-PR-SPPI or SMIv1.


To create a NOTIFICATION-GROUP in MIB Smithy, you must first have created or loaded one or more MIB Modules within the project. Use the Project Tree to select the module in which to create the record -or- one of its records that is the desired parent for the new record. Then, you can either: use InserticonNotification Group from the main menu; click on the iconAdd Notification Group button in the Toolbar; or right-click on the desired parent within the Project Tree, and use its NewiconNotification Group menu. MIB Smithy will then create the record with a unique, automatically assigned name and subidentifier, and open a page in the Workspace Panel where you can edit its name and other properties.

General Properties

The Group Name, Status and OID Value properties are all available to be edited from the General Page of the Notification Group Workspace, which is pictured below.

General Page

Figure - NOTIFICATION-GROUP Workspace, General Page

Group Name

Each group must be assigned a name. MIB Smithy will automatically assign a name that is unique within the project; however, a user should assign a more suitable name that roughly describes the nature of the group, such as the relationship it describes between its member notifications. The name should be chosen so-as to minimize to the possibility of other OIDs being given the same name for compatibility with tools that do not provide mechanisms for working around name collision.

A valid group name begins with a lowercase letter and may contain zero or more additional letters or numbers. Hyphens are allowed in SMIv1 provided the name does not end in a hyphen and no two hyphens are adjacent. Hyphens are not allowed in SMIv2 except by way of conversion from SMIv1, which does not have a NOTIFICATION-GROUP equivalent.

This property is unconditionally required.


This property indicates the status of the notification group with regards to its historic nature. It may take one of three values: current, deprecated or obsolete, indicating that the group is current and valid and may continue to be used for defining conformance, that it may still be used but may soon become obsolete in the future, or that the group is now obsolete and should not continue to be used for defining conformance. Note that a group's status does not affect the status of its member notifications; however, a group should not in general have a more current status than its members (i.e., a current group should not reference obsolete notifications, but an obsolete group can reference current notifications).

This property is unconditionally required.

OID Value

This property registers a unique OBJECT IDENTIFIER value that may be used to identify the group. It is not in general used by SNMP entities, but may be used by MIB compilers and similar tools.

This property is unconditionally required.

See Also

Object Identifier Values

Notifications Property

This property corresponds both to the NOTIFICATIONS field of the NOTIFICATION-GROUP macro, and is used to specify the list of NOTIFICATION-TYPEs that are considered to be members of the group. Notifications within a group are usually implemented in an agent conjunction with one another, although notifications can be members of more than one group. At least one notification MUST be listed in a group to be conformant, as the group would serve no purpose otherwise. Further, a notification must be listed in a group referenced by an AGENT-CAPABILITIES statement in order for that statement to include a variation (i.e., to mark the notification as unimplemented). Also, every notification listed in the group must be defined in the same module as the group its self.

This property is required. At least one notification must be specified.

Notifications Page

Figure - NOTIFICATION-GROUP Workspace, Notifications Page

To add a NOTIFICATION-TYPE reference to the Notifications list, it may either be typed in manually into the space provided or selected from the drop-down list, followed by pressing the "Add" button. To delete a reference from the Notifications list, it may be selected from the list above or entered manually, followed by pressing the "Remove" button.

Description Property

The Notification Group's Description property is used to provide the reader or implementor a description of the technical purpose behind the group. This should generally include the conditions under which an agent is expected to implement the group, and how the group's members relate to one another.

This property is unconditionally required.

See Also

Formatting Text Fields

Description Page

Figure - NOTIFICATION-GROUP Workspace, Description Page

Reference Property

The Notification Group's Reference property may be used to provide the reader or implementor a reference to additional supporting documentation that may be of assistance in interpreting the purpose for the group and its member notifications.

This property is optional.

See Also

Formatting Text Fields

Reference Page

Figure - NOTIFICATION-GROUP Workspace, Reference Page

Comments Property

The Comments Property, which is common to all MIB Smithy records for which ASN.1 is generated (including modules, type assignments, NOTIFICATION-GROUPs, etc.), allows you to specify optional comments that are to be associated with the record. Like comments in programming languages, ASN.1 comments are bits of text that allow extra descriptive text to be provided that are discarded by normal parsers. When MIB Smithy generates the module, either when saving or previewing, the comments for a particular record will be generated immediately above the record they are associated with.

See Also

Formatting Comments

Comments Page

Figure - NOTIFICATION-GROUP Workspace, Comments Page

  1. Up to Table of Contents