MIB Smithy
Notifications (NOTIFICATION-TYPE/TRAP-TYPE)
Notifications are SNMP messages that are initiated by an SNMP entity acting in an agent role. Whereas other types of messages are initiated by managers (query requests), and the agent only sends messages in response to those queries, notifications allow the agent to send messages the manager without needing a request. There are two types of notifications in SNMP: the trap and the inform request. Traps are unconfirmed messages (that is, the manager does not respond to them), while informs (only available with SNMPv2 and later) expect the manager to confirm receipt.
In SMIv1, traps are defined using the TRAP-TYPE macro. SMIv2 uses the NOTIFICATION-TYPE macro (for defining both informs and normal traps). MIB Smithy generates whichever form is appropriate for the SMI version in use based on the IMPORTS list for the module. Internally and through the GUI, MIB Smithy always uses the NOTIFICATION-TYPE style, converting TRAP-TYPEs as necessary according to the rules in RFC 2576 . What this means to the user is that even though TRAP-TYPEs are defined with an integer value and enterprise OID, they are both specified as a single OID value as if defining a NOTIFICATION-TYPE.
Notifications are not supported by COPS-PR-SPPI.
Creating a Notification
To create a Notification 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 from the main menu; click on the Add Notification button in the Toolbar; or right-click on the desired parent within the Project Tree and use its New → Notification 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 Notification Name, Status and OID Value properties are all available to be edited from the General Page of the Notification Workspace, which is pictured below.
Figure - Notification Workspace, General Page
Notification Name
Each Notification 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 notification, such as its purpose or the condition under which it is to be sent. 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 Notification 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.
This property is unconditionally required.
Status
This property indicates the status of the notification with regards to its historic nature. It may take one of three values: current, deprecated or obsolete, indicating that the notification is current and valid and may continue to be used, that it may still be used but may soon become obsolete in the future, or that the notification is now obsolete and should not be implemented or expected to be supported in any recent implementation, respectively.
This property is required for NOTIFICATION-TYPE. The SMIv1 TRAP-TYPE form does not have a STATUS field, and thus this property may safely be ignored when working with SMIv1 modules.
OID Value
This property registers a unique OBJECT IDENTIFIER value that may be used by an SNMP entity to identify the notification by way of the snmpTrapOID variable binding in an SNMPv2/v3 Notification-PDU. When working with SMIv1 modules, and in consideration of mappings to the SNMPv1 Trap-PDU, this property specifies both the enterprise OID and generic-trap integer value as well as the specific-trap integer value as specified by Section 3.2 of RFC 2576, which specifies rules for mapping between SNMPv1 and SNMPv2/v3 notification parameters.
In essence, the OID Value for a TRAP-TYPE is either enterprise.value or enterprise.0.value depending on whether or not the TRAP-TYPE defines one of the "well known" standard notifications (linkUp, linkDown, coldStart, etc.) defined by the SNMP protocol. New NOTIFICATION-TYPE definitions should always be assigned OID values such that the second-to-last subidentifier is 0, which allows for bi-directional (a.k.a. "reverse-mappable") translation between SNMP versions via proxies.
This property is unconditionally required.
See Also
Objects Property
The Notification's Objects property may be used to specify a list of OBJECT-TYPEs applicable to the notification that an agent MUST include in the variable bindings (payload) of the notification when generated. For example, a MIB author designing a notification that is triggered whenever an instance of a particular object reaches a critical value may choose to require that the triggering object be included in the notification. This property corresponds both to the OBJECTS field of the NOTIFICATION-TYPE in SMIv2 and to the equivalent VARIABLES field of the TRAP-TYPE in SMIv1.
This property is optional.
Figure - Notification Workspace, Objects Page
To add an OBJECT-TYPE reference to the Objects 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 Objects list, it may be selected from the list above or entered manually, followed by pressing the "Remove" button.
Description Property
The Notification's Description property is used to provide the reader or implementor a description of the technical purpose and semantics of the notification. This should include, at the vary least, the conditions under which an agent is expected to generate the notification, how often, as well as any additional factors that may affect its generation (such as OBJECT-TYPEs whose values directly control the notification).
This property is unconditionally required.
See Also
Figure - Notification Workspace, Description Page
Reference Property
The Notification'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 rules or basis for the type. MIB Smithy will apply the same formatting rules to this property as it does for other similar quoted-text fields such as descriptions.
This property is optional.
See Also
Figure - Notification 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, Notifications, 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 Workspace, Comments Page