Energy Object Context MIB
draft-ietf-eman-energy-aware-mib-11
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7461.
|
|
|---|---|---|---|
| Authors | John Parello , Benoît Claise , Mouli Chandramouli | ||
| Last updated | 2013-11-29 | ||
| Replaces | draft-parello-eman-energy-aware-mib | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | Dan Romascanu | ||
| IESG | IESG state | Became RFC 7461 (Proposed Standard) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | Joel Jaeggli | ||
| Send notices to | (None) |
draft-ietf-eman-energy-aware-mib-11
Network Working Group J. Parello
Internet-Draft B. Claise
Intended Status: Standards Track Mouli Chandramouli
Expires: May 29, 2014 Cisco Systems, Inc.
November 29, 2013
Energy Object Context MIB
draft-ietf-eman-energy-aware-mib-11
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance
with the provisions of BCP 78 and BCP 79.
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
This Internet-Draft will expire on May 29, 2014.
<Parello, Claise> Expires May 29, 2014 [Page 1]
Internet-Draft < Energy Object Context MIB > November 2013
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described
in Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License.
Abstract
This document defines a subset of a Management Information Base
(MIB) for energy management of devices. The module addresses
device identification, context information, and the
relationships between reporting devices, remote devices, and
monitoring devices.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" in this document are to
be interpreted as described in RFC 2119 [RFC2119].
Table of Contents
1. Introduction.............................................. 3
1.1. Energy Management Document Overview...................3
2. The Internet-Standard Management Framework................ 4
3. Requirements and Use Cases................................ 4
4. Terminology............................................... 4
5. Architecture Concepts Applied to the MIB Module........... 6
5.1 Energy Object Identification...........................8
5.2 Energy Object Context..................................9
5.3 Links to Other Identifiers............................10
5.4 Energy Object Relationships...........................11
5.5 Energy Object Identity Persistence....................12
6. MIB Definitions.......................................... 12
<Parello, Claise> Expires May 29, 2014 [Page 2]
Internet-Draft < Energy Object Context MIB > November 2013
7. Implementation Status.................................... 27
8. Security Considerations.................................. 28
9. IANA Considerations...................................... 29
10. Acknowledgement......................................... 29
11. References.............................................. 30
11.1. Normative References................................30
11.2. Informative References..............................31
1. Introduction
The EMAN standards provide a specification for Energy
Management. This document defines a subset of a Management
Information Base (MIB) for use with network management protocols
for Energy monitoring of network devices and devices attached to
the network and possibly extending to devices in the industrial
automation setting with a network interface.
The focus of the MIB module specified in this document is on the
identification of Energy Objects and reporting the context and
relationships of Energy Objects as defined in [EMAN-FMWK]. The
module addresses Energy Object Identification, Energy Object
Context, and Energy Object Relationships.
1.1. Energy Management Document Overview
This document specifies the Energy Object Context (ENERGY-
OBJECT-CONTEXT-MIB) and IANA Energy Relationship (IANA-ENERGY-
RELATION-MIB) modules. The Energy Object Context MIB module
specifies MIB objects for identification of Energy Objects, and
reporting context and relationship of an Energy Object. The IANA
Energy Relationship MIB module specifies the first version of
the IANA-maintained definitions of relationships between Energy
Objects.
This document is based on the Energy Management Framework [EMAN-
FMWK] and meets the requirements on identification of Energy
Objects and their context and relationships as specified in the
Energy Management requirements [RFC6988].
A second MIB module required by the [EMAN-FMWK], the Power and
Energy Monitoring MIB [EMAN-MON-MIB], monitors the Energy
Objects for Power States, for the Power and Energy consumption.
Power State monitoring includes: retrieving Power States, Power
State properties, current Power State, Power State transitions,
and Power State statistics. In addition, this MIB module
<Parello, Claise> Expires May 29, 2014 [Page 3]
Internet-Draft < Energy Object Context MIB > November 2013
provides the Power Characteristics properties of the Power and
Energy, along with optional characteristics.
The applicability statement document [EMAN-AS] provides the list
of use cases, and describes the common aspects of between
existing Energy standards and the EMAN standard, and shows how
the EMAN framework relates to other frameworks.
2. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the
current Internet-Standard Management Framework, please refer to
section 7 of RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store,
termed the Management Information Base or MIB. MIB objects are
generally accessed through the Simple Network Management
Protocol (SNMP). Objects in the MIB are defined using the
mechanisms defined in the Structure of Management Information
(SMI). This memo specifies MIB modules that are compliant with
SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58,
RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
3. Requirements and Use Cases
Firstly, to illustrate the importance of energy monitoring in
networks and secondly to list some of the important areas to be
addressed by the Energy Management Framework, several use cases
and network scenarios are presented in the EMAN applicability
statement document [EMAN-AS]. In addition, for each scenario,
the target devices for energy management, and how those devices
powered and metered are also presented. To address the network
scenarios, requirements for power and energy monitoring for
networking devices are specified in [RFC6988]. Based on the
requirements [RFC6988], the [EMAN-FMWK] presents a solution
approach.
Accordingly, the scope of the MIB modules in this document is in
accordance to the requirements specified in [RFC6988] and the
concepts from [EMAN-FMWK].
4. Terminology
<Parello, Claise> Expires May 29, 2014 [Page 4]
Internet-Draft < Energy Object Context MIB > November 2013
Please refer to [EMAN-FMWK] for the definitions of the following
terminology used in this draft:
Energy Management
Energy Management System (EnMS)
Energy Monitoring
Energy Control
electrical equipment
non-electrical equipment (mechanical equipment)
device
component
power inlet
power outlet
energy
power
demand
provide energy
receive energy
meter (energy meter)
battery
Power Interface
Nameplate Power
Power Attributes
Power Quality
Power State
Power State Set
<Parello, Claise> Expires May 29, 2014 [Page 5]
Internet-Draft < Energy Object Context MIB > November 2013
5. Architecture Concepts Applied to the MIB Module
This section describes the basic concepts specified in the
Energy Management Architecture [EMAN-FMWK], with specific
information related to the MIB modules specified in this
document.
The Energy Object Context (ENERGY-OBJECT-CONTEXT-MIB) MIB module
in this document specifies MIB objects for identification of
Energy Objects, and reporting context and relationship of an
Energy Object. The managed objects are contained in two tables
eoTable and eoRelationTable.
The first table eoTable focuses on link to the other MIB
modules, context of the Energy Object. The second table
eoRelationTable specifies the relationships between Energy
Objects. This is a simplified representation of relationship
between Energy Objects.
+- eoTable(2)
|
+- eoEntry(1) [entPhysicalIndex]
| |
| +-- r-n PethPsePortIndexOrZero eoEthPortIndex(1)
| +-- r-n PethPsePortGroupIndexOrZero eoEthPortGrpIndex(2)
| +-- r-n LldpPortNumberOrZero eoLldpPortNumber(3)
| +-- rwn MacAddress eoMgmtMacAddress(4)
| +-- r-n InetAddressType eoMgmtAddressType(5)
| +-- r-n InetAddress eoMgmtAddress(6)
| +-- r-n SnmpAdminString eoMgmtDNSName(7)
| +-- rwn SnmpAdminString eoDomainName(8)
| +-- rwn SnmpAdminString eoRoleDescription(9)
| +-- rwn EnergyObjectKeywordList eoKeywords(10)
| +-- rwn Integer32 eoImportance(11)
| +-- r-n INTEGER eoPowerCategory(12)
| +-- rwn SnmpAdminString eoAlternateKey(13)
| +-- r-n INTEGER eoPowerInterfaceType(14)
| +- eoRelationTable(2)
| |
| +- eoRelationEntry(1) [entPhysicalIndex,
eoRelationIndex]
| | |
| | +-- --n Integer32 eoRelationIndex(1)
| | +-- --n UUIDorZero eoRelationID(2)
<Parello, Claise> Expires May 29, 2014 [Page 6]
Internet-Draft < Energy Object Context MIB > November 2013
| | +-- rwn IANAEnergyRelationship
eoRelationship(3)
The following UML diagram illustrates the relationship of the
MIB objects in the eoTable, eoRelationTable that describe the
identity, context and relationship of an Energy Object.
+--------------------------+
| EO Context Information |
| ------------------------ |
| eoRoleDescription |
| eoKeywords |
| eoImportance |
| eoPowerCategory |
| eoPowerInterfaceType |
+--------------------------+
|
|
v
+-----------------------------+
|---> | EO Identification |
| |_---------------------------- |
| | entPhysicalIndex (*) |
| | entPhysicalName (*) |
| | entPhysicalUUID (*) |
| | |
| | eoEthPortIndex (**) |
| | eoEthPortGrpIndex (**) |
| | eoLldpPortNumber (***) |
| | eoAlternateKey |
| | |
| | eoMgmtMacAddress (optional) |
| | eoMgmtAddressType (optional) |
| | eoMgmtAddress (optional) |
| | eoMgmtDNSName (optional) |
| | eoDomainName |
| +------------------------------+
|
| +------------------------------+
|---- | EO Relationship |
| | ---------------------------- |
| | eoRelationIndex |
| | eoRelationID |
| | IANAEnergyRelationship |
| +------------------------------+
<Parello, Claise> Expires May 29, 2014 [Page 7]
Internet-Draft < Energy Object Context MIB > November 2013
(*) Compliance with the ENTITY MIB V4 [RFC6933]
(**) Link with the Power over Ethernet MIB [RFC3621]
(***) Link with LLDP MIBs [LLDP-MIB] [LLDP-MED-MIB]
Figure 1: MIB Objects Grouping
As displayed in figure 1, the MIB objects can be classified in
different logical grouping of MIB objects.
1) The Energy Object Identification. See Section 5.1 "Energy
Object Identification". Devices and their sub-components are
characterized by the power-related attributes of a physical
entity present in the ENTITY MIB [RFC6933].
2) The Context Information. See Section 5.2 "Energy Object
Context"
3) The links to other MIB modules. See Section 5.3 "Links to
other Identifiers"
4) The Energy Object Relationships specific information. See
Section 5.4
5) The Energy Object Identity Persistence. See Section 5.5
"Energy Object Identity Persistence"
5.1 Energy Object Identification
Refer to the "Energy Object Information" section in [EMAN-FMWK]
for background information about Energy Objects.
Every Energy Object MUST implement the unique index,
entPhysicalIndex, entPhysicalName and entPhysicalUUID from the
ENTITY MIB [RFC6933]. Module Compliance with respect to
entity4CRCompliance of ENTITY-MIB should be supported which
require a limited number of objects supported (entPhysicalClass,
entPhysicalName, entPhysicalUUID). entPhysicalIndex is used as
index for the primary Energy Object information in the ENERGY-
OBJECT-CONTEXT-MIB module.
Every Energy Object MUST have a printable name assigned to it.
Energy Objects MUST implement the entPhysicalName object
specified in the ENTITY-MIB [RFC6933], which must contain the
Energy Object name.
<Parello, Claise> Expires May 29, 2014 [Page 8]
Internet-Draft < Energy Object Context MIB > November 2013
For the ENERGY-OBJECT-CONTEXT-MIB compliance, every Energy
Object instance MUST implement the entPhysicalUUID from the
ENTITY MIB [RFC6933].
As displayed in [RFC4122], the following is an example of the
string representation of a UUID as a URN: urn:uuid:f81d4fae-
7dec-11d0-a765-00a0c91e6bf6.
For example, to understand the relationship between Energy
Object Components and Energy Objects, the ENTITY-MIB physical
containment tree [RFC6933] MUST be implemented.
A second example deals with one of the ENTITY-MIB extensions: if
the Energy Object temperature is required, the managed objects
from the ENTITY-SENSOR-MIB [RFC3433] should be supported.
Each Energy Object MUST belong to a single Energy Management
Domain or in other words, an Energy Object cannot belong to more
than one Energy Management Domain. Refer to the "Energy
Management Domain" section in [EMAN-FMWK] for background
information. The eoDomainName, which is an element of the
eoTable, is a read-write MIB object. The Energy Management
Domain should map 1-1 with a metered or sub-metered portion of
the network. The Energy Management Domain MUST be configured on
the Energy Object. The Energy Object MAY inherit the some of the
domain parameters (possibly domain name, some of the context
information such as role or keywords, importance) from the
Energy Object or the Energy Management Domain MAY be configured
directly in an Energy Object.
When an Energy Object acts as a Power Aggregator, the Energy
Objects for which Power should be aggregated MUST be members of
the same Energy Management Domain, specified by the eoDomainName
MIB Object.
5.2 Energy Object Context
Refer to the "Energy Object Context" section in [EMAN-FMWK] for
background information.
An Energy Object must provide a value for eoImportance in the
range of 1...100 to help differentiate the use or relative value
of the device. The importance range is from 1 (least important)
to 100 (most important). The default importance value is 1.
<Parello, Claise> Expires May 29, 2014 [Page 9]
Internet-Draft < Energy Object Context MIB > November 2013
An Energy Object can provide a set of eoKeywords. These keywords
are a list of tags that can be used for grouping and summary
reporting within or between Energy Management Domains.
An Energy Object can have Power Interfaces and those interfaces
can be classified as Power Inlet, Power Outlet or both.
An Energy Object can be classified based on the physical
properties of the Energy Object. That Energy Object can be
classified as consuming power or supplying power to other
devices or that Energy Object can perform both of those
functions and finally, an Energy Object can be a passive meter.
Additionally, an Energy Object can provide an eoRoleDescription
string that indicates the purpose the Energy Object serves in
the network.
5.3 Links to Other Identifiers
While the entPhysicalIndex is the primary index for all MIB
objects in the ENERGY-OBJECT-CONTEXT-MIB module, the Energy
Management Systems (EnMS) must be able to make the link with the
identifier(s) in other supported MIB modules.
If the Energy Object is a Power over Ethernet (PoE) port, and if
the Power over Ethernet MIB [RFC3621] is supported by the Energy
Object SNMP agent, then the Energy Object eoethPortIndex and
eoethPortGrpIndex MUST contain the values of pethPsePortIndex
and pethPsePortGroupIndex [RFC3621].
The Energy Object eoLldpPortNumber MUST contain the
lldpLocPortNum from the LLDP MIB [LLDP-MIB], if the LLDP-MED
MIB is supported on the Energy Object SNMP agent.
The intent behind the links to the other MIB module
identifier(s) is to correlate the instances in the different MIB
modules. This will allow the ENERGY-OBJECT-CONTEXT-MIB module to
reference other MIB modules in cases where the Power over
Ethernet and the LLDP MIB modules are supported by the SNMP
agent. Some use cases may not implement any of these two MIB
modules for the Energy Objects. However, in situation where any
of these two MIB modules are implemented, the EnMS must be able
to correlate the instances in the different MIB modules.
The eoAlternateKey alternate key object specifies a manufacturer
defined string that can be used to identify the Energy Object.
Since an EnMS may need to correlate objects across management
<Parello, Claise> Expires May 29, 2014 [Page 10]
Internet-Draft < Energy Object Context MIB > November 2013
systems, this alternate key is provided to facilitate such a
link. This optional value is intended as a foreign key or
alternate identifier for a manufacturer or EnMS to use to
correlate the unique Energy Object Id in other systems or
namespaces. If an alternate key is not available or is not
applicable then the value is the zero-length string.
5.4 Energy Object Relationships
Refer to the "Energy Object Relationships" section in [EMAN-
FMWK] for the definition and background information.
In order to link two Energy Objects a separate table
(eoRelationTable) has been introduced in this MIB module. The
following relationships between Energy objects have been
considered in the eoRelationTable.
Metering Relationship -> meteredBy / metering
Power Source Relationship -> poweredBy / powering
Aggregation Relationship -> aggregatedBy / aggregating
Each Energy object can have one or more Energy Object
relationships with other Energy Objects. The relations between
Energy Objects are specified in eoRelationTable. The
relationship between the Energy Objects is specified with an
arbitrary index and the UUID of the remote Energy Object. The
UUID MUST comply to the RFC 4122 specifications. It is
important to note that it is possible that an Energy Object may
not have an Energy Object relationship with other Energy
Objects.
The IANA Energy Relationship MIB module specifies the first
version of the IANA-maintained definitions of relationships
between Energy Objects, as textual conventions. This way, for
Energy Relationships, new textual conventions can be specified,
without updating the primary Energy Object Context MIB module.
Since the communication between the Energy Objects may not be
SNMP and is left to the choice of the device manufacturer, an
Energy Object can have additional MIB objects that can be used
for easier identification by the EnMS. The optional objects
eoMgmtMacAddress, eoMgmtAddressType eoMgmtDNSName can be used to
help identify the relationship between the Energy Objects and
other NMS objects. These objects can be used as an alternate
<Parello, Claise> Expires May 29, 2014 [Page 11]
Internet-Draft < Energy Object Context MIB > November 2013
key to help link the Energy Object with other keyed information
that may be stored within the EnMS(s). For the optional objects
that may not be included in some vendor implementations, the
expected behavior when those objects are polled is a response
noSuchInstance.
5.5 Energy Object Identity Persistence
In some situations, the Energy Object identity information
should be persistent even after a device reload. For example, in
a static setup where a switch monitors a series of connected PoE
phones, there is a clear benefit for the EnMS if the Energy
Object Identification and all associated information persist, as
it saves a network discovery. However, in other situations,
such as a wireless access point monitoring the mobile user PCs,
there is not much advantage to persist the Energy Object
Information. The identity information of an Energy Object
should be persisted and there is value in the writable MIB
objects persisted.
6. MIB Definitions
-- ************************************************************
--
--
-- This MIB is used for describing the identity and the
-- context information of Energy Objects in network
--
--
-- *************************************************************
ENERGY-OBJECT-CONTEXT-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY,
OBJECT-TYPE,
mib-2,
Integer32
FROM SNMPv2-SMI
TEXTUAL-CONVENTION, MacAddress, TruthValue
FROM SNMPv2-TC
MODULE-COMPLIANCE,
OBJECT-GROUP
<Parello, Claise> Expires May 29, 2014 [Page 12]
Internet-Draft < Energy Object Context MIB > November 2013
FROM SNMPv2-CONF
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB
InetAddressType, InetAddress
FROM INET-ADDRESS-MIB
entPhysicalIndex
FROM ENTITY-MIB
UUIDorZero
FROM UUID-TC-MIB
IANAEnergyRelationship
FROM IANA-ENERGY-RELATION-MIB;
energyAwareMIB MODULE-IDENTITY
LAST-UPDATED "201311290000Z"
ORGANIZATION "IETF EMAN Working Group"
CONTACT-INFO
"WG Charter:
http://datatracker.ietf.org/wg/eman/charter/
Mailing Lists:
General Discussion: eman@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/eman
Archive: http://www.ietf.org/mail-archive/web/eman
Editors:
John Parello
Cisco Systems, Inc.
3550 Cisco Way
San Jose, California 95134
US
Phone: +1 408 525 2339
Email: jparello@cisco.com
Benoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
Degem 1831
Belgium
Phone: +32 2 704 5622
Email: bclaise@cisco.com
Mouli Chandramouli
<Parello, Claise> Expires May 29, 2014 [Page 13]
Internet-Draft < Energy Object Context MIB > November 2013
Cisco Systems, Inc.
Sarjapur Outer Ring Road
Bangalore 560103
IN
Phone: +91 80 4429 2409
Email: moulchan@cisco.com"
DESCRIPTION
"This MIB is used for describing the identity and the
context information of Energy Objects"
REVISION
"201311290000Z"
DESCRIPTION
"Initial version, published as RFC XXXX."
::= { energyMIB 1 }
energyAwareMIBNotifs OBJECT IDENTIFIER
::= { energyAwareMIB 0 }
energyAwareMIBObjects OBJECT IDENTIFIER
::= { energyAwareMIB 1 }
energyAwareMIBConform OBJECT IDENTIFIER
::= { energyAwareMIB 2 }
-- Textual Conventions
PethPsePortIndexOrZero ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"This textual convention is an extension of the
pethPsePortIndex convention, which defines a greater than
zero value used to identify a power Ethernet PSE port.
This extension permits the additional value of zero. The
semantics of the value zero are object-specific and must,
therefore, be defined as part of the description of any
object that uses this syntax. Examples of the usage of
this extension are situations where none or all physical
entities need to be referenced."
SYNTAX Integer32 (0..2147483647)
<Parello, Claise> Expires May 29, 2014 [Page 14]
Internet-Draft < Energy Object Context MIB > November 2013
PethPsePortGroupIndexOrZero ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"This textual convention is an extension of the
pethPsePortGroupIndex convention from the Power Over
Ethernet MIB [RFC3621], which defines a greater than zero
value used to identify group containing the port to which
a power Ethernet PSE is connected. This extension
permits the additional value of zero. The semantics of
the value zero are object-specific and must, therefore,
be defined as part of the description of any object that
uses this syntax. Examples of the usage of this
extension are situations where none or all physical
entities need to be referenced."
SYNTAX Integer32 (0..2147483647)
LldpPortNumberOrZero ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"This textual convention is an extension of the
LldpPortNumber convention specified in the LLDP MIB,
which defines a greater than zero value used to uniquely
identify each port contained in the chassis (that is
known to the LLDP agent) by a port number. This
extension permits the additional value of zero. The
semantics of the value zero are object-specific and must,
therefore, be defined as part of the description of any
object that uses this syntax. Examples of the usage of
this extension are situations where none or all physical
entities need to be referenced."
SYNTAX Integer32(0..4096)
EnergyObjectKeywordList ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A list of keywords that can be used to group Energy
Objects for reporting or searching. If multiple keywords
are present, then this string will contain all the
keywords separated by the ',' character. All alphanumeric
<Parello, Claise> Expires May 29, 2014 [Page 15]
Internet-Draft < Energy Object Context MIB > November 2013
characters and symbols (other than a comma), such as #,
(, $, !, and &, are allowed. White spaces before and
after the commas are ignored, as well as within a keyword
itself.
For example, if an Energy Object were to be tagged with
the keyword values 'hospitality' and 'guest', then the
keyword list will be 'hospitality,guest'."
SYNTAX OCTET STRING (SIZE (0..2048))
-- Objects
eoTable OBJECT-TYPE
SYNTAX SEQUENCE OF EoEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table lists Energy Objects."
::= { energyAwareMIBObjects 1 }
eoEntry OBJECT-TYPE
SYNTAX EoEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry describes the attributes of an Energy Object.
Whenever a new Energy Object is added or an existing
Energy Object is deleted, a row in the eoTable is added
or deleted."
INDEX {entPhysicalIndex }
::= { eoTable 1 }
EoEntry ::= SEQUENCE {
eoEthPortIndex PethPsePortIndexOrZero,
eoEthPortGrpIndex PethPsePortGroupIndexOrZero,
eoLldpPortNumber LldpPortNumberOrZero,
eoMgmtMacAddress MacAddress,
eoMgmtAddressType InetAddressType,
eoMgmtAddress InetAddress,
eoMgmtDNSName SnmpAdminString,
eoDomainName SnmpAdminString,
eoRoleDescription SnmpAdminString,
eoKeywords EnergyObjectKeywordList,
eoImportance Integer32,
eoPowerCategory INTEGER,
<Parello, Claise> Expires May 29, 2014 [Page 16]
Internet-Draft < Energy Object Context MIB > November 2013
eoAlternateKey SnmpAdminString,
eoPowerInterfaceType INTEGER
}
eoEthPortIndex OBJECT-TYPE
SYNTAX PethPsePortIndexOrZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This variable uniquely identifies the power Ethernet
port to which the attached device is connected [RFC3621].
In addition, PoE MIB should be instantiated on the
device. If such a power Ethernet port cannot be specified
or is not known then the object is zero."
::= { eoEntry 1 }
eoEthPortGrpIndex OBJECT-TYPE
SYNTAX PethPsePortGroupIndexOrZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This variable uniquely identifies the group containing
the port to which a power Ethernet PSE is connected
[RFC3621]. In addition, PoE MIB should be instantiated on
the device. If such a group cannot be specified or is not
known then the object is zero."
::= { eoEntry 2 }
eoLldpPortNumber OBJECT-TYPE
SYNTAX LldpPortNumberOrZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This variable uniquely identifies the port component
(contained in the local chassis with the LLDP agent) as
defined by the lldpLocPortNum in the [LLDP-MIB] and
[LLDP-MED-MIB]. In addition, LLDP MIB should be
instantiated on the device If such a port number cannot
be specified or is not known then the object is zero."
::= { eoEntry 3 }
eoMgmtMacAddress OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object specifies a MAC address of the Energy
Object."
<Parello, Claise> Expires May 29, 2014 [Page 17]
Internet-Draft < Energy Object Context MIB > November 2013
::= { eoEntry 4 }
eoMgmtAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object specifies the eoMgmtAddress type, i.e. an
IPv4 address or an IPv6 address. This object MUST be
populated when eoMgmtAddress is populated."
::= { eoEntry 5 }
eoMgmtAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object specifies the management address as an IPv4
address or IPv6 address of Energy Object. The IP address
type, i.e. IPv4 or IPv6, is determined by the
eoMgmtAddressType value. This object can be used as an
alternate key to help link the Energy Object with other
keyed information that may be stored within the EnMS(s)."
::= { eoEntry 6 }
eoMgmtDNSName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object specifies the DNS name of the eoMgmtAddress.
This object can be used as an alternate key to help link
the Energy Object with other keyed information that may
be stored within the EnMS(s)."
::= { eoEntry 7 }
eoDomainName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object specifies the name of an Energy Management
Domain for the Energy Object. This object specifies a
zero-length string value if no Energy Management Domain
name is configured. The value of eoDomainName must remain
constant at least from one re-initialization of the
entity local management system to the next re-
initialization."
<Parello, Claise> Expires May 29, 2014 [Page 18]
Internet-Draft < Energy Object Context MIB > November 2013
::= { eoEntry 8 }
eoRoleDescription OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object specifies an administratively assigned name
to indicate the purpose an Energy Object serves in the
network.
For example, we can have a phone deployed to a lobby with
eoRoleDescription as 'Lobby phone'.
This object specifies the value is the zero-length string
value if no role description is configured.
The value of eoRoleDescription must remain constant at
least from one re-initialization of the entity local
management system to the next re-initialization. "
::= { eoEntry 9 }
eoKeywords OBJECT-TYPE
SYNTAX EnergyObjectKeywordList
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object specifies a list of keywords that can be
used to group Energy Objects for reporting or searching.
The value is the zero-length string if no keywords have
been configured. If multiple keywords are present, then
this string will contain all the keywords separated by
the ',' character. For example, if an Energy Object were
to be tagged with the keyword values 'hospitality' and
'guest', then the keyword list will be
'hospitality,guest'.
If write access is implemented and a value is written
into the instance, the agent must retain the supplied
value in the eoKeywords instance associated with
the same physical entity for as long as that entity
remains instantiated. This includes instantiations
across all re-initializations/reboots of the local
management agent. "
::= { eoEntry 10 }
eoImportance OBJECT-TYPE
SYNTAX Integer32 (1..100)
MAX-ACCESS read-write
<Parello, Claise> Expires May 29, 2014 [Page 19]
Internet-Draft < Energy Object Context MIB > November 2013
STATUS current
DESCRIPTION
"This object specifies a ranking of how important the
Energy Object is (on a scale of 1 to 100) compared with
other Energy Objects in the same Energy Management
Domain. The ranking should provide a business or
operational context for the Energy Object as compared to
other similar Energy Objects. This ranking could be used
as input for policy-based network management.
Although network managers must establish their own
ranking, the following is a broad recommendation:
90 to 100 Emergency response
80 to 90 Executive or business critical
70 to 79 General or Average
60 to 69 Staff or support
40 to 59 Public or guest
1 to 39 Decorative or hospitality
The value of eoImportance must remain constant at least
from one re-initialization of the entity local
management system to the next re-initialization. "
DEFVAL { 1 }
::= { eoEntry 11 }
eoPowerCategory OBJECT-TYPE
SYNTAX INTEGER {
consumer(0),
producer(1),
meter(2),
distributor(3),
store(4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object describes the Energy Object category, which
indicates the expected behavior or physical property of
the Energy Object, based on its design. An Energy Object
can be a consumer(0), producer(1), meter(2),
distributor(3) or store(4).
In some cases, a meter is required to measure the power
consumption. In such a case, this meter Energy Object
category is meter(2). If a device is functioning as a
distributor of Energy that category of the Energy Object
<Parello, Claise> Expires May 29, 2014 [Page 20]
Internet-Draft < Energy Object Context MIB > November 2013
is distributor (3). If a device is a store of electric
Energy the category of the device can be store (4). "
::= { eoEntry 12 }
eoAlternateKey OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object specifies a manufacturer defined string that
can be used to identify the Energy Object. Since Energy
Management Systems (EnMS) and Network Management Systems
(NMS) may need to correlate objects across management
systems, this alternate key is provided to provide such a
link. This optional value is intended as a foreign key or
alternate identifier for a manufacturer or EnMS/NMS to
use to correlate the unique Energy Object Id in other
systems or namespaces. If an alternate key is not
available or is not applicable then the value is the
zero-length string.
The value of eoAlternateKey must remain constant at
least from one re-initialization of the entity local
management system to the next re-initialization. "
::= { eoEntry 13 }
eoPowerInterfaceType OBJECT-TYPE
SYNTAX INTEGER {
inlet(0),
outlet(1),
both(2)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object describes the Power Interface for an Energy
Object. A Power Interface is an interface at which a
Energy Object is connected to a power transmission
medium, at which it can in turn receive power, provide
power, or both. A Power Interface type can be an inlet(0)
or outlet(1) or both(2), respectively."
::= { eoEntry 14 }
eoRelationTable OBJECT-TYPE
SYNTAX SEQUENCE OF EoRelationEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
<Parello, Claise> Expires May 29, 2014 [Page 21]
Internet-Draft < Energy Object Context MIB > November 2013
"This table describes the relationships between Energy
Objects."
::= { energyAwareMIBObjects 2 }
eoRelationEntry OBJECT-TYPE
SYNTAX EoRelationEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in this table describes the relationship
between Energy objects."
INDEX { entPhysicalIndex, eoRelationIndex }
::= { eoRelationTable 1 }
EoRelationEntry ::= SEQUENCE {
eoRelationIndex Integer32,
eoRelationID UUIDorZero,
eoRelationship IANAEnergyRelationship
}
eoRelationIndex OBJECT-TYPE
SYNTAX Integer32 (0..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object is an arbitrary index to identify the Energy
Object related to another Energy Object"
::= { eoRelationEntry 1 }
eoRelationID OBJECT-TYPE
SYNTAX UUIDorZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object specifies the Universally Unique Identifier
(UUID) of the peer (other) Energy Object. The UUID must
comply the specifications of UUID in UUID-TC-MIB.
If UUID of the energy object is unknown or non-existent,
the eoRelationID will be set to a zero-length string
instead."
REFERENCE
"RFC 6933, Entity MIB - version 4, May 2013 "
::= { eoRelationEntry 2 }
<Parello, Claise> Expires May 29, 2014 [Page 22]
Internet-Draft < Energy Object Context MIB > November 2013
eoRelationship OBJECT-TYPE
SYNTAX IANAEnergyRelationship
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object describes the relations between Energy
objects. For each Energy object, the relations between
the other Energy objects are specified using the bitmap."
::= { eoRelationEntry 3 }
-- Conformance
energyAwareMIBCompliances OBJECT IDENTIFIER
::= { energyAwareMIBConform 1 }
energyAwareMIBGroups OBJECT IDENTIFIER
::= { energyAwareMIBConform 2 }
energyAwareMIBFullCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"When this MIB is implemented with support for
read-write, then such an implementation can
claim full compliance. Such devices can then
be both monitored and configured with this MIB."
MODULE -- this module
MANDATORY-GROUPS {
energyAwareMIBTableGroup,
energyAwareRelationTableGroup
}
GROUP energyAwareOptionalMIBTableGroup
DESCRIPTION
"A compliant implementation does not have to
implement. Module Compliance of ENTITY-MIB
with respect to entity4CRCompliance should
be supported. "
::= { energyAwareMIBCompliances 1 }
energyAwareMIBReadOnlyCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"When this MIB is implemented without support for
read-write (i.e. in read-only mode), then such an
implementation can claim read-only compliance.
<Parello, Claise> Expires May 29, 2014 [Page 23]
Internet-Draft < Energy Object Context MIB > November 2013
Such a device can then be monitored but cannot be
Configured with this MIB.
Module Compliance of ENTITY-MIB with respect to
entity4CRCompliance should be supported."
MODULE -- this module
MANDATORY-GROUPS {
energyAwareMIBTableGroup,
energyAwareRelationTableGroup
}
GROUP energyAwareOptionalMIBTableGroup
DESCRIPTION
"A compliant implementation does not have to implement
the managed objects in this GROUP.
Module Compliance of ENTITY-MIB
with respect to entity4CRCompliance should
be supported. "
::= { energyAwareMIBCompliances 2 }
-- Units of Conformance
energyAwareMIBTableGroup OBJECT-GROUP
OBJECTS {
eoDomainName,
eoRoleDescription,
eoAlternateKey,
eoKeywords,
eoImportance,
eoPowerCategory,
eoPowerInterfaceType
}
STATUS current
DESCRIPTION
"This group contains the collection of all the objects
related to the EnergyObject.
Module Compliance of ENTITY-MIB
with respect to entity4CRCompliance should
be supported. "
::= { energyAwareMIBGroups 1 }
energyAwareOptionalMIBTableGroup OBJECT-GROUP
OBJECTS {
eoEthPortIndex,
eoEthPortGrpIndex,
eoLldpPortNumber,
eoMgmtMacAddress,
eoMgmtAddressType,
<Parello, Claise> Expires May 29, 2014 [Page 24]
Internet-Draft < Energy Object Context MIB > November 2013
eoMgmtAddress,
eoMgmtDNSName
}
STATUS current
DESCRIPTION
"This group contains the collection of all the objects
related to the Energy Object."
::= { energyAwareMIBGroups 2 }
energyAwareRelationTableGroup OBJECT-GROUP
OBJECTS {
-- Note that object eoRelationIndex is not
-- included since it is not-accessible
eoRelationID,
eoRelationship
}
STATUS current
DESCRIPTION
"This group contains the collection of all objects
specifying the relationship between Energy Objects."
::= { energyAwareMIBGroups 3 }
END
IANA-ENERGY-RELATION-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, mib-2
FROM SNMPv2-SMI
TEXTUAL-CONVENTION
FROM SNMPv2-TC;
ianaEnergyRelationMIB MODULE-IDENTITY
LAST-UPDATED "201306300000Z" -- June 30, 2013
ORGANIZATION "IANA"
CONTACT-INFO "
Internet Assigned Numbers Authority
Postal: ICANN
4676 Admiralty Way, Suite 330
Marina del Rey, CA 90292
Tel: +1-310-823-9358
EMail: iana&iana.org"
DESCRIPTION
"This MIB module defines a TEXTUAL-CONVENTION that
describes the relationships between Energy Objects.
<Parello, Claise> Expires May 29, 2014 [Page 25]
Internet-Draft < Energy Object Context MIB > November 2013
Copyright (C) The IETF Trust (2013).
The initial version of this MIB module was published in
RFC yyyy; for full legal notices see the RFC itself.
Supplementary information may be available at
http://www.ietf.org/copyrights/ianamib.html"
REVISION "201306300000Z" -- June 30, 2013
DESCRIPTION "Initial version of this MIB as published in
RFC yyyy."
::= { energyMIB 2 }
-- RFC Editor, please replace xxx with the IANA allocation
-- for this MIB module and yyyy with the number of the
-- approved RFC
-- Textual Conventions
IANAEnergyRelationship ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"An enumerated value specifies the type of
relationship between Energy Objects.
The enumeration 'poweredBy' is applicable if the
Energy Object A is poweredBy Energy Object B.
The enumeration 'powering' is applicable if the
Energy Object A is powering Energy Object B.
The enumeration 'meteredBy' is applicable if the
Energy Object A is meteredBy Energy Object B.
The enumeration 'metering' is applicable if the
Energy Object A is metering Energy Object B.
The enumeration 'aggregatedBy' is applicable if the
Energy Object A is aggregatedBy Energy Object B.
The enumeration 'aggregating' is applicable if the
Energy Object A is aggregating Energy Object B."
SYNTAX INTEGER {
poweredBy(1), -- power relationship
powering(2),
<Parello, Claise> Expires May 29, 2014 [Page 26]
Internet-Draft < Energy Object Context MIB > November 2013
meteredBy(3), -- meter relationship
metering(4),
aggregatedBy(5), -- aggregation relationship
aggregating(6)
}
END
7. Implementation Status
[Note to RFC Editor: Please remove this section and the
reference to [RFC6982] before publication.]
This section records the status of known implementations of the
EMAN-Monitoring MIB at the time of posting of this Internet-
Draft, and is based on a proposal described in [RFC6982].
The description of implementations in this section is intended
to assist the IETF in its decision processes in progressing
drafts to RFCs.
11.1 SNMP Research
Organization: SNMP Research, Inc.
Maturity: Prototype based upon early drafts of the MIBs.
We anticipate updating it to more recent
documents as development schedules allow.
Coverage: Code was generated to implement all MIB objects
in ENTITY-MIB (Version 4),
ENERGY-OBJECT-CONTEXT-MIB,
ENERGY-OBJECT-MIB,
POWER-CHARACTERISTICS-MIB,
and BATTERY-MIB.
Implementation experience: The documents are implementable.
Comments: Technical comments about the
ENERGY-OBJECT-CONTEXT-MIB,
ENERGY-OBJECT-MIB, and
BATTERY-MIB
were submitted to the EMAN Working Group
E-mail list.
Licensing: Proprietary, royalty licensing
<Parello, Claise> Expires May 29, 2014 [Page 27]
Internet-Draft < Energy Object Context MIB > November 2013
Contact: Alan Luchuk, luchuk at snmp.com
URL: http://www.snmp.com/
11.2 Python
Priyanka Rao mentioned on the mailing list
(http://www.ietf.org/mail-archive/web/eman/current/msg02063.html)
that she has got an python implementation.
8. Security Considerations
Some of the readable objects in these MIB modules (i.e., objects
with a MAX-ACCESS other than not-accessible) may be considered
sensitive or vulnerable in some network environments. It is
thus important to control even GET and/or NOTIFY access to these
objects and possibly to even encrypt the values of these objects
when sending them over the network via SNMP.
There are a number of management objects defined in these MIB
modules with a MAX-ACCESS clause of read-write and/or read-
create. Such objects MAY be considered sensitive or vulnerable
in some network environments. The support for SET operations in
a non-secure environment without proper protection can have a
negative effect on network operations. The following are the
tables and objects and their sensitivity/vulnerability:
. Unauthorized changes to the eoDomainName, entPhysicalName,
eoRoleDescription, eoKeywords, and/or eoImportance MAY
disrupt power and energy collection, and therefore any
predefined policies defined in the network.
SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example, by using
IPsec), there is still no secure control over who on the secure
network is allowed to access and GET/SET
(read/change/create/delete) the objects in these MIB modules.
It is RECOMMENDED that implementers consider the security
features as provided by the SNMPv3 framework (see [RFC3410],
section 8), including full support for the SNMPv3 cryptographic
mechanisms (for authentication and privacy).
<Parello, Claise> Expires May 29, 2014 [Page 28]
Internet-Draft < Energy Object Context MIB > November 2013
Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to
an instance of these MIB modules is properly configured to give
access to the objects only to those principals (users) that have
legitimate rights to GET or SET (change/create/delete) them.
9. IANA Considerations
The MIB modules in this document uses the following IANA-
assigned OBJECT IDENTIFIER values recorded in the SMI Numbers
registry:
Descriptor OBJECT IDENTIFIER value
---------- -----------------------
energyMIB { mib-2 xxx }
Additions to the ENERGY-OBJECT-CONTEXT-MIB module are subject to
Expert Review [RFC5226], i.e., review by one of a group of
experts designated by an IETF Area Director. The group of
experts MUST check the requested MIB objects for completeness
and accuracy of the description. Requests for MIB objects that
duplicate the functionality of existing objects SHOULD be
declined. The smallest available OID SHOULD be assigned to new
MIB objects. The specification of new MIB objects SHOULD follow
the structure specified in Section 6 and MUST be published using
a well-established and persistent publication medium.
This document defines the first version of the IANA-maintained
IANA-ENERGY-RELATION-MIB module, which allows new definitions of
relationships between Energy Objects. A Specification Required
as defined in RFC 5226 [RFC5226], is REQUIRED for each
modification of the energy relationships.
10. Acknowledgement
We would like to thank Juergen Quittek and Juergen Schoenwalder
for their suggestions on the new design of eoRelationTable which
was a proposed solution for the open issue on the representation
of Energy Object as a UUIDlist.
Many thanks to Juergen Quittek for many comments on the wording,
text and design of the MIB thus resulting in an improved draft.
<Parello, Claise> Expires May 29, 2014 [Page 29]
Internet-Draft < Energy Object Context MIB > November 2013
Many thanks to Alan Luchuk for the review of the MIB and his
comments.
In addition the authors thank Bill Mielke for his multiple
reviews, Brad Schoening and Juergen Schoenwaelder for their
suggestions and Michael Brown for dramatically improving this
draft.
11. References
11.1. Normative References
[RFC2119] S. Bradner, Key words for use in RFCs to Indicate
Requirement Levels, BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578, April
1999.
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Textual Conventions for SMIv2",
STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999.
[RFC3621] Berger, A., and D. Romascanu, "Power Ethernet MIB",
RFC3621, December 2003.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace ", RFC 4122,
July 2005.
[RFC6933] Bierman, A. Romascanu,D. Quittek, J. and M.
Chandramouli, "Entity MIB (Version 4)", RFC 6933, May
2013.
[LLDP-MIB] IEEE 802.1AB-2005, "Management Information Base
module for LLDP configuration, statistics, local system
data and remote systems data components", May 2005.
<Parello, Claise> Expires May 29, 2014 [Page 30]
Internet-Draft < Energy Object Context MIB > November 2013
[LLDP-MED-MIB] ANSI/TIA-1057, "The LLDP Management Information
Base extension module for TIA-TR41.4 media endpoint
discovery information", July 2005.
[EMAN-MON-MIB] M. Chandramouli, Schoening, B., Quittek, J.,
Dietz, T., and B. Claise "Power and Energy Monitoring
MIB", draft-ietf-eman-energy-monitoring-mib-07, October
2013.
11.2. Informative References
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet
Standard Management Framework", RFC 3410, December
2002.
[RFC3433] Bierman, A., Romascanu, D., and K.C. Norseth, "Entity
Sensor Management Information Base", RFC 3433, December
2002.
[RFC5226] Narten, T. Alverstrand, H., A. and K. McCloghrie,
"Guidelines for Writing an IANA Considerations Section
in RFCs ", BCP 26, RFC 5226, May 2008.
[RFC6988] Quittek, J., Winter, R., Dietz, T., Claise, B., and M.
Chandramouli, "Requirements for Energy Management", RFC
6988, September 2013.
[EMAN-FMWK] Claise, B., Parello, J., Schoening, B., and J.
Quittek, "Energy Management Framework", draft-ietf-
eman-framework-11, work in progress, November 2013.
[EMAN-AS] Schoening, B., Chandramouli, M, and B. Nordman,
"Energy Management (EMAN) Applicability Statement",
draft-ietf-eman-applicability-statement-04.txt, work
in progress, October 2013.
[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness
of Running Code: The Implementation Status Section",
RFC 6982, July 2013.
Authors' Addresses
Benoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
Diegem 1813
BE
<Parello, Claise> Expires May 29, 2014 [Page 31]
Internet-Draft < Energy Object Context MIB > November 2013
Phone: +32 2 704 5622
Email: bclaise@cisco.com
John Parello
Cisco Systems, Inc.
3550 Cisco Way
San Jose, California 95134
US
Phone: +1 408 525 2339
Email: jparello@cisco.com
Mouli Chandramouli
Cisco Systems, Inc.
Sarjapur Outer Ring Road
Bangalore 560103
IN
Phone: +91 80 4429 2409
Email: moulchan@cisco.com
<Parello, Claise> Expires May 29, 2014 [Page 32]