RFC 3877
Alarm Management Information Base (MIB)
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
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
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
alarmActiveVariableCounter64Val 0 alarmActiveVariableOpaqueVal6.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
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.46.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
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
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
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)
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 | |--------------------------------------------------| | | | |__________________________________________________|
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 |
|--------------------------------------------------|
| | |
|__________________________________________________|
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 |
|--------------------------------------------------|
| | |
|__________________________________________________|
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.
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
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.
[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.
[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
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.