tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 3877

 
 
 

Alarm Management Information Base (MIB)

Part 4 of 4, p. 59 to 75
Prev RFC Part

 


prevText      Top      Up      ToC       Page 59 
6.  Examples

6.1.  Alarms Based on linkUp/linkDown Notifications

   This example demonstrates an interface-based alarm that goes into a
   state of "warning" when a linkDown Notification [RFC2863] occurs but
   the ifAdminStatus indicates the interface was taken down
   administratively.  If IfAdminStatus is "up" when the linkDown
   Notification occurs, then there is a problem, so the state of the
   alarm is critical.  A linkUp alarm clears the alarm.

linkDown NOTIFICATION-TYPE
        OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
        STATUS  current
        DESCRIPTION
            ""
    ::= { snmpTraps 3 }

linkUp NOTIFICATION-TYPE
        OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
        STATUS  current
        DESCRIPTION
            ""
    ::= { snmpTraps 4 }

 alarmModelIndex                  3
 alarmModelState                  1
 alarmModelNotificationId         linkUp
 alarmModelVarbindIndex           0
 alarmModelVarbindValue           0
 alarmModelDescription            "linkUp"
 alarmModelSpecificPointer        ituAlarmEntry.3.1
 alarmModelVarbindSubtree         ifIndex (1.3.6.1.2.1.2.2.1.1)
 alarmModelResourcePrefix         0.0
 alarmModelRowStatus              active (1)
 ituAlarmEventType                communicationsAlarm (2)
 ituAlarmPerceivedSeverity        cleared (1)
 ituAlarmGenericModel             alarmModelEntry.3.1

 alarmModelIndex                  3
 alarmModelState                  2
 alarmModelNotificationId         linkDown
 alarmModelVarbindIndex           2

Top      Up      ToC       Page 60 
 alarmModelVarbindValue           down (2)
 alarmModelDescription            "linkDown administratively"
 alarmModelSpecificPointer        ituAlarmEntry.3.6
 alarmModelVarbindSubtree         ifIndex (1.3.6.1.2.1.2.2.1.1)
 alarmModelResourcePrefix         0.0
 alarmModelRowStatus              active (1)
 ituAlarmEventType                communicationsAlarm (2)
 ituAlarmPerceivedSeverity        warning (6)
 ituAlarmGenericModel             alarmModelEntry.3.2

 alarmModelIndex                  3
 alarmModelState                  3
 alarmModelNotificationId         linkDown
 alarmModelVarbindIndex           2
 alarmModelVarbindValue           up (1)
 alarmModelDescription            "linkDown - confirmed problem"
 alarmModelSpecificPointer        ituAlarmEntry.3.3
 alarmModelVarbindSubtree         ifIndex (1.3.6.1.2.1.2.2.1.1)
 alarmModelResourcePrefix         0.0
 alarmModelRowStatus              active (1)
 ituAlarmEventType                communicationsAlarm (2)
 ituAlarmPerceivedSeverity        critical (3)
 ituAlarmGenericModel             alarmModelEntry.3.3

 alarmActiveIndex                 1
 alarmActiveDateAndTime           2342464573
 alarmActiveDateAndTime           DateAndTime,
 alarmActiveEngineID              SnmpEngineID,
 alarmActiveEngineAddressType     ipV4
 alarmActiveEngineAddress         10.10.10.10
 alarmActiveContextName           SnmpAdminString,
 alarmActiveVariables             3
 alarmActiveNotificationID        1.3.6.1.6.3.1.1.5.3
 alarmActiveResourceId            1.3.6.1.2.1.2.2.1.1.346
 alarmActiveLogPointer            0.0
 alarmActiveModelPointer          alarmModelEntry.3.3
 alarmActiveSpecificPointer       ituAlarmActiveEntry.1.3
 ituAlarmActiveTrendIndication    moreSevere (1)
 ituAlarmDetector                   0.0
 ituAlarmServiceProvider            0.0
 ituAlarmServiceUser                0.0

 alarmActiveVariableIndex                 1
 alarmActiveVariableID                    sysUpTime.0
 alarmActiveVariableValueType             timeTicks(3)
 alarmActiveVariableCounter32Val          0
 alarmActiveVariableUnsigned32Val         0
 alarmActiveVariableTimeTicksVal          46754

