RFC 7461

Energy Object Context MIB

📅 published March 2015, from ietf

Energy Object Context MIB 🔌✨

Part 1 of 6 🎀 more RFC 7461 goodness is coming, bestie.

Internet Engineering Task Force (IETF) 🌸 · Request for Comments: 7461 · Category: Standards Track · ISSN: 2070-1721 · March 2015

Authors: J. Parello, B. Claise, and M. Chandramouli, all from Cisco Systems, Inc. 💅

This doc is an official Standards Track RFC, so it's a real, approved spec and not just someone's opinion 🫶. Its title is Energy Object Context MIB. The title block doesn't list anything it obsoletes or updates, so there's nothing to backfill from older versions. 🦋

Abstract ✨

okay so this doc defines a subset of a Management Information Base (MIB) 🧚 for managing energy use on devices. The module covers three things: how devices get identified, their context info, and the energy relationships between devices. It's giving organized and tidy 💖

Status of This Memo 📜

This is an Internet Standards Track document, which means it's official 👑

It comes from the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 5741 🍓

For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7461 🌈

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. 💜

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read these, because they spell out your rights and restrictions for this doc 🙈 Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, same as the Simplified BSD License says 🔥

Table of Contents 🗂️

1. Introduction ....................................................2
   1.1. Energy Management Document Overview ........................2
   1.2. Conventions Used in This Document ..........................3
2. The Internet-Standard Management Framework ......................3
3. Terminology .....................................................4
4. Architecture Concepts Applied to the MIB Module .................4
   4.1. Energy Object Identification ...............................8
   4.2. Energy Object Context ......................................9
   4.3. Links to Other Identifiers ................................10
   4.4. Energy Object Relationships ...............................11
   4.5. Energy Object Identity Persistence ........................12
5. MIB Definitions ................................................12
6. Security Considerations ........................................27
7. IANA Considerations ............................................28
8. References .....................................................29
   8.1. Normative References ......................................29
   8.2. Informative References ....................................30
Acknowledgments ...................................................31
Authors' Addresses ................................................32

1. Introduction 🧚‍♀️

The Energy Management (EMAN) standards give us a spec for Energy Management 💖 This doc defines a subset of a Management Information Base (MIB) that works with network management protocols for energy monitoring of network devices, and of devices attached to the network. It might even stretch to devices in industrial automation that have a network interface 🏭✨

The big focus of the MIB module in this doc is on identifying Energy Objects and reporting their context and relationships, as defined in [RFC7326] 🦋 So the module covers Energy Object identification, Energy Object context, and Energy Object relationships. Iconic, honestly 👑

1.1. Energy Management Document Overview 📚

This doc specifies two modules: the Energy Object Context (ENERGY-OBJECT-CONTEXT-MIB) and the IANA Energy Relationship (IANA-ENERGY-RELATION-MIB) 🌸 The Energy Object Context MIB has MIB objects for identifying Energy Objects and reporting their context and relationships. The IANA Energy Relationship MIB is the first version of the IANA-maintained definitions of relationships between Energy Objects 💅

First, the doc shows why energy monitoring matters in networks. Second, it lists some of the important areas that the Energy Management Framework [RFC7326] needs to cover. To do both, the EMAN applicability statement document [EMAN-AS] walks through several use cases and network scenarios. For each scenario it also covers the target devices for energy management, and how those devices are powered and metered 🔌 To handle those scenarios, requirements for power and energy monitoring of networking devices are specified in [RFC6988]. Building on those requirements, [RFC7326] presents a solution approach 🎀

So the scope of the MIB modules here follows the requirements in [RFC6988] and the concepts from [RFC7326] 💖 This doc is based on the Energy Management Framework [RFC7326], and it meets the requirements for identifying Energy Objects and their context and relationships in the Energy Management requirements document [RFC6988] 🫶

There's also a second MIB module that meets the EMAN requirements [RFC6988]: the Monitoring and Control MIB for Power and Energy [RFC7460] ⚡ It monitors Energy Objects for Power States and for power and energy consumption. Power State monitoring covers retrieving Power States, Power State properties, the current Power State, Power State transitions, and Power State statistics. This module also gives the Power Characteristics properties of the Power and Energy, along with optional characteristics 🧃

