Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3877

Alarm Management Information Base (MIB)

Pages: 75
Proposed Standard
Errata
Part 4 of 4 – Pages 59 to 75
First   Prev   None

Top   ToC   RFC3877 - Page 59   prevText

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   ToC   RFC3877 - 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   ToC   RFC3877 - 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   ToC   RFC3877 - 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   ToC   RFC3877 - 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   ToC   RFC3877 - 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   ToC   RFC3877 - 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   ToC   RFC3877 - 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   ToC   RFC3877 - 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   ToC   RFC3877 - 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   ToC   RFC3877 - 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   ToC   RFC3877 - 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   ToC   RFC3877 - 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   ToC   RFC3877 - 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   ToC   RFC3877 - 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   ToC   RFC3877 - 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   ToC   RFC3877 - 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.