Top      Up      ToC       Page 61 
 alarmActiveVariableInteger32Val          0
 alarmActiveVariableOctetStringVal        ""
 alarmActiveVariableIpAddressVal          0
 alarmActiveVariableOidVal                0.0
 alarmActiveVariableCounter64Val          0
 alarmActiveVariableIndex                 2
 alarmActiveVariableID                    snmpTrapOID.0
 alarmActiveVariableValueType             objectId(7)
 alarmActiveVariableCounter32Val          0
 alarmActiveVariableUnsigned32Val         0
 alarmActiveVariableTimeTicksVal          0
 alarmActiveVariableInteger32Val          0
 alarmActiveVariableOctetStringVal        ""
 alarmActiveVariableIpAddressVal          0
 alarmActiveVariableOidVal                1.3.6.1.6.3.1.1.5.3
 alarmActiveVariableCounter64Val          0
 alarmActiveVariableIndex                 3
 alarmActiveVariableID                    ifIndex
 alarmActiveVariableValueType             integer32(4)
 alarmActiveVariableCounter32Val          0
 alarmActiveVariableUnsigned32Val         0
 alarmActiveVariableTimeTicksVal          0
 alarmActiveVariableInteger32Val          346
 alarmActiveVariableOctetStringVal        ""
 alarmActiveVariableIpAddressVal          0
 alarmActiveVariableOidVal                0.0
 alarmActiveVariableCounter64Val          0
 alarmActiveVariableIndex                 4
 alarmActiveVariableID                    ifAdminStatus
 alarmActiveVariableValueType             integer32(4)
 alarmActiveVariableCounter32Val          0
 alarmActiveVariableUnsigned32Val         0
 alarmActiveVariableTimeTicksVal          0
 alarmActiveVariableInteger32Val          up (1)
 alarmActiveVariableOctetStringVal        ""
 alarmActiveVariableIpAddressVal          0
 alarmActiveVariableOidVal                0.0
 alarmActiveVariableCounter64Val          0
 alarmActiveVariableIndex                 5
 alarmActiveVariableID                    ifOperStatus
 alarmActiveVariableValueType             integer32(4)
 alarmActiveVariableCounter32Val          0
 alarmActiveVariableUnsigned32Val         0
 alarmActiveVariableTimeTicksVal          0
 alarmActiveVariableInteger32Val          down(2)
 alarmActiveVariableOctetStringVal        ""
 alarmActiveVariableIpAddressVal          0
 alarmActiveVariableOidVal                0.0

Top      Up      ToC       Page 62 
 alarmActiveVariableCounter64Val          0
 alarmActiveVariableOpaqueVal

6.2.  Temperature Alarms Using Generic Notifications

   Consider a system able to detect four different temperature states
   for a widget - normal, minor, major, critical.  The system does not
   have any Notification definitions for these alarm states.  A
   temperature alarm can be modelled using the generic alarm
   Notifications of alarmClearState and alarmActive.

alarmModelIndex                  5
alarmModelState                  1
alarmModelNotificationId         alarmClearState
alarmModelVarbindIndex           2
alarmModelVarbindValue           cleared (1)
alarmModelDescription            "Acme Widget Temperature Normal"
alarmModelSpecificPointer        ituAlarmEntry.5.1
alarmModelVarbindSubtree         alarmActiveResourceId
alarmModelResourcePrefix         0.0
alarmModelRowStatus              active (1)
ituAlarmEventType                environmentalAlarm (6)
ituPerceivedSeverity             cleared (1)
ituAlarmGenericModel             alarmModelEntry.5.1

alarmModelIndex                  5
alarmModelState                  2
alarmModelNotificationId         alarmActiveState
alarmModelVarbindIndex           2
alarmModelVarbindValue           minor (5)
alarmModelDescription            "Acme Widget Temperature Minor"
alarmModelSpecificPointer        ituAlarmEntry.5.5
alarmModelVarbindSubtree         alarmActiveResourceId
alarmModelResourcePrefix         0.0
alarmModelRowStatus              active (1)
ituAlarmEventState               environmentalAlarm (6)
ituPerceivedSeverity             minor (5)
ituAlarmGenericModel             alarmModelEntry.5.2