Last one: the applicability statement document [EMAN-AS] has the full list of use cases. It also describes what existing Energy standards have in common with 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] 🙈 These are the official requirement words, so read them carefully, periodt 💅

2. The Internet-Standard Management Framework 🏗️

If you want a detailed overview of the docs describing the current Internet-Standard Management Framework, check out section 7 of RFC 3410 [RFC3410] 📖

Managed objects get accessed through a virtual information store called the Management Information Base, or MIB 🧚 MIB objects are usually accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms 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 terms used in this 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 ✨

okay so this section takes the core ideas from the Energy Management Framework [RFC7326] and shows how they apply to the MIB modules in this doc 🫶 it's giving architecture, bestie

The ENERGY-OBJECT-CONTEXT-MIB module 🎀 is the one that handles identifying Energy Objects and describing their context and relationships. Its managed objects live in two tables: eoTable and eoRelationTable.

eoTable is all about the link to the other MIB modules, plus identification and context for the Energy Object 💅

eoRelationTable holds the relationships between Energy Objects. ngl it's a simplified version of how those relationships work 🦋

Here's a "smidump-style" tree of the MIB modules in this document 🌸 The symbols are a compressed way of showing each object's MAX-ACCESS clause. These are the possible 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)

Next up is a UML diagram 🧚 It shows how the objects in eoTable, eoRelationTable, and ENTITY-MIB fit together. The MIB objects cover the identity, context, and relationship of an Energy Object, and the diagram also pulls in 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]
 (**)  Link with the Power over Ethernet MIB [RFC3621]
 (***) Link with LLDP MIBs [LLDP-MIB] [LLDP-MED-MIB]

                 Figure 1: MIB Objects Grouping

As Figure 1 shows, the MIB objects fall into different logical groups 🌈

  1. The Energy Object Identification. See Section 5.1 "Energy Object Identification". Devices and their sub-components are described by the power-related attributes of a physical entity in the ENTITY-MIB [RFC6933] 🔥
  2. The Context Information. See Section 4.1 "Energy Object Context".
  3. The links to other MIB modules. See Section 4.3 "Links to Other Identifiers".
  4. The Energy Object Relationships specific information. See Section 4.4 "Energy Object Relationships".
  5. The Energy Object Identity Persistence. See Section 4.5 "Energy Object Identity Persistence".

4.1. Energy Object Identification

okay identification time 🪪 for background on Energy Objects, check the "Identification" section in [RFC7326] ✨

Every Energy Object MUST implement the unique index, entPhysicalIndex, entPhysicalName, entPhysicalClass, and entPhysicalUUID from the ENTITY-MIB [RFC6933]. Module Compliance with respect to entity4CRCompliance of ENTITY-MIB MUST be supported, which 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 ENERGY-OBJECT-CONTEXT-MIB compliance, every Energy Object instance MUST implement the entPhysicalUUID from the ENTITY-MIB [RFC6933] 🙈

As shown in [RFC4122], here's an example of a Universally Unique Identifier (UUID) written as a URN: urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6.

To understand how Energy Object Components relate to Energy Objects, the ENTITY-MIB physical containment tree [RFC6933] MUST be implemented 🌸

A second example is an ENTITY-MIB extension. 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 🚫 See the "Context: Domain" section in [RFC7326] for background. 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 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. Energy Object Context 💖

okay so bestie, go read the "Context: Domain" section in [RFC7326] first 🧚 it's the background tea for everything in here ✨

an Energy Object must provide an eoImportance value from 1-100 so people can tell how much the device matters 👑 1 is the least important and 100 is the most important. if you don't set one, the default is 1 💅

an Energy Object can also give you a set of eoKeywords 🏷️ these are tags you can use to group things and make summary reports, inside one Energy Management Domain or across several of them. so cute for organizing 🍓

Power Interfaces are a thing too 🔌 and they can be a Power Inlet, a Power Outlet, or both. main character wiring energy 💀

an Energy Object can also be classified by its physical properties 🔬 it can be something that consumes power, something that supplies power to other devices, or something that does both. and then there's the passive meter 📏 the whole squad 💜

