Energy Object Context MIB
Extracted elements (27)
A separate eoRelationTable was introduced rather than embedding relationship data in eoTable to allow each Energy Object to have multiple relationships with different peer objects, and to permit IANA to extend the IANAEnergyRelationship textual convention in IANA-ENERGY-RELATION-MIB without modifying the primary MIB module.
Energy Object identity information (writable MIB objects) should be persisted across device reloads in static environments (e.g., a switch monitoring fixed PoE phones) to avoid repeated network discovery, but persistence may not be valuable in dynamic environments (e.g., a wireless AP monitoring mobile PCs).
The eoAlternateKey object is provided as an optional foreign key to facilitate correlation of Energy Objects across heterogeneous management systems and namespaces that may use different primary identifiers than entPhysicalIndex or entPhysicalUUID.
Optional objects eoMgmtMacAddress, eoMgmtAddressType, and eoMgmtDNSName may not be included in some vendor implementations; the expected SNMP response when those objects are polled but not implemented is noSuchInstance.
The ENERGY-OBJECT-CONTEXT-MIB uses entPhysicalIndex from the ENTITY-MIB (RFC 6933) as its primary index and requires entity4CRCompliance, linking it tightly to ENTITY-MIB implementations. Cross-MIB correlation with PoE MIB (RFC 3621) and LLDP MIBs is required when those MIBs are supported.
Deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security.
Each Energy Object MUST belong to a single Energy Management Domain; an Energy Object cannot belong to more than one Energy Management Domain. The Energy Management Domain MUST be configured on the Energy Object.
Every Energy Object MUST have a printable name assigned to it and MUST implement the entPhysicalName object specified in the ENTITY-MIB, which must contain the Energy Object name.
Every Energy Object MUST implement the unique index entPhysicalIndex, entPhysicalName, entPhysicalClass, and entPhysicalUUID from the ENTITY-MIB (RFC 6933). Module Compliance with respect to entity4CRCompliance of ENTITY-MIB MUST be supported.
For ENERGY-OBJECT-CONTEXT-MIB compliance, every Energy Object instance MUST implement the entPhysicalUUID from the ENTITY-MIB (RFC 6933).
If the LLDP-MED MIB is supported by the Energy Object SNMP agent, then eoLldpPortNumber MUST contain the corresponding lldpLocPortNum from the LLDP MIB.
If the Power over Ethernet MIB (RFC 3621) is supported by the SNMP agent managing the Energy Object, then eoEthPortIndex and eoEthPortGrpIndex MUST contain the corresponding values of pethPsePortIndex and pethPsePortGroupIndex.
Implementations claiming compliance to the SNMPv3 standard MUST include full support for authentication and privacy via the User-based Security Model (USM) with the AES cipher algorithm (RFC 3826).
The UUID used in eoRelationID MUST comply to the RFC 4122 specifications.
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.
Energy and power monitoring can reveal sensitive information about individuals' activities and habits. Implementors should use appropriate privacy protections as discussed in RFC 6988 Section 9; monitoring of individuals and homes should only occur with proper authorization.
EnergyObjectKeywordList is a textual convention (OCTET STRING, SIZE 0..2048) holding comma-separated keyword tags used to group Energy Objects for reporting or searching; whitespace around commas is ignored.
eoImportance is a read-write Integer32 (range 1–100) ranking the relative importance of the Energy Object within its Energy Management Domain, with a default value of 1 (least important) and 100 being most important.
eoPowerCategory classifies an Energy Object as one of: consumer(0), producer(1), meter(2), distributor(3), or store(4), reflecting its expected physical behavior.
eoPowerInterfaceType describes the Power Interface for an Energy Object as inlet(0), outlet(1), or both(2), indicating whether the object receives power, provides power, or does both.
IANAEnergyRelationship is a textual convention defining six relationship types between Energy Objects: poweredBy(1), powering(2), meteredBy(3), metering(4), aggregatedBy(5), aggregating(6).
The eoRelationTable specifies relationships between Energy Objects, indexed by entPhysicalIndex and eoRelationIndex. Each entry contains eoRelationID (UUID of peer), eoRelationship (IANAEnergyRelationship bitmap), eoRelationStatus (RowStatus), and eoRelationStorageType.
The eoTable contains per-Energy-Object attributes including identification links (eoEthPortIndex, eoEthPortGrpIndex, eoLldpPortNumber), management addressing (eoMgmtMacAddress, eoMgmtAddressType, eoMgmtAddress, eoMgmtDNSName), context (eoDomainName, eoRoleDescription, eoKeywords, eoImportance), and classification (eoPowerCategory, eoPowerInterfaceType, eoAlternateKey). It is indexed by entPhysicalIndex.
This document defines the first version of the IANA-maintained IANA-ENERGY-RELATION-MIB module assigned OBJECT IDENTIFIER { mib-2 232 }. Future modifications require Specification Required per RFC 5226.
This document establishes the ENERGY-OBJECT-CONTEXT-MIB module assigned OBJECT IDENTIFIER { mib-2 231 } in the SMI Numbers registry.
SNMP versions prior to SNMPv3 did not include adequate security; even on a secure network (e.g., IPsec), there is no access control for MIB GET/SET operations. Implementations SHOULD use SNMPv3 with USM/AES and MAY additionally support TSM with SSH or TLS/DTLS.
Unauthorized changes to writable MIB objects such as eoDomainName, eoRoleDescription, eoKeywords, eoImportance, eoRelationID, and eoRelationship MAY disrupt power and energy collection and predefined network policies. SET operations without proper protection in non-secure environments open devices to attack.