alarmModelIndex                  5
alarmModelState                  3
alarmModelNotificationId         alarmActiveState
alarmModelVarbindIndex           2
alarmModelVarbindValue           major (4)
alarmModelDescription            "Acme Widget Temperature Major"
alarmModelSpecificPointer        ituAlarmEntry.5.4
alarmModelVarbindSubtree         alarmActiveResourceId
alarmModelResourcePrefix         0.0

Top      Up      ToC       Page 63 
alarmModelRowStatus              active (1)
ituAlarmEventType                environmentalAlarm (6)
ituPerceivedSeverity             major (4)
ituAlarmGenericModel             alarmModelEntry.5.3
alarmModelIndex                  5
alarmModelState                  4
alarmModelNotificationId         alarmActiveState
alarmModelVarbindIndex           2
alarmModelVarbindValue           critical (3)
alarmModelDescription            "Acme Widget Temperature Critical"
alarmModelSpecificPointer        ituAlarmEntry.5.3
alarmModelVarbindSubtree         alarmActiveResourceId
alarmModelResourcePrefix         0.0
alarmModelRowStatus              active (1)
ituAlarmEventType                environmentalAlarm (6)
ituPerceivedSeverity             critical (3)
ituAlarmGenericModel             alarmModelEntry.5.4

6.3.  Temperature Alarms Without Notifications

   Consider a system able to detect four different temperature states
   for a widget - normal, minor, major, critical.  The system does not
   have any Notification definitions for these alarm states.  A
   temperature alarm can be modelled without specifying any
   Notifications in the alarm model.  When a temperature state other
   than normal is detected, an instance of this alarm would be added to
   the active alarm table, but no Notifications would be sent out.

   This could alternatively be accomplished using the models from
   example 6.2 and by not specifying any target managers in the SNMP-
   TARGET-MIB, which would allow the alarm state Notifications to be
   logged in the Notification Log while still preventing Notifications
   from being transmitted on the wire.

alarmModelIndex                  6
alarmModelState                  1
alarmModelNotificationId         0.0
alarmModelVarbindIndex           0
alarmModelVarbindValue           0
alarmModelDescription            "Widget Temperature"
alarmModelSpecificPointer        ituAlarmEntry.6.1
alarmModelVarbindSubtree         0.0
alarmModelResourcePrefix         0.0
alarmModelRowStatus              active (1)
ituAlarmEventType                environmentalAlarm (6)
ituPerceivedSeverity             cleared (1)
ituAlarmGenericModel             alarmModelEntry.6.1

Top      Up      ToC       Page 64 
alarmModelIndex                  6
alarmModelState                  2
alarmModelNotificationId         0.0
alarmModelVarbindIndex           0
alarmModelVarbindValue           0
alarmModelDescription            "Widget Temperature"
alarmModelSpecificPointer        ituAlarmEntry.6.5
alarmModelVarbindSubtree         0.0
alarmModelResourcePrefix         0.0
alarmModelRowStatus              active (1)
ituAlarmEventState               environmentalAlarm (6)
ituAlarmPerceivedSeverity        minor (5)
ituAlarmGenericModel             alarmModelEntry.6.2

alarmModelIndex                  6
alarmModelState                  3
alarmModelNotificationId         0.0
alarmModelVarbindIndex           0
alarmModelVarbindValue           0
alarmModelDescription            "Widget Temperature"
alarmModelSpecificPointer        ituAlarmEntry.6.4
alarmModelVarbindSubtree         0.0
alarmModelResourcePrefix         0.0
alarmModelRowStatus              active (1)
ituAlarmEventType                environmentalAlarm (6)
ituPerceivedSeverity             major (4)
ituAlarmGenericModel             alarmModelEntry.6.3

alarmModelIndex                  6
alarmModelState                  4
alarmModelNotificationId         0.0
alarmModelVarbindIndex           0
alarmModelVarbindValue           0
alarmModelDescription            "Widget Temperature Severe"
alarmModelSpecificPointer        ituAlarmEntry.6.3
alarmModelVarbindSubtree         0.0
alarmModelResourcePrefix         0.0
alarmModelRowStatus              active (1)
ituAlarmEventType                environmentalAlarm (6)
ituPerceivedSeverity             critical (3)
ituAlarmGenericModel             alarmModelEntry.6.4