oh and an Energy Object can have an eoRoleDescription string 🎀 it says what job the device does in the network. iconic 🙈

okay this one is lowkey important 🫶 entPhysicalIndex is the main index for every MIB object in the ENERGY-OBJECT-CONTEXT-MIB module, BUT the Energy Management Systems (EnMS) still need to be able to link things up with the identifiers in other MIB modules they support. that's the whole mission 🦋

if the Energy Object is a Power over Ethernet (PoE) port, and the SNMP agent managing it supports the Power over Ethernet MIB [RFC3621], then the Energy Object's eoethPortIndex and eoethPortGrpIndex MUST contain the matching values of pethPsePortIndex and pethPsePortGroupIndex [RFC3621]. no skipping this one 😭

same energy for LLDP 📡 if the Energy Object SNMP agent supports the LLDP-MED MIB [LLDP-MIB], then the Energy Object's eoLldpPortNumber MUST contain the matching lldpLocPortNum from the LLDP MIB 💖

the whole point of these links is to correlate the instances across the different MIB modules ✨ that way ENERGY-OBJECT-CONTEXT-MIB can reference the Power over Ethernet and LLDP MIB modules when the SNMP agent supports them. some use cases won't implement either of those for their Energy Objects, and that's totally fine 🌸 but if either one IS implemented, the EnMS must be able to correlate the instances across the different MIB modules. no ghosting 👻

now eoAlternateKey 🗝️ it's an alternate key string that can identify the Energy Object. since an EnMS sometimes needs to correlate objects across management systems, this key is there to make that link easier. it's optional, and it's meant as a foreign key or alternate identifier that a manufacturer or EnMS can use to match the unique Energy Object Id in other systems or namespaces. if there's no alternate key, or it doesn't apply, the value is the zero-length string 🫧

an Energy Object can also have extra MIB objects that make it easier for the EnMS to identify it 🕵️‍♀️ the optional ones are eoMgmtMacAddress, eoMgmtAddressType, and eoMgmtDNSName. they help show how Energy Objects relate to other NMS objects, and they can work as an alternate key to link the Energy Object with other keyed info stored in the EnMS(s). some vendor implementations won't include every optional object, and when you poll one of those, the expected behavior is a response of noSuchInstance 🙃

4.4. Energy Object Relationships 💞

refer to the "Relationships" section in [RFC7326] for the definition and background 📖 to link two Energy Objects, this MIB module introduces a separate table called eoRelationTable.

each Energy Object can have one or more relationships with other Energy Objects 💕 those relationships live in eoRelationTable, and they're specified using the entPhysicalIndex of the Energy Object plus the UUID of the remote Energy Object. the UUID MUST comply to the RFC 4122 specifications 🔑 and it's totally possible for an Energy Object to have no relationships with other Energy Objects at all, which is fine 🌈

these are the relationships considered in eoRelationTable:

            Metering Relationship     -> meteredBy / metering

            Power Source Relationship -> poweredBy / powering

            Aggregation Relationship  -> aggregatedBy / aggregating

okay the meaning, bestie 🧠 Energy Object B has a "meteredBy" relationship with Energy Object A if A is the one measuring B's energy consumption. flip it and A has a "metering" relationship with B 📊

Energy Object B has a "poweredBy" relationship with Energy Object A if A is B's power source 🔋 and the other way around: A has a "powering" relationship with B ⚡

Energy Object B has an "aggregatedBy" relationship with Energy Object A if A is the aggregation point for B's energy usage ✨ equivalently, A has an "aggregating" relationship with B 🫶

the IANA-ENERGY-RELATION-MIB module in Section 5 below gives the first version of the IANA-maintained relationship definitions 🦋 so new textual conventions for Energy Relationships can be specified WITHOUT updating the primary Energy Object Context MIB module. big brain move 🧠💅

4.5. Energy Object Identity Persistence 🗄️

sometimes the Energy Object identity info should stay persistent even after a device reloads 🔄 for example, in a static setup where a switch monitors a bunch of connected PoE phones, it's a huge win for the EnMS if the Energy Object Identification and all the associated info persist, because it saves a network discovery. ngl that's so efficient 🥹

