| < Prev | Back to Table of Contents | Next > |
NOTIFICATION-GROUPs
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.
valuereference NOTIFICATION-GROUP
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.
Creating a NOTIFICATION-GROUP
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 Insert > Notification Group
from the main menu, click on the Add Notification Group Button
(
) in the
Toolbar, or right-click on the desired parent within the Project
Tree, and use its New > Notification 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.
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.
Status
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
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.
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
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
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
Figure - NOTIFICATION-GROUP Workspace, Comments Page
| < Prev | Back to Table of Contents | Next > |