Top      Up      ToC       Page 65 
6.4.  Printer MIB Alarm Example

   Consider the following Notifications defined in the
   printer MIB [RFC3805]:

   prtAlertSeverityLevel OBJECT-TYPE
    -- This value is a type 1 enumeration
    SYNTAX     INTEGER {
                 other(1),
                 critical(3),
                 warning(4)
             }
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION
      "The level of severity of this alert table entry.  The printer
      determines the severity level assigned to each entry into the
      table."
    ::= { prtAlertEntry 2 }

   printerV2Alert NOTIFICATION-TYPE
    OBJECTS { prtAlertIndex, prtAlertSeverityLevel, prtAlertGroup,
            prtAlertGroupIndex, prtAlertLocation, prtAlertCode }
    STATUS  current
    DESCRIPTION
      "This trap is sent whenever a critical event is added to the
      prtAlertTable."
    ::= { printerV2AlertPrefix 1 }

   These Notifications can be used to model a printer alarm as follows:

   alarmModelIndex                  9 alarmModelState                  1
   alarmModelNotificationId         alarmClearState
   alarmModelVarbindIndex           0 alarmModelVarbindValue           0
   alarmModelDescription            "Printer Alarm"
   alarmModelSpecificPointer        0.0 alarmModelVarbindSubtree
   prtAlertGroup alarmModelResourcePrefix         0.0
   alarmModelRowStatus              active (1)

   alarmModelIndex                  9 alarmModelState                  2
   alarmModelNotificationId         printerV2Alert
   alarmModelVarbindIndex           2 alarmModelVarbindValue
   warning (4) alarmModelDescription            "Printer Alarm"
   alarmModelSpecificPointer        0.0 alarmModelVarbindSubtree
   prtAlertGroup alarmModelResourcePrefix         0.0
   alarmModelRowStatus              active (1)

   alarmModelIndex                  9 alarmModelState                  3

Top      Up      ToC       Page 66 
   alarmModelNotificationId         printerV2Alert
   alarmModelVarbindIndex           2 alarmModelVarbindValue
   other (1) alarmModelDescription            "Printer Alarm - unknown
   severity" alarmModelSpecificPointer        0.0
   alarmModelVarbindSubtree         prtAlertGroup
   alarmModelResourcePrefix         0.0 alarmModelRowStatus
   active (1)

   alarmModelIndex                  9 alarmModelState                  4
   alarmModelNotificationId         printerV2Alert
   alarmModelVarbindIndex           2 alarmModelVarbindValue
   critical (3) alarmModelDescription            "Printer Alarm"
   alarmModelSpecificPointer        0.0 alarmModelVarbindSubtree
   prtAlertGroup alarmModelResourcePrefix         0.0
   alarmModelRowStatus              active (1)

6.5.  RMON Alarm Example

   The RMON MIB [RFC2819] defines a mechanism for generating threshold
   alarms.  When the thresholds are crossed, RisingAlarm and
   FallingAlarm Notifications are generated as appropriate.  These
   Notifications can be used to model an upper threshold alarm as
   follows:

   alarmModelIndex                  6
   alarmModelState                  1
   alarmModelNotificationId         FallingAlarm
   alarmModelVarbindIndex           0
   alarmModelVarbindValue           0
   alarmModelDescription            "RMON Rising Clear Alarm"
   alarmModelSpecificPointer        0.0
   alarmModelVarbindSubtree         alarmIndex
   alarmModelResourcePrefix         0.0
   alarmModelRowStatus              active (1)

   alarmModelIndex                  6
   alarmModelState                  2
   alarmModelNotificationId         RisingAlarm
   alarmModelVarbindIndex           0
   alarmModelVarbindValue           0
   alarmModelDescription            "RMON Rising Alarm"
   alarmModelSpecificPointer        0.0
   alarmModelVarbindSubtree         alarmIndex
   alarmModelResourcePrefix         0.0
   alarmModelRowStatus              active (1)