BUT in other situations, like a wireless access point watching mobile user PCs, there isn't much benefit to persisting the Energy Object Information 🤷‍♀️ the identity info of an Energy Object should be persisted, and there's value in the writable MIB objects being persisted too 💜

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                           -- RFC 2578
       TEXTUAL-CONVENTION, MacAddress, TruthValue,
          RowStatus, StorageType
           FROM SNMPv2-TC                            -- RFC 2579
       MODULE-COMPLIANCE,  OBJECT-GROUP
           FROM SNMPv2-CONF                          -- RFC 2580
       SnmpAdminString
           FROM SNMP-FRAMEWORK-MIB                   -- RFC 3411
       InetAddressType, InetAddress
          FROM INET-ADDRESS-MIB                      -- RFC 4001
       entPhysicalIndex
          FROM ENTITY-MIB                            -- RFC 6933
       UUIDorZero
          FROM UUID-TC-MIB                           -- RFC 6933
       IANAEnergyRelationship
          FROM IANA-ENERGY-RELATION-MIB;

   energyObjectContextMIB MODULE-IDENTITY
       LAST-UPDATED    "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
             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
             India
             Phone: +91 80 4429 2409
             Email: moulchan@cisco.com"

       DESCRIPTION
          "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."
       REVISION
           "201502090000Z"
       DESCRIPTION
          "Initial version, published as RFC 7461."

      ::= { mib-2 231 }

   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 value used to identify a power Ethernet 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
           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)

Okay so we're deep in the MIB now, bestie 🧚 These textual conventions are the building blocks everything else gets dressed in 💅

   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 Ethernet device is 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, then
           the object is zero."
        REFERENCE
           "RFC 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 (RFC 3621).  If the Power over Ethernet MIB (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, then the object is zero."
        REFERENCE
           "RFC 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 and
           LLDP-MED-MIB.  If the 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.  If such a
           port number cannot be specified or is not known, then the
           object is zero."
        REFERENCE
           "LLDP MIB, IEEE 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 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., an
           IPv4 or 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: 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."
        ::= { 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
        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 89  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 Energy Object 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).

Next up: the rest of eoPowerCategory and the remaining objects, so keep that scroll going 🦋🌸

Okay so we're picking up right where the meter stuff left off, bestie 💖 Let's go.

           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)."
        ::= { eoEntry 12    }

Next up is eoAlternateKey 🦋 It's basically a foreign key or nickname so an EnMS or NMS can match up an Energy Object with its ID in some other system. If there's nothing to put there, you just use the zero-length string, and the value has to stick around across re-initializations 🎀

    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 (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, 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 }

Now eoPowerInterfaceType 🌸 This one tells you whether an Energy Object is an inlet, an outlet, or both when it comes to the power transmission medium. Main character energy, honestly 👑

    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 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),
           an outlet(1), or both(2), respectively."
        ::= { eoEntry 14 }

Next is the relation table 🧚 It's where we describe how Energy Objects are related to each other. The relationships themselves come from RFC 7326, so go read that if you want the full story 📚

    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 RFC 7326."
        REFERENCE
           " RFC 7326: Energy Management Framework"
        INDEX        { entPhysicalIndex, eoRelationIndex }
        ::= { eoRelationTable 1 }

Here's the row structure, plus the columns for each row 💅 Each one has its own little personality, so let's meet them all ✨

    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."
        ::= { 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 is unknown or 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: Entity MIB (Version 4)"
        ::= { eoRelationEntry 2 }

    eoRelationship      OBJECT-TYPE
        SYNTAX          IANAEnergyRelationship
        MAX-ACCESS      read-create
        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 }

    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.

         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 }

Last stretch of the object stuff 🌈 This is the conformance section, where we spell out which groups count as mandatory and which ones are optional. Keep your eyes peeled for the ENTITY-MIB bit, because it shows up twice 👀

    -- 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."
        ::= { energyObjectContextMIBCompliances 1 }

    energyObjectContextMIBReadOnlyCompliance 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.
            Such a device can then be monitored but cannot be
            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."

       ::= { energyObjectContextMIBCompliances 2 }

