Network Working Group
Internet Engineering Task Force (IETF) J. Parello
Internet-Draft
Request for Comments: 7461 B. Claise
Intended Status:
Category: Standards Track Mouli M. Chandramouli
Expires: May 27, 2014
ISSN: 2070-1721 Cisco Systems, Inc.
Nov 27, 2014
March 2015
Energy Object Context MIB
draft-ietf-eman-energy-aware-mib-17
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 energy relationships
between devices.
Status of this 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 an Internet Standards Track document.
This document is a product 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
(IETF). It represents the consensus of six
months the IETF community. It has
received public review and may be updated, replaced, or obsoleted has been approved for publication by other
documents at any time. It the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work available in progress."
The list Section 2 of RFC 5741.
Information about the current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list status of Internet-Draft Shadow Directories can this document, any errata,
and how to provide feedback on it may be accessed obtained at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on May 27, 2014.
http://www.rfc-editor.org/info/rfc7461.
Copyright Notice
Copyright (c) 2014 2015 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 energy
relationships between 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 ....................................................2
1.1. Energy Management Document Overview .................. 3 ........................2
1.2. Conventions Used in This Document ..........................3
2. The Internet-Standard Management Framework ................ 4 ......................3
3. Terminology ............................................... 4 .....................................................4
4. Architecture Concepts Applied to the MIB Module ........... 5
4.1 .................4
4.1. Energy Object Identification .......................... 8
4.2 ...............................8
4.2. Energy Object Context ................................. 9
4.3 ......................................9
4.3. Links to Other Identifiers ........................... 10
4.4 ................................10
4.4. Energy Object Relationships .......................... 11
4.5 ...............................11
4.5. Energy Object Identity Persistence ................... 12 ........................12
5. MIB Definitions .......................................... 12 ................................................12
6. Implementation Status .................................... 28
6.2. Python ................................................. 29
7. Security Considerations .................................. 29
8. ........................................27
7. IANA Considerations ...................................... 30
9. Acknowledgement .......................................... 31
10. ............................................28
8. References .............................................. 32
10.1. .....................................................29
8.1. Normative References ............................... 32
10.2. ......................................29
8.2. Informative References ............................. 33 ....................................30
Acknowledgments ...................................................31
Authors' Addresses ................................................32
1. Introduction
The EMAN Energy Management (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 [RFC7326]. 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) (ENERGY-OBJECT-
CONTEXT-MIB) and IANA Energy Relationship (IANA-ENERGY-
RELATION-MIB) (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.
Firstly, to illustrate the importance of energy monitoring in
networks and secondly and, secondly, to list some of the important areas to be
addressed by the Energy Management Framework, Framework [RFC7326], 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 in [RFC6988], the
[RFC7326] 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 [RFC7326].
This document is based on the Energy Management Framework [RFC7326]
and meets the requirements on identification of Energy Objects and
their context and relationships as specified in the Energy Management
requirements document [RFC6988].
A second MIB module meeting the EMAN requirements [RFC6988] the
Power and Energy
Monitoring and Control MIB [EMAN-MON-MIB], for Power and Energy [RFC7460], 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 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.
1.2. 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
[RFC2119].
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. Terminology
Please refer to [RFC7326] for the definitions of the following
terminology used in this draft. document.
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
4. Architecture Concepts Applied to the MIB Module
This section describes the basic concepts specified in the Energy
Management Architecture Framework [RFC7326], 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 the identification of Energy Objects,
Objects and reporting context and relationship of an Energy Object.
The managed objects are contained in two tables tables: eoTable and
eoRelationTable.
The first table eoTable table, eoTable, focuses on the link to the other MIB
modules, on identification identification, and on the context of the Energy Object.
The second table eoRelationTable table, eoRelationTable, specifies the relationships
between Energy Objects. This is a simplified representation of the
relationship between Energy Objects.
A "smidump-style" tree presentation of the MIB modules contained in
the draft document is presented. The meaning of the three symbols in is a
compressed representation of the object's MAX-ACCESS clause clause, which
may have the following values:
"not-accessible"->"---"
"accessible-for-notify"->"--n"
"read-only"->"r-n"
"read-write"->"rwn"
+- eoTable(1)
|
+- 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 OCTET STRING 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)
+-- rwn UUIDorZero eoRelationID(2)
+-- rwn IANAEnergyRelationship eoRelationship(3)
+-- rwn RowStatus eoRelationStatus(4)
+-- rwn StorageType eoRelationStorageType(5)
The following UML Unified Modeling Language (UML) diagram illustrates the
relationship of the MIB objects in the eoTable, eoRelationTable eoRelationTable, and
ENTITY-MIB. The MIB objects describe the identity, context context, and
relationship of an Energy Object. The UML diagram furthermore diagram, furthermore,
contains objects from the ENTITY-MIB [RFC6933].
+--------------------------+
| EO Context Information |
| ------------------------ |
| eoRoleDescription |
| eoKeywords |
| eoImportance |
| eoPowerCategory |
| eoPowerInterfaceType |
| eoDomainName |
+--------------------------+
^
|
|
+------------------------------+
|--- | EO Identification |
| | ---------------------------- |
| | entPhysicalIndex (*) |
| | entPhysicalName (*) |
| | entPhysicalUUID (*) |
| | entPhysicalClass (*) |
| --------------------------------
|
| +------------------------------+
|---> | Link to other identifiers |
| |------------------------------|
| | eoEthPortIndex (**) |
| | eoEthPortGrpIndex (**) |
| | eoLldpPortNumber (***) |
| | |
| | eoMgmtMacAddress (optional) |
| | eoMgmtAddressType (optional) |
| | eoMgmtAddress (optional) |
| | eoMgmtDNSName (optional) |
| | eoAlternateKey |
| +------------------------------+
|
| +------------------------------+
|---> | EO Relationship |
| ---------------------------- |
| eoRelationIndex |
| eoRelationID |
| eoRelationship |
| eoRelationStatus |
| eoRelationStorageType |
+------------------------------+
(*) Compliance with entity4CRCompliance ENTITY MIB[RFC6933] ENTITY-MIB [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 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 ENTITY-MIB [RFC6933].
2) The Context Information. See Section 5.2 4.1 "Energy Object
Context" Context".
3) The links to other MIB modules. See Section 5.3 4.3 "Links to
other Identifiers" Other
Identifiers".
4) The Energy Object Relationships specific information. See Section 5.4
4.4 "Energy Object Relationships".
5) The Energy Object Identity Persistence. See Section 5.5 4.5 "Energy
Object Identity Persistence"
4.1 Persistence".
4.1. Energy Object Identification
Refer to the "Energy Object Information" "Identification" section in [RFC7326] for background
information about Energy Objects.
Every Energy Object MUST implement the unique index,
entPhysicalIndex, entPhysicalName, entPhysicalClass, and
entPhysicalUUID from the ENTITY MIB ENTITY-MIB [RFC6933]. Module Compliance
with respect to entity4CRCompliance of ENTITY-MIB MUST be
supported supported,
which require requires a limited number of objects supported
(entPhysicalIndex, entPhysicalName, entPhysicalClass, and
entPhysicalUUID). entPhysicalIndex is used as index for the Energy
Object 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.
For the ENERGY-OBJECT-CONTEXT-MIB compliance, every Energy Object
instance MUST implement the entPhysicalUUID from the
ENTITY MIB ENTITY-MIB
[RFC6933].
As displayed in [RFC4122], the following is an example of the string
representation of a UUID Universally Unique Identifier (UUID) as a URN: urn:uuid:f81d4fae-
7dec-11d0-a765-00a0c91e6bf6.
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 "Context: Domain" section in
[RFC7326] 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 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.
4.2
4.2. Energy Object Context
Refer to the "Energy Object Context" "Context: Domain" section in [RFC7326] for background
information.
An Energy Object must provide a value for eoImportance in the range
of 1...100 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.
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 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.
4.3
4.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 SNMP agent
managing the Energy Object, then the Energy Object Objects eoethPortIndex
and eoethPortGrpIndex MUST contain the corresponding values of
pethPsePortIndex and pethPsePortGroupIndex [RFC3621].
If the LLDP-MED MIB [LLDP-MIB] is supported by the Energy Object SNMP
agent, then the Energy Object eoLldpPortNumber MUST contain the
corresponding lldpLocPortNum from the LLDP MIB.
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 either of these two MIB modules for the Energy Objects.
However, in situation situations where any either of these two MIB modules are
implemented, the EnMS must be able to correlate the instances in the
different MIB modules.
The eoAlternateKey object specifies an alternate key string that can
be used to identify the Energy Object. Since an EnMS may need to
correlate objects across management 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
applicable, then the value is the zero-length string.
An Energy Object can have additional MIB objects that can be used for
easier identification by the EnMS. The optional objects
eoMgmtMacAddress, eoMgmtAddressType eoMgmtAddressType, and 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 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.
4.4
4.4. Energy Object Relationships
Refer to the "Energy Object Relationships" "Relationships" section in [RFC7326] for the definition
and background information.In information. In order to link two Energy Objects Objects, a
separate table (eoRelationTable) has been introduced in this MIB
module.
Each Energy object Object can have one or more Energy Object relationships
with other Energy Objects. The relationship between Energy Objects are
is specified in eoRelationTable. The relationship between the Energy
Objects is specified with the entPhysicalIndex of the Energy Object
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 following relationships between Energy objects Objects have been
considered in the eoRelationTable.
Metering Relationship -> meteredBy / metering
Power Source Relationship -> poweredBy / powering
Aggregation Relationship -> aggregatedBy / aggregating
An
Energy Object B has a "meteredBy" relationship with Energy Object A,
if the energy consumption of Energy Object B is measured by Energy
Object A. Equivalently, it is possible to indicate that Energy
Object A has a "metering" relationship with Energy Object B.
An
Energy Object B has a "poweredBy" relationship with Energy Object A,
if the power source of Energy Object B is Energy Object A.
Equivalently, it is possible to indicate that Energy Object A has a
"powering" relationship with Energy Object B.
An
Energy Object B has "aggregatedBy" relationship with Energy Object A,
if Energy Object A is an aggregation point for energy usage of Energy
Object B. Equivalently, it is possible to indicate that Energy
Object A has "aggregating" relationship with Energy Object B.
The IANA Energy Relationship MIB IANA-ENERGY-RELATION-MIB module in Section 6 5 below specifies the
first version of the IANA-maintained definitions of relationships.
This way, for Energy Relationships, new textual conventions can be
specified, without updating the primary Energy Object Context MIB
module.
4.5
4.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.
5. 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 -- RFC2578 RFC 2578
TEXTUAL-CONVENTION, MacAddress, TruthValue,
RowStatus, StorageType
FROM SNMPv2-TC -- RFC2579 RFC 2579
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF -- RFC2580 RFC 2580
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB -- RFC3411 RFC 3411
InetAddressType, InetAddress
FROM INET-ADDRESS-MIB -- RFC3291 RFC 4001
entPhysicalIndex
FROM ENTITY-MIB -- RFC6933 RFC 6933
UUIDorZero
FROM UUID-TC-MIB -- RFC6933 RFC 6933
IANAEnergyRelationship
FROM IANA-ENERGY-RELATION-MIB;
energyObjectContextMIB MODULE-IDENTITY
LAST-UPDATED "201406110000Z" "201502090000Z"
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
United States
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
Cisco Systems, Inc.
Sarjapur Outer Ring Road
Bangalore 560103
IN
India
Phone: +91 80 4429 2409
Email: moulchan@cisco.com"
DESCRIPTION
"This
"Copyright (c) 2015 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This MIB is used for describing the identity and the
context information of Energy Objects" Objects."
REVISION
"201406110000Z"
"201502090000Z"
DESCRIPTION
"Initial version, published as RFC YYYY." 7461."
::= { mib-2 xxx1 231 }
-- RFC Editor, please replace xxx1 with the IANA allocation
-- for this MIB module and YYYY with the number of the
-- approved RFC
energyObjectContextMIBNotifs OBJECT IDENTIFIER
::= { energyObjectContextMIB 0 }
energyObjectContextMIBObjects OBJECT IDENTIFIER
::= { energyObjectContextMIB 1 }
energyObjectContextMIBConform OBJECT IDENTIFIER
::= { energyObjectContextMIB 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 greater-
than-zero value used to identify a power Ethernet PSE Power
Sourcing Equipment (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)
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 in RFC 3621, which defines a greater than zero greater-than-zero
value used to identify the 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
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."
::= { energyObjectContextMIBObjects 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 OCTET STRING,
eoDomainName SnmpAdminString,
eoRoleDescription SnmpAdminString,
eoKeywords EnergyObjectKeywordList,
eoImportance Integer32,
eoPowerCategory INTEGER,
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 a Power over Enternet Ethernet device is connected . connected.
If the Power over Ethernet MIB in RFC 3621 is supported by
the SNMP agent managing the Energy Object, then the
Energy Object eoethPortIndex MUST contain the
corresponding value of pethPsePortIndex. If such a power
Ethernet port cannot be specified or is not known known, then
the object is zero."
REFERENCE
"RFC 3621 " 3621: Power Ethernet MIB"
DEFVAL { 0 }
::= { 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 over Ethernet device PSE is
connected [RFC3621]. (RFC 3621). If the Power over Ethernet MIB RFC
3621 (RFC
3621) is supported by the SNMP agent managing the Energy
Object, then the Energy Object eoEthPortGrpIndex MUST
contain the corresponding value of eoethPortGrpIndex. If
such a power Ethernet port cannot be specified or is not
known
known, then the object is zero."
REFERENCE
"RFC 3621" 3621: Power Ethernet MIB"
DEFVAL { 0 }
::= { 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] LLDP-MIB and
[LLDP-MED-MIB].
LLDP-MED-MIB. If the [LLDP-MIB] LLDP-MIB is supported by the
SNMP agent managing the Energy Object, then the Energy
Object eoLldpPortNumber MUST contain the corresponding
value of lldpLocPortNum from the [LLDP-MIB]. LLDP-MIB. If such a
port number cannot be specified or is not known known, then the
object is zero."
REFERENCE
"LLDP MIB, IEEE 802.1AB-2005, 802.1AB-2005; LLDP-MED-MIB, ANSI/TIA-1057"
DEFVAL { 0 }
::= { eoEntry 3 }
eoMgmtMacAddress OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object specifies a MAC Media Access Control (MAC) address
of the Energy Object."
::= { eoEntry 4 }
eoMgmtAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object specifies the eoMgmtAddress type, i.e. 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 OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object specifies a 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). A DNS Name must always be a
fully qualified name. This MIB uses the same encoding as
the DNS protocol."
REFERENCE
"RFC-1034 section 3.1."
::= { eoEntry 7
"RFC 1034: Domain names - concepts and facilities,
Section 3.1."
::= { 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. By default, this object
should be an empty string. The value of eoDomainName must
remain constant at least from one re-initialization of
the entity local management system to the next re-
initialization."
::= { 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 that 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. " 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. " agent."
::= { eoEntry 10 }
eoImportance OBJECT-TYPE
SYNTAX Integer32 (1..100)
MAX-ACCESS read-write
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 89 Executive or business critical
70 to 79 General or Average 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 Energy Object local
management system to the next re-initialization. " 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)
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 distributing
electric Energy, the category of the Energy Object is
distributor (3). If a device is storing electric Energy,
the category of the device can be store (4). " (4)."
::= { eoEntry 12 }
eoAlternateKey OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The eoAlternateKey object specifies an alternate key
string that can be used to identify the Energy Object.
Since Energy Management Systems (EnMS) and Network
Management Systems (NMS) (NMSs) 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 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. " 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 an
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) inlet(0),
an outlet(1), or both(2), respectively."
::= { eoEntry 14 }
eoRelationTable OBJECT-TYPE
SYNTAX SEQUENCE OF EoRelationEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table describes the relationships between Energy
Objects."
::= { energyObjectContextMIBObjects 2 }
eoRelationEntry OBJECT-TYPE
SYNTAX EoRelationEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in this table specifies the Energy relationship
between Energy objects. Energy relations between two
Energy objects are defined in the RFC7326." RFC 7326."
REFERENCE
" RFC7326, RFC 7326: Energy Management Framework, RFC abcs,
Jan 2014" Framework"
INDEX { entPhysicalIndex, eoRelationIndex }
::= { eoRelationTable 1 }
EoRelationEntry ::= SEQUENCE {
eoRelationIndex Integer32,
eoRelationID UUIDorZero,
eoRelationship IANAEnergyRelationship,
eoRelationStatus RowStatus,
eoRelationStorageType StorageType
}
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" Object."
::= { eoRelationEntry 1 }
eoRelationID OBJECT-TYPE
SYNTAX UUIDorZero
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object specifies the Universally Unique Identifier
(UUID) of the peer (other) Energy Object. The UUID must
comply with the specifications of UUID in UUID-TC-MIB.
If the UUID of the energy object Energy Object is unknown or non-existent, nonexistent,
the eoRelationID will be set to a zero-length string
instead. It is preferable that the value of
entPhysicalUUID from ENTITY-MIB is used for values for
this object."
REFERENCE
"RFC 6933, 6933: Entity MIB - version 4, May 2013 " (Version 4)"
::= { eoRelationEntry 2 }
eoRelationship OBJECT-TYPE
SYNTAX IANAEnergyRelationship
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object describes the relations between Energy
objects.
Objects. For each Energy object, Object, the relations between
the other Energy objects Objects are specified using the bitmap."
::= { eoRelationEntry 3 }
eoRelationStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status controls and reflects the creation and
activation status of a row in this table to specify energy
relationship between Energy objects. Objects.
An entry status may not be active(1) unless all objects in
the entry have the appropriate values.
No attempt to modify a row columnar object instance value
in the eoRelationTable should be issued while the value of
eoRelationStatus is active(1). The data can be destroyed by
setting up the eoRelationStatus to destroy(2)."
::= { eoRelationEntry 4 }
eoRelationStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This variable indicates the storage type for this row."
DEFVAL { nonVolatile }
::= {eoRelationEntry 5 }
-- Conformance
energyObjectContextMIBCompliances OBJECT IDENTIFIER
::= { energyObjectContextMIBConform 1 }
energyObjectContextMIBGroups OBJECT IDENTIFIER
::= { energyObjectContextMIBConform 2 }
energyObjectContextMIBFullCompliance 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 Compliance of ENTITY-MIB with respect to
entity4CRCompliance MUST be supported."
MODULE -- this module
MANDATORY-GROUPS {
energyObjectContextMIBTableGroup,
energyObjectRelationTableGroup
}
GROUP energyObjectOptionalMIBTableGroup
DESCRIPTION
"A compliant implementation does not have to
implement. "
implement."
::= { energyObjectContextMIBCompliances 1 }
energyObjectContextMIBReadOnlyCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"When this MIB is implemented without support for
read-write (i.e. (i.e., in read-only mode), then such an
implementation can claim read-only compliance.
Such a device can then be monitored but cannot be
Configured
configured with this MIB.
Module Compliance of ENTITY-MIB with respect to
entity4CRCompliance MUST be supported."
MODULE -- this module
MANDATORY-GROUPS {
energyObjectContextMIBTableGroup,
energyObjectRelationTableGroup
}
GROUP energyObjectOptionalMIBTableGroup
DESCRIPTION
"A compliant implementation does not have to implement
the managed objects in this GROUP. " GROUP."
::= { energyObjectContextMIBCompliances 2 }
-- Units of Conformance
energyObjectContextMIBTableGroup 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. " EnergyObject."
::= { energyObjectContextMIBGroups 1 }
energyObjectOptionalMIBTableGroup OBJECT-GROUP
OBJECTS {
eoEthPortIndex,
eoEthPortGrpIndex,
eoLldpPortNumber,
eoMgmtMacAddress,
eoMgmtAddressType,
eoMgmtAddress,
eoMgmtDNSName
}
STATUS current
DESCRIPTION
"This group contains the collection of all the objects
related to the Energy Object."
::= { energyObjectContextMIBGroups 2 }
energyObjectRelationTableGroup OBJECT-GROUP
OBJECTS {
eoRelationID,
eoRelationship,
eoRelationStatus,
eoRelationStorageType
}
STATUS current
DESCRIPTION
"This group contains the collection of all objects
specifying the relationship between Energy Objects."
::= { energyObjectContextMIBGroups 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 "201406110000Z" "201502090000Z" -- June 11, 2014 February 9, 2015
ORGANIZATION "IANA"
CONTACT-INFO "
Internet Assigned Numbers Authority
Postal: ICANN
4676 Admiralty Way,
12025 Waterfront Dr., Suite 330
Marina del Rey, 300
Los Angeles, CA 90292 90094
United States
Tel: +1-310-823-9358 +1-310-301-5800
EMail: iana&iana.org" iana@iana.org"
DESCRIPTION
"This
"Copyright (c) 2015 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This MIB module defines a TEXTUAL-CONVENTION that
describes the relationships between Energy Objects.
Copyright (C) The IETF Trust (2014).
The initial version of this MIB module was published in
RFC YYYY; 7461; for full legal notices see the RFC itself.
Supplementary information may be available at
http://www.ietf.org/copyrights/ianamib.html" itself."
REVISION "201406110000Z" "201502090000Z" -- June 11, 2014 February 9, 2015
DESCRIPTION "Initial version of this MIB as published in
RFC YYYY." 7461."
::= { mib-2 xxx2 232 }
-- RFC Editor, please replace xxx2 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 specifying the type of
relationship between an Energy Object A, on
which the relationship is specified, with the
Energy Object B, identified by the UUID.
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),
meteredBy(3), -- meter relationship
metering(4),
aggregatedBy(5), -- aggregation relationship
aggregating(6)
}
END
6. 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.
6.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
Contact: Alan Luchuk, luchuk at snmp.com
URL: http://www.snmp.com/
6.2. Python
Priyanka Rao has mentioned on the mailing list
(http://www.ietf.org/mail-
archive/web/eman/current/msg02063.html) that she has
a python implementation.
7. Security Considerations
There are a number of management objects defined in this MIB module
with a MAX-ACCESS clause of read-write and/or read-
create. 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 opens devices to attack. These
are the tables and objects and their sensitivity/vulnerability:
.
Unauthorized changes to the eoDomainName, entPhysicalName,
eoRoleDescription, eoKeywords, eoImportance, eoAlternateKey,
eoRelationID, eoRelationship, eoRelationStatus, and/or eoImportance
eoRelationStorageType 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 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 module.
Implementations SHOULD provide the security features described by the
SNMPv3 framework (see [RFC3410]), and implementations claiming
compliance to the SNMPv3 standard MUST include full support for
authentication and privacy via the User-based Security Model (USM)
[RFC3414] with the AES cipher algorithm [RFC3826]. Implementations
MAY also provide support for the Transport Security Model (TSM)
[RFC5591] in combination with a secure transport such as SSH
[RFC5592] or TLS/DTLS [RFC6353].
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 this MIB module 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.
In certain situations, energy and power monitoring can reveal
sensitive information about individuals' activities and habits.
Implementors of this specification should use appropriate privacy
protections as discussed in Section 9 of RFC 6988 and monitoring of
individuals and homes should only occur with proper authorization.
8.
7. IANA Considerations
The MIB modules in this document use the following IANA-assigned
OBJECT IDENTIFIER values recorded in the SMI Numbers registry:
Descriptor OBJECT IDENTIFIER value Value
---------- -----------------------
energyObjectContextMIB { mib-2 xxx1 231 }
Editor's Note (to be removed prior to publication): IANA is
requested to assign a value for "xxx1" under the 'mib-2' subtree
and to record the assignment in the SMI Numbers registry. When
the assignment has been made, the RFC Editor is asked to replace
"xxx1" (here and in the MIB module) with the assigned value and
to remove this note.
This document defines the first version of the IANA-maintained
IANA-ENERGY-RELATION-MIB IANA-
ENERGY-RELATION-MIB module, which allows new definitions of
relationships between Energy Objects.
A Specification Required as defined in RFC 5226 [RFC5226], [RFC5226] is REQUIRED for each
modification of the energy relationships.
The MIB module in this document uses the following IANA-assigned
OBJECT IDENTIFIER values recorded in the SMI Numbers registry.
Descriptor OBJECT IDENTIFIER value Value
---------- -----------------------
ianaEnergyRelationMIB { mib-2 xxx2 232 }
Editor's Note (to be removed prior to publication): IANA is
requested to assign a value for "xxx2" under the 'mib-2' subtree
and to record the assignment in the SMI Numbers registry. When
the assignment has been made, the RFC Editor is asked to replace
"xxx2" (here and in the MIB module) with the assigned value and
to remove this note.
9. 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.
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.
And finally thanks the EMAN WG chairs: Nevil Brownlee and Tom
Nadeau.
10.
8. References
10.1.
8.1. Normative References
[RFC2119] S. Bradner, Key S., "Key words for use in RFCs to Indicate
Requirement Levels, Levels", BCP 14, RFC 2119, March 1997. 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April
1999. 1999,
<http://www.rfc-editor.org/info/rfc2578>.
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD
58, RFC 2579, April 1999. 1999,
<http://www.rfc-editor.org/info/rfc2579>.
[RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Conformance Statements for SMIv2",
STD 58, RFC 2580, April 1999. 1999,
<http://www.rfc-editor.org/info/rfc2580>.
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", STD 62, RFC 3414, December 2002,
<http://www.rfc-editor.org/info/rfc3414>.
[RFC3621] Berger, A., A. and D. Romascanu, "Power Ethernet MIB",
RFC3621, RFC
3621, December 2003. 2003,
<http://www.rfc-editor.org/info/rfc3621>.
[RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The
Advanced Encryption Standard (AES) Cipher Algorithm in the
SNMP User-based Security Model", RFC 3826, June 2004,
<http://www.rfc-editor.org/info/rfc3826>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace ", Namespace", RFC 4122, July 2005.
2005, <http://www.rfc-editor.org/info/rfc4122>.
[RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model
for the Simple Network Management Protocol (SNMP)", STD
78, RFC 5591, June 2009,
<http://www.rfc-editor.org/info/rfc5591>.
[RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure
Shell Transport Model for the Simple Network Management
Protocol (SNMP)", RFC 5592, June 2009,
<http://www.rfc-editor.org/info/rfc5592>.
[RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport
Model for the Simple Network Management Protocol (SNMP)",
STD 78, RFC 6353, July 2011,
<http://www.rfc-editor.org/info/rfc6353>.
[RFC6933] Bierman, A. Romascanu,D. A., Romascanu, D., Quittek, J. J., and M.
Chandramouli, "Entity MIB (Version 4)", RFC 6933, May
2013.
[LLDP-MIB] IEEE 802.1AB-2005, "Management Information Base
module
2013, <http://www.rfc-editor.org/info/rfc6933>.
[RFC7460] Chandramouli, Claise, B., Schoening, B., Quittek, J., and
Dietz, T., "Monitoring and Control MIB for LLDP configuration, statistics, local system
data Power and remote systems data components", May 2005.
Energy", RFC 7460, March 2015,
<http://www.rfc-editor.org/info/rfc7460>.
[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
extension module for TIA-TR41.4 media endpoint discovery
information", July 2005.
[LLDP-MIB] IEEE, "Management Information Base module for LLDP
configuration, statistics, local system data and Energy Monitoring
MIB", draft-ietf-eman-energy-monitoring-mib-13,
November 2014.
10.2. remote
systems data components", IEEE 802.1AB, May 2005.
8.2. Informative References
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet Internet-
Standard Management Framework", RFC 3410, December
2002. 2002,
<http://www.rfc-editor.org/info/rfc3410>.
[RFC3433] Bierman, A., Romascanu, D., and K.C. K. Norseth, "Entity Sensor
Management Information Base", RFC 3433, December
2002. 2002,
<http://www.rfc-editor.org/info/rfc3433>.
[RFC5226] Narten, T. Alverstrand, H., A. and K. McCloghrie, H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs ", RFCs", BCP 26, RFC 5226,
May 2008. 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC6988] Quittek, J., Ed., Chandramouli, M., Winter, R., Dietz, T., Claise, B.,
and M.
Chandramouli, B. Claise, "Requirements for Energy Management", RFC
6988, September 2013. 2013,
<http://www.rfc-editor.org/info/rfc6988>.
[RFC7326] Parello, J., Claise, B., Schoening, B., and J. Quittek,
"Energy Management Framework", RFC 7326,
September, 2014. September 2014,
<http://www.rfc-editor.org/info/rfc7326>.
[EMAN-AS] Schoening, B., Chandramouli, M, M., and B. Nordman, "Energy
Management (EMAN) Applicability Statement",
draft-ietf-eman-applicability-statement-08.txt, work Work in
progress, October
Progress, draft-ietf-eman-applicability-statement-08,
December 2014.
[RFC6982] Sheffer, Y.
Acknowledgements
We would like to thank Juergen Quittek and A. Farrel, "Improving Awareness Juergen Schoenwalder for
their suggestions on the new design of
Running Code: The Implementation Status Section", RFC
6982, July 2013.
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security
Model (USM) eoRelationTable, which was a
proposed solution for version 3 the open issue on the representation of Energy
Object as a UUID list.
Many thanks to Juergen Quittek for many comments on the Simple Network
ManagementProtocol (SNMPv3)", STD 62, RFC 3414,
December 2002.
[RFC3826] Blumenthal, U., Maino, F., wording,
text, and K. McCloghrie, "The
Advanced Encryption Standard (AES) Cipher Algorithm design of the MIB thus resulting in an improved document.
Many thanks to Alan Luchuk for the SNMP User-based Security Model", RFC 3826, June
2004.
[RFC5591] Harrington, D. review of the MIB and W. Hardaker, "Transport Security
Model for his
comments.
In addition, the Simple Network Management Protocol
(SNMP)", RFC 5591, June 2009.
[RFC5592] Harrington, D., Salowey, J., authors thank Bill Mielke for his multiple reviews,
Brad Schoening and W. Hardaker, "Secure
Shell Transport Model Juergen Schoenwaelder for the Simple Network Management
Protocol (SNMP)", RFC 5592, June 2009.
[RFC6353] Hardaker, W., "Transport Layer Security (TLS)
Transport Model their suggestions, and
Michael Brown for dramatically improving this document.
Finally, thanks to the Simple Network Management
Protocol (SNMP)", RFC 6353, July 2011. EMAN WG chairs: Nevil Brownlee and Tom Nadeau.
Authors' Addresses
Benoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
Diegem 1813
BE
Belgium
Phone: +32 2 704 5622
Email:
EMail: bclaise@cisco.com
John Parello
Cisco Systems, Inc.
3550 Cisco Way
San Jose, California 95134
US
United States
Phone: +1 408 525 2339
Email:
EMail: jparello@cisco.com
Mouli Chandramouli
Cisco Systems, Inc.
Sarjapur Outer Ring Road
Bangalore 560103
IN
India
Phone: +91 80 4429 2409
Email:
EMail: moulchan@cisco.com