Top      Up      ToC       Page 67 
6.6.  The Lifetime of an Alarm

   The following example demonstrates the relationship between the
   active alarm table, the clear alarm table and the Notification Log
   MIB.

   Consider a system with alarms modelled as in example 1 and which also
   supports the informational Notification dsx3LineStatusChange.

dsx3LineStatusChange NOTIFICATION-TYPE
    OBJECTS { dsx3LineStatus,
              dsx3LineStatusLastChange }
    STATUS  current
    DESCRIPTION
            "A dsx3LineStatusChange trap is sent when the
            value of an instance of dsx3LineStatus changes.  It
            can be utilized by an NMS to trigger polls.  When
            the line status change results in a lower level
            line status change (i.e., ds1), then no traps for
            the lower level are sent."
               ::= { ds3Traps 0 1 }

0. At system start, the active alarm table, alarm clear table and
   the Notification Log are all empty.
         ___________________________     _______________________
        | alarmActiveTable          |   | nlmLogTable           |
        |---------------------------|   |-----------------------|
        | alarmActiveIndex |  alarm |   | nlmLogPointer | notif.|
        |---------------------------|   |-----------------------|
        |___________________________|   |_______________________|

         __________________________________________________
        | alarmClearTable                                  |
        |--------------------------------------------------|
        | alarmClear Index |  alarm                        |
        |--------------------------------------------------|
        |                  |                               |
        |__________________________________________________|

Top      Up      ToC       Page 68 
1. Some time later, a link goes down generating a linkDown
   Notification, which is sent out and logged in the
   Notification Log.  As this Notification is modelled as
   an alarm state, an entry is added to the active alarm
   table.
         __________________________________________________
        | alarmActiveTable                                 |
        |--------------------------------------------------|
        | alarmActiveIndex |  alarm                        |
        |--------------------------------------------------|
        |        1         | link down - problem confirmed |
        |__________________________________________________|

         _______________________________________________
        | nlmLogTable                                   |
        |-----------------------------------------------|
        | nlmLogPointer |  Notification                 |
        |-----------------------------------------------|
        |      1        | linkdown                      |
        |_______________________________________________|

         __________________________________________________
        | alarmClearTable                                  |
        |--------------------------------------------------|
        | alarmClear Index |  alarm                        |
        |--------------------------------------------------|
        |                  |                               |
        |__________________________________________________|

Top      Up      ToC       Page 69 
2. Some time later, the value of an instance of dsx3LineStatus
   changes.  This Notification is sent out and logged.  As this
   is not modelled into an alarm state, the active alarm table
   remains unchanged.
         __________________________________________________
        | alarmActiveTable                                 |
        |--------------------------------------------------|
        | alarmActiveIndex |  alarm                        |
        |--------------------------------------------------|
        |        1         | linkDown - problem confirmed  |
        |__________________________________________________|

         _____________________________________________
        | nlmLogTable                                 |
        |---------------------------------------------|
        | nlmLogPointer |  Notification               |
        |---------------------------------------------|
        |      1        | linkDown                    |
        |      2        | dsx3LineStatusChange        |
        |_____________________________________________|

         __________________________________________________
        | alarmClearTable                                  |
        |--------------------------------------------------|
        | alarmClear Index |  alarm                        |
        |--------------------------------------------------|
        |                  |                               |
        |__________________________________________________|

Top      Up      ToC       Page 70 
3. Some time later, the link goes back up.  A linkUp Notification
   is sent out and logged.  As this Notification models
   the clear alarm for this alarm, the alarm entry is remove
   from the active alarm table.  An entry is added to the
   clear alarm table.
         __________________________________________________
        | alarmActiveTable                                 |
        |--------------------------------------------------|
        | alarmActiveIndex |  alarm                        |
        |--------------------------------------------------|
        |__________________________________________________|

         _____________________________________________
        | nlmLogTable                                 |
        |---------------------------------------------|
        | nlmLogPointer |  Notification               |
        |---------------------------------------------|
        |      1      | linkDown                      |
        |      2      | dsx3LineStatusChange          |
        |      3      | linkUp                        |
        |_____________________________________________|

         __________________________________________________
        | alarmClearTable                                  |
        |--------------------------------------------------|
        | alarmClear Index |  alarm                        |
        |--------------------------------------------------|
        |      1           | linkDown - confirmed problem  |
        |__________________________________________________|