Now the units of conformance, aka the groups that bundle all those objects together 🍓

    -- 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."

        ::= { 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

And now the IANA side of things 🎀 This module is the one that defines the relationship textual convention, and it's giving very "official but make it cute" 💜

    IANA-ENERGY-RELATION-MIB DEFINITIONS ::= BEGIN
         IMPORTS
           MODULE-IDENTITY, mib-2
               FROM SNMPv2-SMI
           TEXTUAL-CONVENTION
               FROM SNMPv2-TC;

         ianaEnergyRelationMIB MODULE-IDENTITY
           LAST-UPDATED "201502090000Z"  -- February 9, 2015
           ORGANIZATION "IANA"
           CONTACT-INFO "
                         Internet Assigned Numbers Authority
                         Postal: ICANN
                         12025 Waterfront Dr., Suite 300
                         Los Angeles, CA 90094
                         United States
                         Tel: +1-310-301-5800
                         EMail: iana@iana.org"

           DESCRIPTION
            "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.

             The initial version of this MIB module was published in
             RFC 7461; for full legal notices see the RFC itself."

           REVISION     "201502090000Z"  -- February 9, 2015
           DESCRIPTION  "Initial version of this MIB as published in
                         RFC 7461."
           ::= { mib-2 232 }

         -- 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
               Energy Object A is poweredBy Energy Object B.
               The enumeration 'powering' is applicable if
               Energy Object A is powering Energy Object B.

               The enumeration 'meteredBy' is applicable if
               Energy Object A is meteredBy Energy Object B.

               The enumeration 'metering' is applicable if
               Energy Object A is metering Energy Object B.

               The enumeration 'aggregatedBy' is applicable if
               Energy Object A is aggregatedBy Energy Object B.

               The enumeration 'aggregating' is applicable if
               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. Security Considerations 🔐

Okay bestie, this part is seriously important, so no giggling through it 😭 There are a bunch of management objects in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Those objects may be considered sensitive or vulnerable in some network environments. Supporting SET operations in a non-secure environment without proper protection opens devices up to attack. Here are the tables and objects, plus how sensitive or vulnerable each one is 👀

Unauthorized changes to the eoDomainName, entPhysicalName, eoRoleDescription, eoKeywords, eoImportance, eoAlternateKey, eoRelationID, eoRelationship, eoRelationStatus, and/or 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 over who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. Not me being shocked 🙈

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. Lock it down, babe 🔒

Energy and power monitoring can be a privacy minefield. In certain situations, it can reveal sensitive information about individuals' activities and habits, so 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. Privacy is not a vibe to skip 🫶

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
    ----------                    -----------------------
  energyObjectContextMIB              { mib-2 231 }

This document defines the first version of the IANA-maintained IANA-ENERGY-RELATION-MIB module, which allows new definitions of relationships between Energy Objects. Ooh, it's giving extensibility 🌈

A Specification Required as defined in [RFC5226] is REQUIRED for each modification of the energy relationships. No sneaky edits allowed ✨

The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry.

     Descriptor                  OBJECT IDENTIFIER Value
     ----------                  -----------------------
   ianaEnergyRelationMIB             { mib-2 232 }

8. References 📚

8.1. Normative References

8.2. Informative References

Acknowledgements 💜

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 UUID list. Brilliant brains 🧠

Many thanks to Juergen Quittek for many comments on the wording, text, and design of the MIB, thus resulting in an improved document. Such a legend 👑

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 document. Michael really ate this one up 💅

Finally, thanks to the EMAN WG chairs: Nevil Brownlee and Tom Nadeau. 🎀

Authors' Addresses 🧚

Here's where you can find the authors, bestie 💖

John Parello
Cisco Systems, Inc.
3550 Cisco Way
San Jose, California 95134
United States

Phone: +1 408 525 2339
EMail: jparello@cisco.com


Benoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
Diegem 1813
Belgium

Phone: +32 2 704 5622
EMail: bclaise@cisco.com


Mouli Chandramouli
Cisco Systems, Inc.
Sarjapur Outer Ring Road
Bangalore 560103
India

Phone: +91 80 4429 2409
EMail: moulchan@cisco.com
📦 where this page comes from