Internet Draft Andy Bierman
Cisco Systems, Inc.
Dan Romascanu
Avaya Communication
KC Norseth
Enterasys Networks
18 January 2002
Entity Sensor
Management Information Base
<draft-ietf-entmib-sensor-mib-00.txt>
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.
Internet Draft Entity Sensor MIB January 18, 2002
1. Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
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 ................................................ 2
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 References ..................................................... 16
11 Security Considerations ........................................ 19
12 Authors' Addresses ............................................. 19
13 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].
Expires July 2002 [Page 2]
Internet Draft Entity Sensor MIB January 18, 2002
o Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and
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.
Expires July 2002 [Page 3]
Internet Draft Entity Sensor MIB January 18, 2002
Physical sensors are represented in the Entity MIB with entPhysicalEntry
and an entPhysicalClass value of 'sensor(8)'. The information provided
in the ENTITY-SENSOR-MIB module (defined in this document) augments the
entPhysicalTable, but only 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 conceptually extend the
entPhysicalTable in the Entity MIB, but only 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. OPEN ISSUE: The current version of the MIB defines
this object as an enum. This limits the scalability to a pre-
defined set of values. A syntax of OID with a IANA-administered
list of entSensorTypes would allow for the list to be extended with
new types of sensors that might show up in the future. The Working
Expires July 2002 [Page 4]
Internet Draft Entity Sensor MIB January 18, 2002
Group should decide is this extensibility is worth the price of the
relative complexity of using an OID syntax. Also, an OID syntax may
potentially be abused, since this syntax does not restrict the list
of OID values to IANA-administered values.
entSensorScale
This object identifies the (power of 10) scaling factor associated
with the sensor value.
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.
entSensorStatus
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,
Expires July 2002 [Page 5]
Internet Draft Entity Sensor MIB January 18, 2002
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
FROM SNMP-FRAMEWORK-MIB;
entitySensorMIB MODULE-IDENTITY
LAST-UPDATED "200201180000Z"
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
KC Norseth
Enterasys Networks
Tel: +1 801 887 9823
Email: knorseth@enterasys.com
Postal: 2691 South Decker Lake Lane
Salt Lake City, Utah 84119
Send comments to <entmib@ietf.org>
Mailing list subscription info:
http://www.ietf.org/mailman/listinfo/entmib "
DESCRIPTION
"This module defines Entity MIB extensions for physical
sensors."
REVISION "200201180000Z"
DESCRIPTION
"Initial version of the Entity Sensor MIB module."
Expires July 2002 [Page 6]
Internet Draft Entity Sensor MIB January 18, 2002
::= { mib-2 xxx } -- unassigned
entitySensorObjects OBJECT IDENTIFIER
::= { entitySensorMIB 1 }
entitySensorNotifications OBJECT IDENTIFIER
::= { entitySensorMIB 2 }
entitySensorConformance OBJECT IDENTIFIER
::= { entitySensorMIB 3 }
--
-- 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) }
"
Expires July 2002 [Page 7]
Internet Draft Entity Sensor MIB January 18, 2002
SYNTAX INTEGER {
other(1),
unknown(2),
voltsAC(3),
voltsDC(4),
amperes(5),
watts(6),
hertz(7),
celsius(8),
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
Expires July 2002 [Page 8]
Internet Draft Entity Sensor MIB January 18, 2002
exa(14), -- 10^15
peta(15), -- 10^18
zetta(16), -- 10^21
yotta(17) -- 10^24
}
EntitySensorPrecision ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"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
Expires July 2002 [Page 9]
Internet Draft Entity Sensor MIB January 18, 2002
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
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
Expires July 2002 [Page 10]
Internet Draft Entity Sensor MIB January 18, 2002
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.
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
Expires July 2002 [Page 11]
Internet Draft Entity Sensor MIB January 18, 2002
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,
entSensorValue EntitySensorValue,
entSensorStatus 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
Expires July 2002 [Page 12]
Internet Draft Entity Sensor MIB January 18, 2002
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
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 }
entSensorStatus 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
Expires July 2002 [Page 13]
Internet Draft Entity Sensor MIB January 18, 2002
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"
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 }
Expires July 2002 [Page 14]
Internet Draft Entity Sensor MIB January 18, 2002
MODULE ENTITY-MIB
MANDATORY-GROUPS { entityPhysicalGroup }
::= { entitySensorCompliances 1 }
-- Object Groups
entitySensorValueGroup OBJECT-GROUP
OBJECTS {
entSensorType,
entSensorScale,
entSensorPrecision,
entSensorValue,
entSensorStatus,
entSensorUnitsDisplay,
entSensorValueTimeStamp,
entSensorValueUpdateRate
}
STATUS current
DESCRIPTION
"A collection of objects representing physical entity sensor
information."
::= { entitySensorGroups 1 }
END
Expires July 2002 [Page 15]
Internet Draft Entity Sensor MIB January 18, 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. 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.
Expires July 2002 [Page 16]
Internet Draft Entity Sensor MIB January 18, 2002
[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.
[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
Levels" RFC 2119, Harvard University, March 1997.
[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.
[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.
Expires July 2002 [Page 17]
Internet Draft Entity Sensor MIB January 18, 2002
[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.,
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.
[RFC2819]
S. Waldbusser, "Remote network Monitoring Management Information
Base", RFC 2819, Lucent Technologies, May 2000.
Expires July 2002 [Page 18]
Internet Draft Entity Sensor MIB January 18, 2002
11. 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.
12. 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
KC Norseth
Enterasys Networks
2691 South Decker Lake Lane
Salt Lake City, Utah 84119
Expires July 2002 [Page 19]
Internet Draft Entity Sensor MIB January 18, 2002
Phone: +1 801 887 9823
Email: knorseth@enterasys.com
13. 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 July 2002 [Page 20]
