draft-ietf-entmib-sensor-mib-02.txt
Bob Burget <[email protected]>
| Newsgroups | gmane.ietf.entmib |
|---|---|
| Organization | MSSBU WAN Engineering |
| Message-ID | <[email protected]> |
Dear IETF Working Group; I have recently become aware that a new MIB for physical sensors, (as defined by an entPhysicalClass value of 'sensor(8)') has been proposed for the IETF standards track. I request that the MIB text be modified to include some indication in the object descriptors that this MIB is for Physical entities. I hope to ensure that the relationship between the proposed MIB and the entPhysicalTable in the ENTITY-MIB is clarified. A similar case for reference is the existing entPhysicalContainsTable which also has the entPhysicalIndex as its INDEX. Attached is a text file that shows how this can be done. Please let me know if there would be any problems with this. Thanks, -- Bob Burget, [email protected]
draft-ietf-entmib-sensor-mib-02.txt
(text/plain, 36.4 KB)
Internet Draft Andy Bierman
Cisco Systems, Inc.
Dan Romascanu
Avaya Communication
K.C. Norseth
5 October 2002
Entity Physical Sensor
Management Information Base
<draft-ietf-entmib-sensor-mib-01.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.
1. Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Internet Draft Entity Physical Sensor MIB October 5, 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 Physical Sensor MIB October 5, 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 Physical Sensor MIB October 5, 2002
in the ENTITY-PHYSICAL-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 entPhySensorEntry 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 Physical 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 Physical Sensor MIB contains a single group called the
entityPhySensorValueGroup, which provides objects to convey the current
value and status of a physical sensor.
The entityPhySensorValueGroup contains a single table, called the
entPhySensorTable, which provides a small number of read-only objects:
entPhySensorType
This object identifies the type of data units associated with the
sensor value.
entPhySensorScale
This object identifies the (power of 10) scaling factor associated
with the sensor value.
Expires February 2003 [Page 4]
Internet Draft Entity Physical Sensor MIB October 5, 2002
entPhySensorPrecision
This object identifies the number of decimal places of precision
associated with the sensor value.
entPhySensorValue
This object identifies the current value of the sensor.
entPhySensorOperStatus
This object identifies the current operational status of the sensor
(as it's known to the agent).
entPhySensorUnitsDisplay
This object provides a textual description of the data units
represented by the entPhySensorType and entPhySensorScale objects.
entPhySensorValueTimeStamp
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 entPhySensorValueUpdateRate object is greater
than zero).
entPhySensorValueUpdateRate
This object indicates the nature of the agent implementation of the
entPhySensorEntry, 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-PHYSICAL-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 Physical Sensor MIB October 5, 2002
FROM SNMP-FRAMEWORK-MIB;
entityPhySensorMIB MODULE-IDENTITY
LAST-UPDATED "200210050000Z"
ORGANIZATION "IETF Entity MIB Working Group"
CONTACT-INFO
" Andy Bierman
Cisco Systems, Inc.
Tel: +1 408-527-3711
E-mail: [email protected]
Postal: 170 West Tasman Drive
San Jose, CA USA 95134
Dan Romascanu
Avaya Communication
Tel: +972-3-645-8414
Email: [email protected]
Postal: Atidim technology Park, Bldg. #3
Tel Aviv, Israel, 61131
K.C. Norseth
Consultant
Tel: +1 801-546-3316
Email: [email protected]
Postal: 934 S. Palos Verdes Dr.
Kaysville, Utah 84037
Send comments to <[email protected]>
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 Physical Sensor MIB module, published
as RFC xxxx." -- RFC Editor assigns xxxx
::= { mib-2 xxx } -- IANA needs to assign xxx
entityPhySensorObjects OBJECT IDENTIFIER
::= { entityPhySensorMIB 1 }
-- entityPhySensorNotifications OBJECT IDENTIFIER
-- ::= { entityPhySensorMIB 2 }
entityPhySensorConformance OBJECT IDENTIFIER
::= { entityPhySensorMIB 3 }
Expires February 2003 [Page 6]
Internet Draft Entity Physical Sensor MIB October 5, 2002
--
-- Textual Conventions
--
EntityPhySensorDataType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"An object using this data type represents the Entity Physical 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
EntityPhySensorDataScale object.
An object of this type SHOULD be defined together with
objects of type EntityPhySensorDataScale and
EntityPhySensorPrecision. Together, associated objects of
these three types are used to identify the semantics of an
object of type EntityPhySensorValue.
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 Physical Sensor MIB October 5, 2002
percentRH(9),
rpm(10),
cmm(11),
truthvalue(12)
}
EntityPhySensorDataScale ::= 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 EntityPhySensorDataType object.
An object of this type SHOULD be defined together with
objects of type EntityPhySensorDataType and
EntityPhySensorPrecision. Together, associated objects of
these three types are used to identify the semantics of an
object of type EntityPhySensorValue."
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
}
EntityPhySensorPrecision ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
Expires February 2003 [Page 8]
Internet Draft Entity Physical Sensor MIB October 5, 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 EntityPhySensorDataType and
EntityPhySensorDataScale. Together, associated objects of
these three types are used to identify the semantics of an
object of type EntityPhySensorValue.
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 EntityPhySensorValue 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 EntityPhySensorValue fixed-point number.
The value zero indicates the associated EntityPhySensorValue
object is not a fixed-point number.
Agent implementors must choose a value for the associated
EntityPhySensorPrecision object so that the precision and
accuracy of the associated EntityPhySensorValue 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
EntityPhySensorPrecision value of '1', an EntityPhySensorDataScale
value of 'units(9)', and an EntityPhySensorValue ranging from
'0' to '1000'. The EntityPhySensorValue would be interpreted
as 'degrees C * 10'."
SYNTAX Integer32 (-8..9)
EntityPhySensorValue ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"An object using this data type represents an Entity Physical Sensor
value.
An object of this type SHOULD be defined together with
objects of type EntityPhySensorDataType, EntityPhySensorDataScale
and EntityPhySensorPrecision. Together, associated objects of
those three types are used to identify the semantics of an
Expires February 2003 [Page 9]
Internet Draft Entity Physical Sensor MIB October 5, 2002
object of this data type.
The semantics of an object using this data type are
determined by the value of the associated
EntityPhySensorDataType object.
If the associated EntityPhySensorDataType 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 EntityPhySensorPrecision
indicates how many fractional digits are represented in the
associated EntityPhySensorValue object.
If the associated EntityPhySensorDataType object is equal to
'percentRH(9)', then an object of this type MUST contain a
number ranging from 0 to 100.
If the associated EntityPhySensorDataType 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 EntityPhySensorDataType 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 EntityPhySensorDataType 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)
EntityPhySensorStatus ::= 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 Physical Sensor MIB October 5, 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 Physical Sensor Table
--
entPhySensorTable OBJECT-TYPE
SYNTAX SEQUENCE OF EntPhySensorEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains one row per physical sensor represented
by an associated row in the entPhysicalTable."
::= { entityPhySensorObjects 1 }
entPhySensorEntry OBJECT-TYPE
SYNTAX EntPhySensorEntry
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
::= { entPhySensorTable 1 }
EntPhySensorEntry ::= SEQUENCE {
entPhySensorType EntityPhySensorDataType,
entPhySensorScale EntityPhySensorDataScale,
entPhySensorPrecision EntityPhySensorPrecision,
Expires February 2003 [Page 11]
Internet Draft Entity Physical Sensor MIB October 5, 2002
entPhySensorValue EntityPhySensorValue,
entPhySensorOperStatus EntityPhySensorStatus,
entPhySensorUnitsDisplay SnmpAdminString,
entPhySensorValueTimeStamp TimeStamp,
entPhySensorValueUpdateRate Unsigned32
}
entPhySensorType OBJECT-TYPE
SYNTAX EntityPhySensorDataType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The type of data returned by the associated entPhySensorValue
object.
This object SHOULD be set by the agent during entry
creation, and the value SHOULD NOT change during operation."
::= { entPhySensorEntry 1 }
entPhySensorScale OBJECT-TYPE
SYNTAX EntityPhySensorDataScale
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The exponent to apply to values returned by the associated
entPhySensorValue object.
This object SHOULD be set by the agent during entry
creation, and the value SHOULD NOT change during operation."
::= { entPhySensorEntry 2 }
entPhySensorPrecision OBJECT-TYPE
SYNTAX EntityPhySensorPrecision
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of decimal places of precision in fixed-point
sensor values returned by the associated entPhySensorValue
object.
This object SHOULD be set to '0' when the associated
entPhySensorType 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 Physical Sensor MIB October 5, 2002
creation, and the value SHOULD NOT change during operation."
::= { entPhySensorEntry 3 }
entPhySensorValue OBJECT-TYPE
SYNTAX EntityPhySensorValue
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 entPhySensorType, entPhySensorScale, and
entPhySensorPrecision objects must also be examined."
::= { entPhySensorEntry 4 }
entPhySensorOperStatus OBJECT-TYPE
SYNTAX EntityPhySensorStatus
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The operational status of the sensor."
::= { entPhySensorEntry 5 }
entPhySensorUnitsDisplay 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 entPhySensorValue."
::= { entPhySensorEntry 6 }
entPhySensorValueTimeStamp 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."
::= { entPhySensorEntry 7 }
entPhySensorValueUpdateRate OBJECT-TYPE
SYNTAX Unsigned32
UNITS "milliseconds"
Expires February 2003 [Page 13]
Internet Draft Entity Physical Sensor MIB October 5, 2002
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An indication of the frequency that the agent updates the
associated entPhySensorValue 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.
"
::= { entPhySensorEntry 8 }
--
-- Conformance Section
--
entityPhySensorCompliances OBJECT IDENTIFIER
::= { entityPhySensorConformance 1 }
entityPhySensorGroups OBJECT IDENTIFIER
::= { entityPhySensorConformance 2 }
entityPhySensorCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"Describes the requirements for conformance to the Entity
Sensor MIB module."
MODULE -- this module
MANDATORY-GROUPS { entityPhySensorValueGroup }
MODULE ENTITY-MIB
MANDATORY-GROUPS { entityPhysicalGroup }
::= { entityPhySensorCompliances 1 }
-- Object Groups
entityPhySensorValueGroup OBJECT-GROUP
OBJECTS {
entPhySensorType,
Expires February 2003 [Page 14]
Internet Draft Entity Physical Sensor MIB October 5, 2002
entPhySensorScale,
entPhySensorPrecision,
entPhySensorValue,
entPhySensorOperStatus,
entPhySensorUnitsDisplay,
entPhySensorValueTimeStamp,
entPhySensorValueUpdateRate
}
STATUS current
DESCRIPTION
"A collection of objects representing physical entity sensor
information."
::= { entityPhySensorGroups 1 }
END
Expires February 2003 [Page 15]
Internet Draft Entity Physical Sensor MIB October 5, 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 Physical Sensor MIB October 5, 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 Physical Sensor MIB October 5, 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 Physical Sensor MIB October 5, 2002
12. Security Considerations
There is one managed object in this MIB that may contain sensitive
information. This is:
entPhySensorValue
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: [email protected]
Dan Romascanu
Avaya Inc.
Atidim Technology Park, Bldg. #3
Tel Aviv, 61131, Israel
Phone: +972-3-545-8414
Email: [email protected]
K.C. Norseth
Consultant
934 S. Palos Verdes Dr.
Kaysville, Utah 84037
Expires February 2003 [Page 19]
Internet Draft Entity Physical Sensor MIB October 5, 2002
Phone: +1 801-546-3316
Email: [email protected]
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]