Internet Draft Andy Bierman Cisco Systems, Inc. Dan Romascanu Avaya Communication K.C. Norseth 15 August 2002 Entity Sensor Management Information Base Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this document is unlimited. Please send comments to authors. 1. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Internet Draft Entity Sensor MIB August 15, 2002 2. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for extending the Entity MIB (RFC2737) to provide generalized access to information related to physical sensors, which are often found in networking equipment (such as chassis temperature, fan RPM, power supply voltage). 3. Table of Contents 1 Copyright Notice ................................................ 1 2 Abstract ........................................................ 2 3 Table of Contents ............................................... 2 4 The SNMP Network Management Framework ........................... 2 5 Overview ........................................................ 3 5.1 Terms ......................................................... 4 5.2 Relationship to the Entity MIB ................................ 4 5.3 Relationship to General Thresholding Mechanisms ............... 4 6 MIB Structure ................................................... 4 7 Definitions ..................................................... 5 8 Intellectual Property ........................................... 16 9 Acknowledgements ................................................ 16 10 Normative References ........................................... 16 11 Informative References ......................................... 18 12 Security Considerations ........................................ 19 13 Authors' Addresses ............................................. 19 14 Full Copyright Statement ....................................... 20 4. The SNMP Network Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in RFC 1155 [RFC1155], RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in RFC 2578 [RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and Expires February 2003 [Page 2] Internet Draft Entity Sensor MIB August 15, 2002 described in RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 5. Overview There is a need for a standardized way of obtaining information related to the physical sensors which are commonly found in networking equipment. Information such as the current value of the sensor, the current operational status, and the data units precision associated with the sensor, should be represented in a consistent manner for any type of sensor. Physical sensors are represented in the Entity MIB with entPhysicalEntry and an entPhysicalClass value of 'sensor(8)'. The information provided Expires February 2003 [Page 3] Internet Draft Entity Sensor MIB August 15, 2002 in the ENTITY-SENSOR-MIB module (defined in this document) defines a sparse augmentation of the entPhysicalTable, for entries which represent physical sensors. 5.1. Terms The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. [RFC2119] 5.2. Relationship to the Entity MIB The MIB objects defined in this document provide a sparse augmentation to the entPhysicalTable in the Entity MIB, for entries for which the associated entPhysicalClass object is equal to 'sensor(8)'. An agent is expected to maintain an entSensorEntry with the same entPhysicalIndex value for each entPhysicalEntry representing a physical sensor. Therefore, implementation of the entityPhysicalGroup is required for agents which implement the Entity Sensor MIB. 5.3. Relationship to General Thresholding Mechanisms There are no specialized sensor value thresholding mechanisms defined in this MIB module. Instead, it is recommended that a generalized thresholding MIB, such as the mechanisms defined by the Alarm and Events groups of the Remote Network Monitoring MIB [RFC2819], be used for this purpose. 6. MIB Structure The Entity Sensor MIB contains a single group called the entitySensorValueGroup, which provides objects to convey the current value and status of a physical sensor. The entitySensorValueGroup contains a single table, called the entSensorTable, which provides a small number of read-only objects: entSensorType This object identifies the type of data units associated with the sensor value. entSensorScale This object identifies the (power of 10) scaling factor associated with the sensor value. Expires February 2003 [Page 4] Internet Draft Entity Sensor MIB August 15, 2002 entSensorPrecision This object identifies the number of decimal places of precision associated with the sensor value. entSensorValue This object identifies the current value of the sensor. entSensorOperStatus This object identifies the current operational status of the sensor (as it's known to the agent). entSensorUnitsDisplay This object provides a textual description of the data units represented by the entSensorType and entSensorScale objects. entSensorValueTimeStamp The object identifies the value of sysUpTime at the time the agent last updated the information in the entry. This object is only relevant if the agent uses a polling implementation strategy, (i.e., the associated entSensorValueUpdateRate object is greater than zero). entSensorValueUpdateRate This object indicates the nature of the agent implementation of the entSensorEntry, and contains the (possibly estimated) number of milliseconds that elapse between polling updates of the information in the associated entry. The value zero indicates that the agent always return current data for the entry (as opposed to the data as it was at the last polling interval). 7. Definitions ENTITY-SENSOR-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32, mib-2 FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF TEXTUAL-CONVENTION, TimeStamp FROM SNMPv2-TC entPhysicalIndex, entityPhysicalGroup FROM ENTITY-MIB SnmpAdminString Expires February 2003 [Page 5] Internet Draft Entity Sensor MIB August 15, 2002 FROM SNMP-FRAMEWORK-MIB; entitySensorMIB MODULE-IDENTITY LAST-UPDATED "200208150000Z" ORGANIZATION "IETF Entity MIB Working Group" CONTACT-INFO " Andy Bierman Cisco Systems, Inc. Tel: +1 408-527-3711 E-mail: abierman@cisco.com Postal: 170 West Tasman Drive San Jose, CA USA 95134 Dan Romascanu Avaya Communication Tel: +972-3-645-8414 Email: dromasca@avaya.com Postal: Atidim technology Park, Bldg. #3 Tel Aviv, Israel, 61131 K.C. Norseth Consultant Tel: +1 801-546-3316 Email: kcn@norseth.com Postal: 934 S. Palos Verdes Dr. Kaysville, Utah 84037 Send comments to Mailing list subscription info: http://www.ietf.org/mailman/listinfo/entmib " DESCRIPTION "This module defines Entity MIB extensions for physical sensors." REVISION "200208150000Z" DESCRIPTION "Initial version of the Entity Sensor MIB module, published as RFC xxxx." -- RFC Editor assigns xxxx ::= { mib-2 xxx } -- IANA needs to assign xxx entitySensorObjects OBJECT IDENTIFIER ::= { entitySensorMIB 1 } -- entitySensorNotifications OBJECT IDENTIFIER -- ::= { entitySensorMIB 2 } entitySensorConformance OBJECT IDENTIFIER ::= { entitySensorMIB 3 } Expires February 2003 [Page 6] Internet Draft Entity Sensor MIB August 15, 2002 -- -- Textual Conventions -- EntitySensorDataType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An object using this data type represents the Entity Sensor measurement data type associated with a physical sensor value. The actual data units are determined by examining an object of this type together with the associated EntitySensorDataScale object. An object of this type SHOULD be defined together with objects of type EntitySensorDataScale and EntitySensorPrecision. Together, associated objects of these three types are used to identify the semantics of an object of type EntitySensorValue. Valid values are: other(1): a measure other than those listed below unknown(2): unknown measurement, or arbitrary, relative numbers voltsAC(3): electric potential voltsDC(4): electric potential amperes(5): electric current watts(6): power hertz(7): frequency celsius(8): temperature percentRH(9): percent relative humidity rpm(10): shaft revolutions per minute cmm(11),: cubic meters per minute (airflow) truthvalue(12): value takes { true(1), false(2) } " SYNTAX INTEGER { other(1), unknown(2), voltsAC(3), voltsDC(4), amperes(5), watts(6), hertz(7), celsius(8), Expires February 2003 [Page 7] Internet Draft Entity Sensor MIB August 15, 2002 percentRH(9), rpm(10), cmm(11), truthvalue(12) } EntitySensorDataScale ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An object using this data type represents a data scaling factor, represented with an International System of Units (SI) prefix. The actual data units are determined by examining an object of this type together with the associated EntitySensorDataType object. An object of this type SHOULD be defined together with objects of type EntitySensorDataType and EntitySensorPrecision. Together, associated objects of these three types are used to identify the semantics of an object of type EntitySensorValue." REFERENCE "TBD" SYNTAX INTEGER { yocto(1), -- 10^-24 zepto(2), -- 10^-21 atto(3), -- 10^-18 femto(4), -- 10^-15 pico(5), -- 10^-12 nano(6), -- 10^-9 micro(7), -- 10^-6 milli(8), -- 10^-3 units(9), -- 10^0 kilo(10), -- 10^3 mega(11), -- 10^6 giga(12), -- 10^9 tera(13), -- 10^12 exa(14), -- 10^15 peta(15), -- 10^18 zetta(16), -- 10^21 yotta(17) -- 10^24 } EntitySensorPrecision ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION Expires February 2003 [Page 8] Internet Draft Entity Sensor MIB August 15, 2002 "An object using this data type represents a sensor precision range. An object of this type SHOULD be defined together with objects of type EntitySensorDataType and EntitySensorDataScale. Together, associated objects of these three types are used to identify the semantics of an object of type EntitySensorValue. If an object of this type contains a value in the range 1 to 9, it represents the number of decimal places in the fractional part of an associated EntitySensorValue fixed- point number. If an object of this type contains a value in the range -8 to -1, it represents the number of accurate digits in the associated EntitySensorValue fixed-point number. The value zero indicates the associated EntitySensorValue object is not a fixed-point number. Agent implementors must choose a value for the associated EntitySensorPrecision object so that the precision and accuracy of the associated EntitySensorValue object is correctly indicated. For example, a physical entity representing a temperature sensor that can measure 0 degrees to 100 degrees C in 0.1 degree increments, +/- 0.05 degrees, would have an EntitySensorPrecision value of '1', an EntitySensorDataScale value of 'units(9)', and an EntitySensorValue ranging from '0' to '1000'. The EntitySensorValue would be interpreted as 'degrees C * 10'." SYNTAX Integer32 (-8..9) EntitySensorValue ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An object using this data type represents an Entity Sensor value. An object of this type SHOULD be defined together with objects of type EntitySensorDataType, EntitySensorDataScale and EntitySensorPrecision. Together, associated objects of those three types are used to identify the semantics of an Expires February 2003 [Page 9] Internet Draft Entity Sensor MIB August 15, 2002 object of this data type. The semantics of an object using this data type are determined by the value of the associated EntitySensorDataType object. If the associated EntitySensorDataType object is equal to 'voltsAC(3)', 'voltsDC(4)', 'amperes(5)', 'watts(6), 'hertz(7)', 'celsius(8)', or 'cmm(11)', then an object of this type MUST contain a fixed point number ranging from -999,999,999 to +999,999,999. The value -1000000000 indicates an underflow error. The value +1000000000 indicates an overflow error. The EntitySensorPrecision indicates how many fractional digits are represented in the associated EntitySensorValue object. If the associated EntitySensorDataType object is equal to 'percentRH(9)', then an object of this type MUST contain a number ranging from 0 to 100. If the associated EntitySensorDataType object is equal to 'rpm(10)', then an object of this type MUST contain a number ranging from -999,999,999 to +999,999,999. If the associated EntitySensorDataType object is equal to 'truthvalue(12)', then an object of this type MUST contain either the value 'true(1)' or the value 'false(2)'. If the associated EntitySensorDataType object is equal to 'other(1)' or unknown(2)', then an object of this type MUST contain a number ranging from -1000000000 to 1000000000." SYNTAX Integer32 (-1000000000..1000000000) EntitySensorStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An object using this data type represents the operational status of a physical sensor. The value 'ok(1)' indicates that the agent can obtain the sensor value. The value 'unavailable(2)' indicates that the agent presently cannot obtain the sensor value. Expires February 2003 [Page 10] Internet Draft Entity Sensor MIB August 15, 2002 The value 'nonoperational(3)' indicates that the agent believes the sensor is broken. The sensor could have a hard failure (disconnected wire), or a soft failure such as out- of-range, jittery, or wildly fluctuating readings." SYNTAX INTEGER { ok(1), unavailable(2), nonoperational(3) } -- -- Entity Sensor Table -- entSensorTable OBJECT-TYPE SYNTAX SEQUENCE OF EntSensorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains one row per physical sensor represented by an associated row in the entPhysicalTable." ::= { entitySensorObjects 1 } entSensorEntry OBJECT-TYPE SYNTAX EntSensorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular physical sensor. An entry in this table describes the present reading of a sensor, the measurement units and scale, and sensor operational status. Entries are created in this table by the agent. An entry for each physical sensor SHOULD be created at the same time as the associated entPhysicalEntry. An entry SHOULD be destroyed if the associated entPhysicalEntry is destroyed." INDEX { entPhysicalIndex } -- SPARSE-AUGMENTS ::= { entSensorTable 1 } EntSensorEntry ::= SEQUENCE { entSensorType EntitySensorDataType, entSensorScale EntitySensorDataScale, entSensorPrecision EntitySensorPrecision, Expires February 2003 [Page 11] Internet Draft Entity Sensor MIB August 15, 2002 entSensorValue EntitySensorValue, entSensorOperStatus EntitySensorStatus, entSensorUnitsDisplay SnmpAdminString, entSensorValueTimeStamp TimeStamp, entSensorValueUpdateRate Unsigned32 } entSensorType OBJECT-TYPE SYNTAX EntitySensorDataType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of data returned by the associated entSensorValue object. This object SHOULD be set by the agent during entry creation, and the value SHOULD NOT change during operation." ::= { entSensorEntry 1 } entSensorScale OBJECT-TYPE SYNTAX EntitySensorDataScale MAX-ACCESS read-only STATUS current DESCRIPTION "The exponent to apply to values returned by the associated entSensorValue object. This object SHOULD be set by the agent during entry creation, and the value SHOULD NOT change during operation." ::= { entSensorEntry 2 } entSensorPrecision OBJECT-TYPE SYNTAX EntitySensorPrecision MAX-ACCESS read-only STATUS current DESCRIPTION "The number of decimal places of precision in fixed-point sensor values returned by the associated entSensorValue object. This object SHOULD be set to '0' when the associated entSensorType value is not a fixed-point type: e.g., 'percentRH(9)', 'rpm(10)', 'cmm(11)', or 'truthvalue(12)'. This object SHOULD be set by the agent during entry Expires February 2003 [Page 12] Internet Draft Entity Sensor MIB August 15, 2002 creation, and the value SHOULD NOT change during operation." ::= { entSensorEntry 3 } entSensorValue OBJECT-TYPE SYNTAX EntitySensorValue MAX-ACCESS read-only STATUS current DESCRIPTION "The most recent measurement obtained by the agent for this sensor. To correctly interpret the value of this object, the associated entSensorType, entSensorScale, and entSensorPrecision objects must also be examined." ::= { entSensorEntry 4 } entSensorOperStatus OBJECT-TYPE SYNTAX EntitySensorStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The operational status of the sensor." ::= { entSensorEntry 5 } entSensorUnitsDisplay OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A textual description of the data units that should be used in the display of entSensorValue." ::= { entSensorEntry 6 } entSensorValueTimeStamp OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time the status and/or value of this sensor was last obtained by the agent." ::= { entSensorEntry 7 } entSensorValueUpdateRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" Expires February 2003 [Page 13] Internet Draft Entity Sensor MIB August 15, 2002 MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of the frequency that the agent updates the associated entSensorValue object, representing in milliseconds. The value zero indicates: - the sensor value is updated on demand (e.g., when polled by the agent for a get-request), - the sensor value is updated when the sensor value changes (event-driven), - the agent does not know the update rate. " ::= { entSensorEntry 8 } -- -- Conformance Section -- entitySensorCompliances OBJECT IDENTIFIER ::= { entitySensorConformance 1 } entitySensorGroups OBJECT IDENTIFIER ::= { entitySensorConformance 2 } entitySensorCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Describes the requirements for conformance to the Entity Sensor MIB module." MODULE -- this module MANDATORY-GROUPS { entitySensorValueGroup } MODULE ENTITY-MIB MANDATORY-GROUPS { entityPhysicalGroup } ::= { entitySensorCompliances 1 } -- Object Groups entitySensorValueGroup OBJECT-GROUP OBJECTS { entSensorType, Expires February 2003 [Page 14] Internet Draft Entity Sensor MIB August 15, 2002 entSensorScale, entSensorPrecision, entSensorValue, entSensorOperStatus, entSensorUnitsDisplay, entSensorValueTimeStamp, entSensorValueUpdateRate } STATUS current DESCRIPTION "A collection of objects representing physical entity sensor information." ::= { entitySensorGroups 1 } END Expires February 2003 [Page 15] Internet Draft Entity Sensor MIB August 15, 2002 8. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 9. Acknowledgements This memo is a product of the Entity MIB working group. It is based on an existing proprietary MIB module written by Cliff Sojourner. 10. Normative References [RFC1905] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [RFC1906] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Expires February 2003 [Page 16] Internet Draft Entity Sensor MIB August 15, 2002 Levels" RFC 2119, Harvard University, March 1997. [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, Cabletron Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, April 1999. [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, SNMP Research, Inc., Cabletron Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, April 1999. [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2573, SNMP Research, Inc., Secure Computing Corporation, Cisco Systems, April 1999. [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, IBM T. J. Watson Research, April 1999. [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, IBM T. J. Watson Research, BMC Software, Inc., Cisco Systems, Inc., April 1999. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", RFC 2578, STD 58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, First Virtual Holdings, International Network Services, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", RFC 2579, STD 58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, First Virtual Holdings, International Network Services, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., Expires February 2003 [Page 17] Internet Draft Entity Sensor MIB August 15, 2002 and S. Waldbusser, "Conformance Statements for SMIv2", RFC 2580, STD 58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, First Virtual Holdings, International Network Services, April 1999. [RFC2737] McCloghrie, K., and A. Bierman, "Entity MIB (Version 2)", RFC 2737, Cisco Systems, Inc., December 1999. 11. Informative References [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990. [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991. [RFC1215] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, Performance Systems International, March 1991. [RFC1901] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, SNMP Research, Inc., TIS Labs at Network Associates, Inc., Ericsson, Cisco Systems, April 1999. [RFC2819] S. Waldbusser, "Remote network Monitoring Management Information Base", RFC 2819, Lucent Technologies, May 2000. Expires February 2003 [Page 18] Internet Draft Entity Sensor MIB August 15, 2002 12. Security Considerations There is one managed object in this MIB that may contain sensitive information. This is: entSensorValue This object may expose the values of particular physical sensors for a device. SNMPv1 by itself is not a secure environment. 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. It is recommended that the implementors consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User- based Security Model RFC 2574 [RFC2574] and the View-based Access Control Model RFC 2575 [RFC2575] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, 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. 13. Authors' Addresses Andy Bierman Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA 95134 Phone: +1 408-527-3711 Email: abierman@cisco.com Dan Romascanu Avaya Inc. Atidim Technology Park, Bldg. #3 Tel Aviv, 61131, Israel Phone: +972-3-545-8414 Email: dromasca@avaya.com K.C. Norseth Consultant 934 S. Palos Verdes Dr. Kaysville, Utah 84037 Expires February 2003 [Page 19] Internet Draft Entity Sensor MIB August 15, 2002 Phone: +1 801-546-3316 Email: kcn@norseth.com 14. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Expires February 2003 [Page 20]