7.  Security Considerations

   There are a number of management objects defined in this MIB module
   with a MAX-ACCESS clause of read-write and/or read-create.  Such
   objects may be considered sensitive or vulnerable in some network
   environments.  The support for SET operations in a non-secure
   environment without proper protection can have a negative effect on
   network operations.

   The following objects are defined with a MAX-ACCESS clause of read-
   write or read-create: alarmModelNotificationId,
   alarmModelVarbindIndex, alarmModelVarbindValue,
   alarmModelDescription, alarmModelSpecificPointer,
   alarmModelVarbindSubtree, alarmModelResourcePrefix,
   alarmModelRowStatus, alarmClearMaximum, ituAlarmEventType,
   ituAlarmProbableCause, ituAlarmAdditionalText, and
   ituAlarmGenericModel.

Top      Up      ToC       Page 71 
   Note that setting the value of alarmClearMaximum too low may result
   in security related alarms history being prematurely lost.

   Changing values of alarmModelRowStatus as part of creating and
   deleting rows in the alarmModelTable result in adding new alarm
   models to the system or taking them out respectively.  These
   operations need to be carefully planned.  Adding a new model should
   be made in a consistent manner to avoid the system overflow with
   alarms.  Taking out a model should result in the deletion of all this
   model's related alarms in the system.

   SNMP versions prior to SNMPv3 did not include adequate security.
   Even if the network itself is secure (for example by using IPSec),
   even then, there is no control as to who on the secure network is
   allowed to access and GET/SET (read/change/create/delete) the objects
   in this MIB module.

   It is RECOMMENDED that implementers consider the security features as
   provided by the SNMPv3 framework (see [RFC3410], section 8),
   including full support for the SNMPv3 cryptographic mechanisms (for
   authentication and privacy).

   Further, deployment of SNMP versions prior to SNMPv3 is NOT
   RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
   enable cryptographic security.  It is then a customer/operator
   responsibility to ensure that the SNMP entity giving access to an
   instance of this MIB module is properly configured to give access to
   the objects only to those principals (users) that have legitimate
   rights to indeed GET or SET (change/create/delete) them.

   Note that the alarm throttling mechanism associated with the
   alarmActiveState and alarmActiveClear notifications only applies to a
   given alarm.  Defining multiple alarms from the same internal
   stimulus may then still result in a flood of alarms into the network.

   Although the use of community strings in SNMPv1 is not considered an
   effective means of providing security, security administrators SHOULD
   consider whether the fact that alarmActiveContextName can reveal
   community string values would make this object sensitive in their
   environment.

   This MIB module can provide access to information that may also be
   accessed through manipulation of the SNMP-NOTIFICATION-MIB and the
   NOTIFICATION-LOG-MIB.  This is expressed in part through the common
   indexing structure of nlmLogName [RFC3014],
   snmpNotifyFilterProfileName [RFC3413], and alarmListName.
   Consequently, it is RECOMMENDED that security administrators take
   care to configure a coherent VACM security policy.  The objects

Top      Up      ToC       Page 72 
   alarmActiveLogPointer, alarmActiveModelPointer,
   alarmActiveSpecificPointer,  and alarmClearModelPointer are object
   identifiers that reference information to which a particular user
   might not be given direct access.  The structure of these object
   identifiers does not permit the extraction of any sensitive
   information.  Two other objects, alarmClearResourceId, and
   alarmActiveResourceId, are also syntactically object identifiers, but
   their structure could provide a user with potentially useful
   information to which he or she might not otherwise be granted access,
   such as the existence of a particular resource.

   For further discussion of security, see section 3.4.

8.  Acknowledgements

   This document is a product of the DISMAN Working Group.

9. References

