< draft-ietf-eman-battery-mib-18.txt   draft-ietf-eman-battery-mib-19.txt >
Network Working Group J. Quittek Network Working Group J. Quittek
Internet-Draft R. Winter Internet-Draft R. Winter
Intended status: Standards Track T. Dietz Intended status: Standards Track T. Dietz
Expires: September 25, 2015 NEC Europe Ltd. Expires: October 16, 2015 NEC Europe Ltd.
March 24, 2015 April 14, 2015
Definition of Managed Objects for Battery Monitoring Definition of Managed Objects for Battery Monitoring
draft-ietf-eman-battery-mib-18 draft-ietf-eman-battery-mib-19
Abstract Abstract
This memo defines a portion of the Management Information Base (MIB) This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community. for use with network management protocols in the Internet community.
In particular, it defines managed objects that provide information on In particular, it defines managed objects that provide information on
the status of batteries in managed devices. the status of batteries in managed devices.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 25, 2015. This Internet-Draft will expire on October 16, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Internet-Standard Management Framework . . . . . . . . . 5
2. The Internet-Standard Management Framework . . . . . . . . . . 6 3. Design of the Battery MIB Module . . . . . . . . . . . . . . 6
3.1. MIB Module Structure . . . . . . . . . . . . . . . . . . 6
3. Design of the Battery MIB Module . . . . . . . . . . . . . . . 7 3.2. Battery Technologies . . . . . . . . . . . . . . . . . . 8
3.1. MIB Module Structure . . . . . . . . . . . . . . . . . . . 7 3.2.1. Guidelines for Adding Battery Technologies . . . . . 9
3.2. Battery Technologies . . . . . . . . . . . . . . . . . . . 9 3.3. Battery Identification . . . . . . . . . . . . . . . . . 9
3.2.1. Guidelines for Adding Battery Technologies . . . . . . 10 3.4. Charging Cycles . . . . . . . . . . . . . . . . . . . . . 10
3.3. Battery Identification . . . . . . . . . . . . . . . . . . 10 3.5. Charge Control . . . . . . . . . . . . . . . . . . . . . 10
3.4. Charging Cycles . . . . . . . . . . . . . . . . . . . . . 11 3.6. Imported Definitions . . . . . . . . . . . . . . . . . . 11
3.5. Imported Definitions . . . . . . . . . . . . . . . . . . . 11 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 33
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
6.1. SMI Object Identifier Registration . . . . . . . . . . . 36
5. Security Considerations . . . . . . . . . . . . . . . . . . . 33 6.2. Battery Technology Registration . . . . . . . . . . . . . 37
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.1. SMI Object Identifier Registration . . . . . . . . . . . . 36 8.1. Normative References . . . . . . . . . . . . . . . . . . 37
6.2. Battery Technology Registration . . . . . . . . . . . . . 36 8.2. Informative References . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.1. Normative References . . . . . . . . . . . . . . . . . . . 37
8.2. Informative References . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
Today, more and more managed devices contain batteries that supply Today, more and more managed devices contain batteries that supply
them with power when disconnected from electrical power distribution them with power when disconnected from electrical power distribution
grids. Common examples are nomadic and mobile devices, such as grids. Common examples are nomadic and mobile devices, such as
notebook computers, netbooks, and smart phones. The status of notebook computers, netbooks, and smart phones. The status of
batteries in such a device, particularly the charging status is batteries in such a device, particularly the charging status is
typically controlled by automatic functions that act locally on the typically controlled by automatic functions that act locally on the
device and manually by users of the device. device and manually by users of the device.
skipping to change at page 7, line 15 skipping to change at page 6, line 17
3. Design of the Battery MIB Module 3. Design of the Battery MIB Module
3.1. MIB Module Structure 3.1. MIB Module Structure
The Battery MIB module defined in this document defines objects for The Battery MIB module defined in this document defines objects for
reporting information about batteries. All managed objects providing reporting information about batteries. All managed objects providing
information of the status of a battery are contained in a single information of the status of a battery are contained in a single
table called batteryTable. The batteryTable contains one conceptual table called batteryTable. The batteryTable contains one conceptual
row per battery. row per battery.
Batteries are indexed by the entPhysicalIndex of the entPhysicalTable Batteries are indexed by the entPhysicalIndex of the
defined in the ENTITY-MIB module [RFC6933]. An implementation of the entPhysicalTable defined in the ENTITY-MIB module [RFC6933]. An
ENTITY-MIB module complying with the entity4CRCompliance MODULE- implementation of the ENTITY-MIB module complying with the
COMPLIANCE statement is required for compliant implementations of the entity4CRCompliance MODULE-COMPLIANCE statement is required for
BATTERY-MIB module. compliant implementations of the BATTERY-MIB module.
If a battery is replaced, and the replacing battery uses the same If a battery is replaced, and the replacing battery uses the same
physical connector as the replaced battery, then the replacing physical connector as the replaced battery, then the replacing
battery MUST be indexed with the same value of object battery MUST be indexed with the same value of object
entPhysicalIndex as the replaced battery. entPhysicalIndex as the replaced battery.
The kind of entity in the entPhysicalTable of the Entity MIB module The kind of entity in the entPhysicalTable of the Entity MIB module
is indicated by the value of enumeration object entPhysicalClass. is indicated by the value of enumeration object entPhysicalClass.
All batteries SHOULD have the value of object entPhysicalClass set to All batteries SHOULD have the value of object entPhysicalClass set to
battery(14) in their row of the entPhysicalTable. battery(14) in their row of the entPhysicalTable.
skipping to change at page 11, line 32 skipping to change at page 10, line 33
3.4. Charging Cycles 3.4. Charging Cycles
The lifetime of a battery can be approximated using the measure of The lifetime of a battery can be approximated using the measure of
charging cycles. A commonly used definition of a charging cycle is charging cycles. A commonly used definition of a charging cycle is
the amount of discharge equal to the design (or nominal) capacity of the amount of discharge equal to the design (or nominal) capacity of
the battery [SBS]. This means that a single charging cycle may the battery [SBS]. This means that a single charging cycle may
include several steps of partial charging and discharging until the include several steps of partial charging and discharging until the
amount of discharging has reached the design capacity of the battery. amount of discharging has reached the design capacity of the battery.
After that the next charging cycle immediately starts. After that the next charging cycle immediately starts.
3.5. Imported Definitions 3.5. Charge Control
Managed object batteryChargingOperState indicates the current
operational charging state of a battery and is a read-only object.
For controlling the charging state object batteryChargingAdminState
can be used. Writing to this object initiates a request to adapt the
operational state according to the value that has been written.
By default the batteryChargingAdminState object is set to notSet(1).
In this state the charging controller is using its predefined
policies to decide which operational state is suitable in the current
situation.
Setting the value of object batteryChargingAdminState may result in
not changing the state of the battery to this value or even in
setting the charging state to another value than the requested one.
Due to operational conditions and limitations of the implementation
of the BATTERY-MIB module, changing the battery status according to a
set value of object batteryChargingAdminState might not be possible.
For example, the charging controller might at any time decide to
enter state using(6), if there is an operational need to use the
battery for supplying power.
The object batteryChargingAdminState will not automatically change
when the object batteryChargingOperState changes. If the operational
state is changed, e.g. to the state using(6) due to operational
conditions, the admin state will remain in its current state. The
charging controller SHOULD change the operational state to the state
indicated by the object batteryChargingAdminState as soon as
operational conditions allow this change.
If a state change of the object batteryChargingAdminState is desired
upon change of the operational state, the object
batteryChargingOperState must be polled or the notification
batteryChargingStateNotification must be used to get notified about
the state change. This could be used, e.g. if maintaining charge is
not desired after fully charging a battery even if charging
controller and battery support it. The object
batteryChargingAdminState can then be set to doNotCharge(3) when the
object batteryChargingOperState changes from charging(2) to
maintainingCharge(3). Another use case would be when performing
several charge and discharge cycles for battery maintenance.
3.6. Imported Definitions
The Battery MIB module defined in this document imports definitions The Battery MIB module defined in this document imports definitions
from the following MIB modules: SNMPv2-SMI [RFC2578], SNMPv2-TC from the following MIB modules: SNMPv2-SMI [RFC2578], SNMPv2-TC
[RFC2579], SNMPv2-CONF [RFC2580], SNMP-FRAMEWORK-MIB [RFC3411], [RFC2579], SNMPv2-CONF [RFC2580], SNMP-FRAMEWORK-MIB [RFC3411],
ENTITY-MIB [RFC6933]. ENTITY-MIB [RFC6933].
4. Definitions 4. Definitions
BATTERY-MIB DEFINITIONS ::= BEGIN BATTERY-MIB DEFINITIONS ::= BEGIN
skipping to change at page 12, line 4 skipping to change at page 11, line 48
BATTERY-MIB DEFINITIONS ::= BEGIN BATTERY-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
mib-2, Integer32, Unsigned32 mib-2, Integer32, Unsigned32
FROM SNMPv2-SMI -- RFC2578 FROM SNMPv2-SMI -- RFC2578
SnmpAdminString SnmpAdminString
FROM SNMP-FRAMEWORK-MIB -- RFC3411 FROM SNMP-FRAMEWORK-MIB -- RFC3411
DateAndTime DateAndTime
FROM SNMPv2-TC -- RFC2579 FROM SNMPv2-TC -- RFC2579
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF -- RFC2580 FROM SNMPv2-CONF -- RFC2580
entPhysicalIndex entPhysicalIndex
FROM ENTITY-MIB; -- RFC6933 FROM ENTITY-MIB; -- RFC6933
batteryMIB MODULE-IDENTITY batteryMIB MODULE-IDENTITY
LAST-UPDATED "201411301200Z" -- 30 November 2014 LAST-UPDATED "201504141200Z" -- 14 April 2015
ORGANIZATION "IETF EMAN Working Group" ORGANIZATION "IETF EMAN Working Group"
CONTACT-INFO CONTACT-INFO
"General Discussion: eman@ietf.org "General Discussion: eman@ietf.org
To Subscribe: http://www.ietf.org/mailman/listinfo/eman To Subscribe: http://www.ietf.org/mailman/listinfo/eman
Archive: http://www.ietf.org/mail-archive/web/eman Archive: http://www.ietf.org/mail-archive/web/eman
Editor: Editor:
Juergen Quittek Juergen Quittek
NEC Europe Ltd. NEC Europe Ltd.
NEC Laboratories Europe NEC Laboratories Europe
skipping to change at page 12, line 48 skipping to change at page 12, line 43
License set forth in Section 4.c of the IETF Trust's Legal License set forth in Section 4.c of the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this MIB module is part of RFC yyyy; see This version of this MIB module is part of RFC yyyy; see
the RFC itself for full legal notices." the RFC itself for full legal notices."
-- replace yyyy with actual RFC number & remove this notice -- replace yyyy with actual RFC number & remove this notice
-- Revision history -- Revision history
REVISION "201411301200Z" -- 30 November 2014 REVISION "201504141200Z" -- 14 April 2015
DESCRIPTION DESCRIPTION
"Initial version, published as RFC yyyy." "Initial version, published as RFC yyyy."
-- replace yyyy with actual RFC number & remove this notice -- replace yyyy with actual RFC number & remove this notice
::= { mib-2 zzz } ::= { mib-2 zzz }
-- zzz to be assigned by IANA. -- zzz to be assigned by IANA.
--****************************************************************** --******************************************************************
-- Top Level Structure of the MIB module -- Top Level Structure of the MIB module
--****************************************************************** --******************************************************************
batteryNotifications OBJECT IDENTIFIER ::= { batteryMIB 0 } batteryNotifications OBJECT IDENTIFIER ::= { batteryMIB 0 }
batteryObjects OBJECT IDENTIFIER ::= { batteryMIB 1 } batteryObjects OBJECT IDENTIFIER ::= { batteryMIB 1 }
batteryConformance OBJECT IDENTIFIER ::= { batteryMIB 2 } batteryConformance OBJECT IDENTIFIER ::= { batteryMIB 2 }
skipping to change at page 19, line 33 skipping to change at page 19, line 27
For batteries of type primary(1) the value of this object is For batteries of type primary(1) the value of this object is
always '0000000000000000'H." always '0000000000000000'H."
::= { batteryEntry 12 } ::= { batteryEntry 12 }
batteryChargingOperState OBJECT-TYPE batteryChargingOperState OBJECT-TYPE
SYNTAX INTEGER { SYNTAX INTEGER {
unknown(1), unknown(1),
charging(2), charging(2),
maintainingCharge(3), maintainingCharge(3),
noCharging(4), noCharging(4),
discharging(5) discharging(5),
using(6)
} }
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This object indicates the current charging state of the "This object indicates the current charging state of the
battery. battery.
Value unknown(1) indicates that the charging state of the Value unknown(1) indicates that the charging state of the
battery cannot be determined. battery cannot be determined.
skipping to change at page 20, line 10 skipping to change at page 20, line 4
being charged with a low average current that compensates being charged with a low average current that compensates
self-discharging. This includes trickle charging, float self-discharging. This includes trickle charging, float
charging and other methods for maintaining the current charging and other methods for maintaining the current
charge of a battery. In typical implementations of charging charge of a battery. In typical implementations of charging
controllers, state maintainingCharge(3) is only applied controllers, state maintainingCharge(3) is only applied
if the battery is fully charged or almost fully charged. if the battery is fully charged or almost fully charged.
Value noCharging(4) indicates that the battery is not being Value noCharging(4) indicates that the battery is not being
charged or discharged by electric current between the charged or discharged by electric current between the
battery and electric circuits external to the battery. battery and electric circuits external to the battery.
Note that the battery may still be subject to Note that the battery may still be subject to
self-discharging. self-discharging.
Value discharging(5) indicates that the battery is being Value discharging(5) indicates that the battery is being
discharged and that the charge of the battery decreases." intentionally discharged by the charging controller for the
purpose of battery maintenace. Thus, the charge of the
battery decreases.
Value using(6) indicates that the battery is used as the
power source for the electric circuits external to the
battery. As a consequence the battery is discharging and
the charge of the battery decreases."
::= { batteryEntry 13 } ::= { batteryEntry 13 }
batteryChargingAdminState OBJECT-TYPE batteryChargingAdminState OBJECT-TYPE
SYNTAX INTEGER { SYNTAX INTEGER {
notSet(1), notSet(1),
charge(2), charge(2),
chargeAndMaintainCharge(3), doNotCharge(3),
doNotCharge(4), discharge(4)
discharge(5)
} }
MAX-ACCESS read-write MAX-ACCESS read-write
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The value of this object indicates the desired "The value of this object indicates the desired
charging state of the battery. The real state is charging state of the battery. The real state is
indicated by object batteryChargingOperState. See the indicated by object batteryChargingOperState. See the
definition of object batteryChargingOperState for a definition of object batteryChargingOperState for a
description of the values. description of the values.
When this object is initialized by an implementation of the When this object is initialized by an implementation of the
BATTERY-MIB module, its value is set to notSet(1). BATTERY-MIB module, its value is set to notSet(1). In this
case the charging controller is free to choose which
However, a SET request can only set this object to either operational state is suitable.
charge(2), chargeAndMaintainCharge(3), doNotCharge(4), or
discharge(5). Attempts to set this object to notSet(1)
will always fail with an 'inconsistentValue' error.
When the batteryChargingAdminState object is set, then the When the batteryChargingAdminState object is set, then the
BATTERY-MIB implementation must try to set the battery BATTERY-MIB implementation must try to set the battery
to the indicated state. The result will be indicated by to the indicated state. The result will be indicated by
object batteryChargingOperState. object batteryChargingOperState.
Setting object batteryChargingAdminState to value Setting object batteryChargingAdminState to value notSet(1)
chargeAndMaintainCharge(3) is a request for first is a request to the charging controller to operate
charging the battery in state charging(2) and then autonomously and choose the operational state that is
entering state maintainingCharge(3). If the battery suitable.
is already fully charged or almost fully charged,
then setting object batteryChargingAdminState to value
chargeAndMaintainCharge(3) is a request for entering
state maintainingCharge(3).
Setting object batteryChargingAdminState to value Setting object batteryChargingAdminState to value
charge(2) is a request for first entering operational charge(2) is a request for first entering operational
state charging(2) until the battery is fully charged state charging(2) until the battery is fully charged. If
and then entering operational state noCharging(4). the charging controller and the battery support the
When operational state noCharging(4) is entered, the functionality of maintaining the charge the operational
value of object batteryChargingAdminState is reset to state will change to maintainingCharge(3). Otherwise the
notSet(1). operational state will change to noCharging(4).
If the battery is already fully charged or almost fully If the battery is already fully charged or almost fully
charged, then setting object batteryChargingAdminState charged, then setting object batteryChargingAdminState
to value charge(2) is a request for entering state to value charge(2) is a request for entering state
noCharging(4). When operational state noCharging(4) is maintainingCharge(3) if the charging controller and the
entered, the value of object batteryChargingAdminState battery support the functionality of maintaining the
is reset to notSet(1). charge or the state noCharging(4) otherwise.
Setting object batteryChargingAdminState to value Setting object batteryChargingAdminState to value
doNotCharge(4) is a request for entering operational doNotCharge(3) is a request for entering operational
state noCharging(4). state noCharging(4).
Setting object batteryChargingAdminState to value Setting object batteryChargingAdminState to value
discharge(5) is a request for entering operational discharge(4) is a request for entering operational
state discharging(5). state discharging(5). If the battery is empty or almost
empty the operational state will change to noCharging(4).
The charging controller will decide which charge condition
will be considered empty dependent on the battery
technology used. This is done to avoid damage on the
battery due to deep discharge.
Due to operational conditions and limitations of the Due to operational conditions and limitations of the
implementation of the BATTERY-MIB module, changing the implementation of the BATTERY-MIB module, changing the
battery status according to a set value of object battery status according to a set value of object
batteryChargingAdminState may not be possible. batteryChargingAdminState may not be possible.
Setting the value of object batteryChargingAdminState Setting the value of object batteryChargingAdminState
may result in not changing the state of the battery may result in not changing the state of the battery
to this value or even in setting the charging state to this value or even in setting the charging state
to another value than the requested one. For example, to another value than the requested one. For example,
the charging controller might at any time decide to the charging controller might at any time decide to
enter state discharging(5), if there is an operational enter state using(6), if there is an operational need
need to use the battery for supplying power." to use the battery for supplying power."
::= { batteryEntry 14 } ::= { batteryEntry 14 }
batteryActualCharge OBJECT-TYPE batteryActualCharge OBJECT-TYPE
SYNTAX Unsigned32 SYNTAX Unsigned32
UNITS "milliampere hours" UNITS "milliampere hours"
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This object provides the actual charge of the battery "This object provides the actual charge of the battery
in units of milliampere hours (mAh). in units of milliampere hours (mAh).
skipping to change at page 36, line 40 skipping to change at page 37, line 12
[NOTE for IANA: Please allocate an object identifier at [NOTE for IANA: Please allocate an object identifier at
http://www.iana.org/assignments/smi-numbers for object batteryMIB.] http://www.iana.org/assignments/smi-numbers for object batteryMIB.]
6.2. Battery Technology Registration 6.2. Battery Technology Registration
Object batteryTechnology defined in Section 4 reports battery Object batteryTechnology defined in Section 4 reports battery
technologies. Eighteen values for battery technologies have technologies. Eighteen values for battery technologies have
initially been defined. They are listed in a table in Section 3.2. initially been defined. They are listed in a table in Section 3.2.
For ensuring extensibility of this list, IANA has created a registry For ensuring extensibility of this list, IANA has created a registry
for battery technologies at for battery technologies at http://www.iana.org/assignments/battery-
http://www.iana.org/assignments/battery-technologies and filled it technologies and filled it with the initial list given in
with the initial list given in Section 3.2. Section 3.2.
New assignments of numbers for battery technologies will be New assignments of numbers for battery technologies will be
administered by IANA through Expert Review ([RFC5226]). Experts must administered by IANA through Expert Review ([RFC5226]). Experts must
check for sufficient relevance of a battery technology to be added check for sufficient relevance of a battery technology to be added
according to the guidelines in section Section 3.2.1. according to the guidelines in section Section 3.2.1.
[NOTE for IANA: Please create a new registry under [NOTE for IANA: Please create a new registry under
http://www.iana.org/assignments/battery-technologies for battery http://www.iana.org/assignments/battery-technologies for battery
types. Please fill the registry with values from the table in types. Please fill the registry with values from the table in
Section 3.2] Section 3.2]
skipping to change at page 37, line 27 skipping to change at page 37, line 47
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Textual Conventions for SMIv2", Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD
STD 58, RFC 2579, April 1999. 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580, "Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999. April 1999.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002. December 2002.
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management (USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
[RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The
Advanced Encryption Standard (AES) Cipher Algorithm in the Advanced Encryption Standard (AES) Cipher Algorithm in the
SNMP User-based Security Model", RFC 3826, June 2004. SNMP User-based Security Model", RFC 3826, June 2004.
[RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model
for the Simple Network Management Protocol (SNMP)", for the Simple Network Management Protocol (SNMP)", STD
STD 78, RFC 5591, June 2009. 78, RFC 5591, June 2009.
[RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure
Shell Transport Model for the Simple Network Management Shell Transport Model for the Simple Network Management
Protocol (SNMP)", RFC 5592, June 2009. Protocol (SNMP)", RFC 5592, June 2009.
[RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport
Model for the Simple Network Management Protocol (SNMP)", Model for the Simple Network Management Protocol (SNMP)",
STD 78, RFC 6353, July 2011. STD 78, RFC 6353, July 2011.
[RFC6933] Bierman, A., Romascanu, D., Quittek, J., and M. [RFC6933] Bierman, A., Romascanu, D., Quittek, J., and M.
Chandramouli, "Entity MIB (Version 4)", RFC 6933, Chandramouli, "Entity MIB (Version 4)", RFC 6933, May
May 2013. 2013.
8.2. Informative References 8.2. Informative References
[RFC6988] Quittek, J., Chandramouli, M., Winter, R., Dietz, T., and [RFC6988] Quittek, J., Chandramouli, M., Winter, R., Dietz, T., and
B. Claise, "Requirements for Energy Management", RFC 6988, B. Claise, "Requirements for Energy Management", RFC 6988,
September 2013. September 2013.
[RFC7326] Parello, J., Claise, B., Schoening, B., and J. Quittek, [RFC7326] Parello, J., Claise, B., Schoening, B., and J. Quittek,
"Energy Management Framework", RFC 7326, September 2014. "Energy Management Framework", RFC 7326, September 2014.
[RFC7460] Chandramouli, M., Claise, B., Schoening, B., Quittek, J., [RFC7460] Chandramouli, M., Claise, B., Schoening, B., Quittek, J.,
and T. Dietz, "Monitoring and Control MIB for Power and and T. Dietz, "Monitoring and Control MIB for Power and
Energy", RFC 7460, March 2015. Energy", RFC 7460, March 2015.
[RFC1628] Case, J., "UPS Management Information Base", RFC 1628, [RFC1628] Case, J., "UPS Management Information Base", RFC 1628, May
May 1994. 1994.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet- "Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002. Standard Management Framework", RFC 3410, December 2002.
[SBS] "Smart Battery Data Specification", Revision 1.1, [SBS] "Smart Battery Data Specification", Revision 1.1, December
December 1998. 1998.
Authors' Addresses Authors' Addresses
Juergen Quittek Juergen Quittek
NEC Europe Ltd. NEC Europe Ltd.
NEC Laboratories Europe NEC Laboratories Europe
Network Research Division Network Research Division
Kurfuersten-Anlage 36 Kurfuersten-Anlage 36
Heidelberg 69115 Heidelberg 69115
DE DE
 End of changes. 28 change blocks. 
86 lines changed or deleted 129 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/