9.1.  Normative References

   [M.3100]    ITU Recommendation M.3100, "Generic Network Information
               Model", 1995

   [RFC1157]   Case, J., Fedor, M., Schoffstall, M. and J. Davin,
               "Simple Network Management Protocol (SNMP)", STD 15, RFC
               1157, May 1990.

   [RFC1215]   Rose, M., "A Convention for defining traps for use with
               the SNMP", RFC 1215, March 1991.

   [RFC2021]   Waldbusser, S., "Remote Network Monitoring Management
               Information Base Version 2 using SMIv2", January 1997.

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2578]   McCloghrie, K., Perkins, D. and J. Schoenwaelder,
               "Structure of Management Information Version 2 (SMIv2)",
               STD 58, RFC 2578, April 1999.

   [RFC2579]   McCloghrie, K., Perkins, D. and J. Schoenwaelder,
               "Textual Conventions for SMIv2", STD 58, RFC 2579, April
               1999.

   [RFC2580]   McCloghrie, K., Perkins, D. and J. Schoenwaelder,
               "Conformance Statements for SMIv2", STD 58, RFC 2580,
               April 1999.

Top      Up      ToC       Page 73 
   [RFC3291]   Daniele, M., Haberman, B., Routhier, S. and J.
               Schoenwaelder, "Textual Conventions for Internet Network
               Addresses", RFC 3291, May 2002.

   [RFC3411]   Harrington, D., Presuhn, R. and B. Wijnen, "An
               Architecture for Describing Simple Network Management
               Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
               December 2002.

   [RFC3413]   Levi, D., Meyer, P. and B. Stewart, "Simple Network
               Management Protocol (SNMP) Applications", STD 62, RFC
               3414, December 2002.

   [RFC3415]   Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
               Access Control Model (VACM) for the Simple Network
               Management Protocol (SNMP)", STD 62, RFC 3415, December
               2002.

   [RFC3416]   Presuhn, R., Ed., "Version 2 of the Protocol Operations
               for the Simple Network Management Protocol (SNMP)", STD
               62, RFC 3416, December 2002.

   [RFC3584]   Frye, R., Levi, D., Routhier, S. and B. Wijnen,
               "Coexistence between Version 1, Version 2, and Version 3
               of the Internet-standard Network Management Framework",
               BCP 74, RFC 3584, August 2003.

   [X.733]     ITU Recommendation X.733, "Information Technology - Open
               Systems Interconnection - System Management: Alarm
               Reporting Function", 1992.

   [X.736]     ITU Recommendation X.736, "Information Technology - Open
               Systems Interconnection - System Management: Security
               Alarm Reporting Function", 1992.

9.2 Informative References

   [RFC1657]   Willis, S., Burruss, J. and J. Chu, Ed., "Definitions of
               Managed Objects for the Fourth Version of the Border
               Gateway Protocol (BGP-4) using SMIv2", RFC 1657, July
               1994.

   [RFC2737]   McCloghrie, K. and A. Bierman, "Entity MIB (version 2)",
               RFC 2737, December 1999.

   [RFC2819]   Waldbusser, S. "Remote Network Monitoring Management
               Information Base", STD 59, RFC 2819, May 2000.

Top      Up      ToC       Page 74 
   [RFC2863]   McCloghrie, K. and F. Kastenholz, "The Interfaces Group
               MIB using SMIv2", RFC 2863, June 2000.

   [RFC2981]   Kavasseri, R., Ed., "Event MIB", RFC 2981, October 2000.

   [RFC3014]   Kavasseri, R., "Notification Log MIB", RFC 3014, November
               2000.

   [RFC3410]   Case, J., Mundy, R., Partain, D. and B. Stewart,
               "Introduction and Applicability Statements for Internet-
               Standard Management Framework", RFC 3410, December 2002.

   [RFC3418]   Presuhn, R., Ed., "Management Information Base (MIB) for
               the Simple Network Management Protocol (SNMP)", STD 62,
               RFC 3418, December 2002.

   [RFC3805]   Bergman, R., Lewis, H. and I. McDonald, "Printer MIB v2",
               RFC 3805, June 2004.

10.  Authors' Addresses

   Sharon Chisholm
   Nortel Networks
   PO Box 3511, Station C
   Ottawa, Ontario, K1Y 4H7
   Canada

   EMail: schishol@nortelnetworks.com


   Dan Romascanu
   Avaya
   Atidim Technology Park, Bldg. #3
   Tel Aviv, 61131
   Israel

   Phone: +972-3-645-8414
   EMail: dromasca@avaya.com

Top      Up      ToC       Page 75 
11.  Full Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.