idnits 2.17.1 draft-ietf-eman-energy-aware-mib-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 225 has weird spacing: '...xOrZero eoEth...' -- The document date (Nov 27, 2014) is 3437 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'LLDP-MIB' -- Possible downref: Non-RFC (?) normative reference: ref. 'LLDP-MED-MIB' -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-11) exists of draft-ietf-eman-applicability-statement-08 -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Parello 3 Internet-Draft B. Claise 4 Intended Status: Standards Track Mouli Chandramouli 5 Expires: May 27, 2014 Cisco Systems, Inc. 6 Nov 27, 2014 8 Energy Object Context MIB 9 draft-ietf-eman-energy-aware-mib-17 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance 14 with the provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet 17 Engineering Task Force (IETF), its areas, and its working 18 groups. Note that other groups may also distribute working 19 documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- 24 Drafts as reference material or to cite them other than as "work 25 in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on May 27, 2014. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with 45 respect to this document. Code Components extracted from this 46 document must include Simplified BSD License text as described 47 in Section 4.e of the Trust Legal Provisions and are provided 48 without warranty as described in the Simplified BSD License. 50 Abstract 52 This document defines a subset of a Management Information Base 53 (MIB) for energy management of devices. The module addresses 54 device identification, context information, and the energy 55 relationships between devices. 57 Conventions used in this document 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 60 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 61 RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 62 be interpreted as described in RFC 2119 [RFC2119]. 64 Table of Contents 66 1. Introduction .............................................. 3 67 1.1. Energy Management Document Overview .................. 3 68 2. The Internet-Standard Management Framework ................ 4 69 3. Terminology ............................................... 4 70 4. Architecture Concepts Applied to the MIB Module ........... 5 71 4.1 Energy Object Identification .......................... 8 72 4.2 Energy Object Context ................................. 9 73 4.3 Links to Other Identifiers ........................... 10 74 4.4 Energy Object Relationships .......................... 11 75 4.5 Energy Object Identity Persistence ................... 12 76 5. MIB Definitions .......................................... 12 77 6. Implementation Status .................................... 28 78 6.2. Python ................................................. 29 79 7. Security Considerations .................................. 29 80 8. IANA Considerations ...................................... 30 81 9. Acknowledgement .......................................... 31 82 10. References .............................................. 32 83 10.1. Normative References ............................... 32 84 10.2. Informative References ............................. 33 86 1. Introduction 88 The EMAN standards provide a specification for Energy 89 Management. This document defines a subset of a Management 90 Information Base (MIB) for use with network management protocols 91 for Energy monitoring of network devices and devices attached to 92 the network and possibly extending to devices in the industrial 93 automation setting with a network interface. 95 The focus of the MIB module specified in this document is on the 96 identification of Energy Objects and reporting the context and 97 relationships of Energy Objects as defined in [RFC7326]. The 98 module addresses Energy Object identification, Energy Object 99 context, and Energy Object relationships. 101 1.1. Energy Management Document Overview 103 This document specifies the Energy Object Context (ENERGY- 104 OBJECT-CONTEXT-MIB) and IANA Energy Relationship (IANA-ENERGY- 105 RELATION-MIB) modules. The Energy Object Context MIB module 106 specifies MIB objects for identification of Energy Objects, and 107 reporting context and relationship of an Energy Object. The IANA 108 Energy Relationship MIB module specifies the first version of 109 the IANA-maintained definitions of relationships between Energy 110 Objects. 112 Firstly, to illustrate the importance of energy monitoring in 113 networks and secondly to list some of the important areas to be 114 addressed by the Energy Management Framework, several use cases 115 and network scenarios are presented in the EMAN applicability 116 statement document [EMAN-AS]. In addition, for each scenario, 117 the target devices for energy management, and how those devices 118 powered and metered are also presented. To address the network 119 scenarios, requirements for power and energy monitoring for 120 networking devices are specified in [RFC6988]. Based on the 121 requirements [RFC6988], the [RFC7326] presents a solution 122 approach. 124 Accordingly, the scope of the MIB modules in this document is in 125 accordance to the requirements specified in [RFC6988] and the 126 concepts from [RFC7326]. 128 This document is based on the Energy Management Framework 129 [RFC7326] and meets the requirements on identification of Energy 130 Objects and their context and relationships as specified in the 131 Energy Management requirements [RFC6988]. 133 A second MIB module meeting the EMAN requirements [RFC6988] the 134 Power and Energy Monitoring MIB [EMAN-MON-MIB], monitors the 135 Energy Objects for Power States, for the Power and Energy 136 consumption. Power State monitoring includes: retrieving Power 137 States, Power State properties, current Power State, Power State 138 transitions, and Power State statistics. In addition, this MIB 139 module provides the Power Characteristics properties of the 140 Power and Energy, along with optional characteristics. 142 The applicability statement document [EMAN-AS] provides the list 143 of use cases, and describes the common aspects of between 144 existing Energy standards and the EMAN standard, and shows how 145 the EMAN framework relates to other frameworks. 147 2. The Internet-Standard Management Framework 149 For a detailed overview of the documents that describe the 150 current Internet-Standard Management Framework, please refer to 151 section 7 of RFC 3410 [RFC3410]. 153 Managed objects are accessed via a virtual information store, 154 termed the Management Information Base or MIB. MIB objects are 155 generally accessed through the Simple Network Management 156 Protocol (SNMP). Objects in the MIB are defined using the 157 mechanisms defined in the Structure of Management Information 158 (SMI). This memo specifies MIB modules that are compliant with 159 SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, 160 RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 162 3. Terminology 164 Please refer to [RFC7326] for the definitions of the following 165 terminology used in this draft. 167 Energy Management 168 Energy Management System (EnMS) 169 Energy Monitoring 170 Energy Control 171 electrical equipment 172 non-electrical equipment (mechanical equipment) 173 device 174 component 175 power inlet 176 power outlet 177 energy 178 power 179 demand 180 provide energy 181 receive energy 182 meter (energy meter) 183 battery 184 Power Interface 185 Nameplate Power 186 Power Attributes 187 Power Quality 188 Power State 189 Power State Set 191 4. Architecture Concepts Applied to the MIB Module 193 This section describes the basic concepts specified in the 194 Energy Management Architecture [RFC7326], with specific 195 information related to the MIB modules specified in this 196 document. 198 The Energy Object Context (ENERGY-OBJECT-CONTEXT-MIB) MIB module 199 in this document specifies MIB objects for identification of 200 Energy Objects, and reporting context and relationship of an 201 Energy Object. The managed objects are contained in two tables 202 eoTable and eoRelationTable. 204 The first table eoTable focuses on the link to the other MIB 205 modules, on identification and context of the Energy Object. The 206 second table eoRelationTable specifies the relationships between 207 Energy Objects. This is a simplified representation of 208 relationship between Energy Objects. 210 A "smidump-style" tree presentation of the MIB modules contained 211 in the draft is presented. The meaning of the three symbols in 212 is a compressed representation of the object's MAX-ACCESS clause 213 which may have the following values: 215 "not-accessible"->"---" 216 "accessible-for-notify"->"--n" 217 "read-only"->"r-n" 218 "read-write"->"rwn" 220 +- eoTable(1) 221 | 222 +- eoEntry(1) [entPhysicalIndex] 223 | 224 +-- r-n PethPsePortIndexOrZero eoEthPortIndex(1) 225 +-- r-n PethPsePortGroupIndexOrZero eoEthPortGrpIndex(2) 226 +-- r-n LldpPortNumberOrZero eoLldpPortNumber(3) 227 +-- rwn MacAddress eoMgmtMacAddress(4) 228 +-- r-n InetAddressType eoMgmtAddressType(5) 229 +-- r-n InetAddress eoMgmtAddress(6) 230 +-- r-n OCTET STRING eoMgmtDNSName(7) 231 +-- rwn SnmpAdminString eoDomainName(8) 232 +-- rwn SnmpAdminString eoRoleDescription(9) 233 +-- rwn EnergyObjectKeywordList eoKeywords(10) 234 +-- rwn Integer32 eoImportance(11) 235 +-- r-n INTEGER eoPowerCategory(12) 236 +-- rwn SnmpAdminString eoAlternateKey(13) 237 +-- r-n INTEGER eoPowerInterfaceType(14) 239 +- eoRelationTable(2) 240 | 241 +- eoRelationEntry(1) [entPhysicalIndex, eoRelationIndex] 242 | 243 +-- --n Integer32 eoRelationIndex(1) 244 +-- rwn UUIDorZero eoRelationID(2) 245 +-- rwn IANAEnergyRelationship eoRelationship(3) 246 +-- rwn RowStatus eoRelationStatus(4) 247 +-- rwn StorageType eoRelationStorageType(5) 249 The following UML diagram illustrates the relationship of the 250 MIB objects in the eoTable, eoRelationTable and ENTITY-MIB. The 251 MIB objects describe the identity, context and relationship of 252 an Energy Object. The UML diagram furthermore contains objects 253 from the ENTITY-MIB [RFC6933]. 255 +--------------------------+ 256 | EO Context Information | 257 | ------------------------ | 258 | eoRoleDescription | 259 | eoKeywords | 260 | eoImportance | 261 | eoPowerCategory | 262 | eoPowerInterfaceType | 263 | eoDomainName | 264 +--------------------------+ 265 ^ 266 | 267 | 268 +------------------------------+ 269 |--- | EO Identification | 270 | | ---------------------------- | 271 | | entPhysicalIndex (*) | 272 | | entPhysicalName (*) | 273 | | entPhysicalUUID (*) | 274 | | entPhysicalClass (*) | 275 | -------------------------------- 276 | 277 | +------------------------------+ 278 |---> | Link to other identifiers | 279 | |------------------------------| 280 | | eoEthPortIndex (**) | 281 | | eoEthPortGrpIndex (**) | 282 | | eoLldpPortNumber (***) | 283 | | | 284 | | eoMgmtMacAddress (optional) | 285 | | eoMgmtAddressType (optional) | 286 | | eoMgmtAddress (optional) | 287 | | eoMgmtDNSName (optional) | 288 | | eoAlternateKey | 289 | +------------------------------+ 290 | 291 | +------------------------------+ 292 |---> | EO Relationship | 293 | ---------------------------- | 294 | eoRelationIndex | 295 | eoRelationID | 296 | eoRelationship | 297 | eoRelationStatus | 298 | eoRelationStorageType | 299 +------------------------------+ 301 (*) Compliance with entity4CRCompliance ENTITY MIB[RFC6933] 302 (**) Link with the Power over Ethernet MIB [RFC3621] 303 (***) Link with LLDP MIBs [LLDP-MIB] [LLDP-MED-MIB] 305 Figure 1: MIB Objects Grouping 307 As displayed in figure 1, the MIB objects can be classified in 308 different logical grouping of MIB objects. 310 1) The Energy Object Identification. See Section 5.1 "Energy 311 Object Identification". Devices and their sub-components are 312 characterized by the power-related attributes of a physical 313 entity present in the ENTITY MIB [RFC6933]. 314 2) The Context Information. See Section 5.2 "Energy Object 315 Context" 316 3) The links to other MIB modules. See Section 5.3 "Links to 317 other Identifiers" 318 4) The Energy Object Relationships specific information. See 319 Section 5.4 320 5) The Energy Object Identity Persistence. See Section 5.5 321 "Energy Object Identity Persistence" 323 4.1 Energy Object Identification 325 Refer to the "Energy Object Information" section in [RFC7326] 326 for background information about Energy Objects. 328 Every Energy Object MUST implement the unique index, 329 entPhysicalIndex, entPhysicalName, entPhysicalClass, and 330 entPhysicalUUID from the ENTITY MIB [RFC6933]. Module Compliance 331 with respect to entity4CRCompliance of ENTITY-MIB MUST be 332 supported which require a limited number of objects supported 333 (entPhysicalIndex, entPhysicalName, entPhysicalClass, and 334 entPhysicalUUID). entPhysicalIndex is used as index for the 335 Energy Object in the ENERGY-OBJECT-CONTEXT-MIB module. 336 Every Energy Object MUST have a printable name assigned to it. 337 Energy Objects MUST implement the entPhysicalName object 338 specified in the ENTITY-MIB [RFC6933], which must contain the 339 Energy Object name. 341 For the ENERGY-OBJECT-CONTEXT-MIB compliance, every Energy 342 Object instance MUST implement the entPhysicalUUID from the 343 ENTITY MIB [RFC6933]. 345 As displayed in [RFC4122], the following is an example of the 346 string representation of a UUID as a URN: urn:uuid:f81d4fae- 347 7dec-11d0-a765-00a0c91e6bf6. 349 For example, to understand the relationship between Energy 350 Object Components and Energy Objects, the ENTITY-MIB physical 351 containment tree [RFC6933] MUST be implemented. 353 A second example deals with one of the ENTITY-MIB extensions: if 354 the Energy Object temperature is required, the managed objects 355 from the ENTITY-SENSOR-MIB [RFC3433] should be supported. 357 Each Energy Object MUST belong to a single Energy Management 358 Domain or in other words, an Energy Object cannot belong to more 359 than one Energy Management Domain. Refer to the "Energy 360 Management Domain" section in [RFC7326] for background 361 information. The eoDomainName, which is an element of the 362 eoTable, is a read-write MIB object. The Energy Management 363 Domain should map 1-1 with a metered or sub-metered portion of 364 the network. The Energy Management Domain MUST be configured on 365 the Energy Object. The Energy Object MAY inherit the some of the 366 domain parameters (possibly domain name, some of the context 367 information such as role or keywords, importance) from the 368 Energy Object or the Energy Management Domain MAY be configured 369 directly in an Energy Object. 371 When an Energy Object acts as a Power Aggregator, the Energy 372 Objects for which Power should be aggregated MUST be members of 373 the same Energy Management Domain, specified by the eoDomainName 374 MIB Object. 376 4.2 Energy Object Context 378 Refer to the "Energy Object Context" section in [RFC7326] for 379 background information. 381 An Energy Object must provide a value for eoImportance in the 382 range of 1...100 to help differentiate the use or relative value 383 of the device. The importance range is from 1 (least important) 384 to 100 (most important). The default importance value is 1. 386 An Energy Object can provide a set of eoKeywords. These keywords 387 are a list of tags that can be used for grouping and summary 388 reporting within or between Energy Management Domains. 390 An Energy Object can have Power Interfaces and those interfaces 391 can be classified as Power Inlet, Power Outlet or both. 393 An Energy Object can be classified based on the physical 394 properties of the Energy Object. That Energy Object can be 395 classified as consuming power or supplying power to other 396 devices or that Energy Object can perform both of those 397 functions and finally, an Energy Object can be a passive meter. 399 Additionally, an Energy Object can provide an eoRoleDescription 400 string that indicates the purpose the Energy Object serves in 401 the network. 403 4.3 Links to Other Identifiers 405 While the entPhysicalIndex is the primary index for all MIB 406 objects in the ENERGY-OBJECT-CONTEXT-MIB module, the Energy 407 Management Systems (EnMS) must be able to make the link with the 408 identifier(s) in other supported MIB modules. 410 If the Energy Object is a Power over Ethernet (PoE) port, and if 411 the Power over Ethernet MIB [RFC3621] is supported by the SNMP 412 agent managing the Energy Object, then the Energy Object 413 eoethPortIndex and eoethPortGrpIndex MUST contain the 414 corresponding values of pethPsePortIndex and 415 pethPsePortGroupIndex [RFC3621]. 417 If the LLDP-MED MIB [LLDP-MIB] is supported by the Energy Object 418 SNMP agent, then the Energy Object eoLldpPortNumber MUST contain 419 the corresponding lldpLocPortNum from the LLDP MIB. 421 The intent behind the links to the other MIB module 422 identifier(s) is to correlate the instances in the different MIB 423 modules. This will allow the ENERGY-OBJECT-CONTEXT-MIB module to 424 reference other MIB modules in cases where the Power over 425 Ethernet and the LLDP MIB modules are supported by the SNMP 426 agent. Some use cases may not implement any of these two MIB 427 modules for the Energy Objects. However, in situation where any 428 of these two MIB modules are implemented, the EnMS must be able 429 to correlate the instances in the different MIB modules. 431 The eoAlternateKey object specifies an alternate key string that 432 can be used to identify the Energy Object. Since an EnMS may 433 need to correlate objects across management systems, this 434 alternate key is provided to facilitate such a link. This 435 optional value is intended as a foreign key or alternate 436 identifier for a manufacturer or EnMS to use to correlate the 437 unique Energy Object Id in other systems or namespaces. If an 438 alternate key is not available or is not applicable then the 439 value is the zero-length string. 441 An Energy Object can have additional MIB objects that can be 442 used for easier identification by the EnMS. The optional objects 443 eoMgmtMacAddress, eoMgmtAddressType eoMgmtDNSName can be used to 444 help identify the relationship between the Energy Objects and 445 other NMS objects. These objects can be used as an alternate 446 key to help link the Energy Object with other keyed information 447 that may be stored within the EnMS(s). For the optional objects 448 that may not be included in some vendor implementations, the 449 expected behavior when those objects are polled is a response 450 noSuchInstance. 452 4.4 Energy Object Relationships 454 Refer to the "Energy Object Relationships" section in [RFC7326] 455 for the definition and background information.In order to link 456 two Energy Objects a separate table (eoRelationTable) has been 457 introduced in this MIB module. 459 Each Energy object can have one or more Energy Object 460 relationships with other Energy Objects. The relationship 461 between Energy Objects are specified in eoRelationTable. The 462 relationship between the Energy Objects is specified with the 463 entPhysicalIndex of the Energy Object and the UUID of the remote 464 Energy Object. The UUID MUST comply to the RFC 4122 465 specifications. It is important to note that it is possible 466 that an Energy Object may not have an Energy Object relationship 467 with other Energy Objects. 469 The following relationships between Energy objects have been 470 considered in the eoRelationTable. 472 Metering Relationship -> meteredBy / metering 474 Power Source Relationship -> poweredBy / powering 476 Aggregation Relationship -> aggregatedBy / aggregating 478 An Energy Object B has "meteredBy" relationship with Energy 479 Object A, if the energy consumption of Energy Object B is 480 measured by Energy Object A. Equivalently, it is possible to 481 indicate that Energy Object A has "metering" relationship with 482 Energy Object B. 484 An Energy Object B has "poweredBy" relationship with Energy 485 Object A, if the power source of Energy Object B Energy Object 486 A. Equivalently, it is possible to indicate that Energy Object A 487 has "powering" relationship with Energy Object B. 489 An Energy Object B has "aggregatedBy" relationship with Energy 490 Object A, if Energy Object A is an aggregation point for energy 491 usage of Energy Object B. Equivalently, it is possible to 492 indicate that Energy Object A has "aggregating" relationship 493 with Energy Object B. 495 The IANA Energy Relationship MIB module in Section 6 below 496 specifies the first version of the IANA-maintained definitions 497 of relationships. This way, for Energy Relationships, new 498 textual conventions can be specified, without updating the 499 primary Energy Object Context MIB module. 501 4.5 Energy Object Identity Persistence 503 In some situations, the Energy Object identity information 504 should be persistent even after a device reload. For example, in 505 a static setup where a switch monitors a series of connected PoE 506 phones, there is a clear benefit for the EnMS if the Energy 507 Object Identification and all associated information persist, as 508 it saves a network discovery. However, in other situations, 509 such as a wireless access point monitoring the mobile user PCs, 510 there is not much advantage to persist the Energy Object 511 Information. The identity information of an Energy Object 512 should be persisted and there is value in the writable MIB 513 objects persisted. 515 5. MIB Definitions 517 -- ************************************************************ 518 -- 519 -- 520 -- This MIB is used for describing the identity and the 521 -- context information of Energy Objects in network 522 -- 523 -- 524 -- ************************************************************* 526 ENERGY-OBJECT-CONTEXT-MIB DEFINITIONS ::= BEGIN 528 IMPORTS 529 MODULE-IDENTITY, 530 OBJECT-TYPE, 531 mib-2, Integer32 532 FROM SNMPv2-SMI -- RFC2578 533 TEXTUAL-CONVENTION, MacAddress, TruthValue, 534 RowStatus, StorageType 535 FROM SNMPv2-TC -- RFC2579 536 MODULE-COMPLIANCE, OBJECT-GROUP 537 FROM SNMPv2-CONF -- RFC2580 538 SnmpAdminString 539 FROM SNMP-FRAMEWORK-MIB -- RFC3411 540 InetAddressType, InetAddress 541 FROM INET-ADDRESS-MIB -- RFC3291 542 entPhysicalIndex 543 FROM ENTITY-MIB -- RFC6933 544 UUIDorZero 545 FROM UUID-TC-MIB -- RFC6933 546 IANAEnergyRelationship 547 FROM IANA-ENERGY-RELATION-MIB; 549 energyObjectContextMIB MODULE-IDENTITY 550 LAST-UPDATED "201406110000Z" 552 ORGANIZATION "IETF EMAN Working Group" 553 CONTACT-INFO 554 "WG Charter: 555 http://datatracker.ietf.org/wg/eman/charter/ 557 Mailing Lists: 558 General Discussion: eman@ietf.org 559 To Subscribe: https://www.ietf.org/mailman/listinfo/eman 560 Archive: http://www.ietf.org/mail-archive/web/eman 562 Editors: 563 John Parello 564 Cisco Systems, Inc. 565 3550 Cisco Way 566 San Jose, California 95134 567 US 568 Phone: +1 408 525 2339 569 Email: jparello@cisco.com 571 Benoit Claise 572 Cisco Systems, Inc. 573 De Kleetlaan 6a b1 574 Degem 1831 575 Belgium 576 Phone: +32 2 704 5622 577 Email: bclaise@cisco.com 579 Mouli Chandramouli 580 Cisco Systems, Inc. 581 Sarjapur Outer Ring Road 582 Bangalore 560103 583 IN 584 Phone: +91 80 4429 2409 585 Email: moulchan@cisco.com" 587 DESCRIPTION 588 "This MIB is used for describing the identity and the 589 context information of Energy Objects" 590 REVISION 591 "201406110000Z" 592 DESCRIPTION 593 "Initial version, published as RFC YYYY." 595 ::= { mib-2 xxx1 } 597 -- RFC Editor, please replace xxx1 with the IANA allocation 598 -- for this MIB module and YYYY with the number of the 599 -- approved RFC 601 energyObjectContextMIBNotifs OBJECT IDENTIFIER 602 ::= { energyObjectContextMIB 0 } 604 energyObjectContextMIBObjects OBJECT IDENTIFIER 605 ::= { energyObjectContextMIB 1 } 607 energyObjectContextMIBConform OBJECT IDENTIFIER 608 ::= { energyObjectContextMIB 2 } 610 -- Textual Conventions 612 PethPsePortIndexOrZero ::= TEXTUAL-CONVENTION 613 DISPLAY-HINT "d" 614 STATUS current 615 DESCRIPTION 616 "This textual convention is an extension of the 617 pethPsePortIndex convention, which defines a greater than 618 zero value used to identify a power Ethernet PSE port. 620 This extension permits the additional value of zero. The 621 semantics of the value zero are object-specific and must, 622 therefore, be defined as part of the description of any 623 object that uses this syntax. Examples of the usage of 624 this extension are situations where none or all physical 625 entities need to be referenced." 626 SYNTAX Integer32 (0..2147483647) 628 PethPsePortGroupIndexOrZero ::= TEXTUAL-CONVENTION 629 DISPLAY-HINT "d" 630 STATUS current 631 DESCRIPTION 632 "This textual convention is an extension of the 633 pethPsePortGroupIndex convention from the Power Over 634 Ethernet MIB RFC 3621, which defines a greater than zero 635 value used to identify group containing the port to which 636 a power Ethernet PSE is connected. This extension 637 permits the additional value of zero. The semantics of 638 the value zero are object-specific and must, therefore, 639 be defined as part of the description of any object that 640 uses this syntax. Examples of the usage of this 641 extension are situations where none or all physical 642 entities need to be referenced." 643 SYNTAX Integer32 (0..2147483647) 645 LldpPortNumberOrZero ::= TEXTUAL-CONVENTION 646 DISPLAY-HINT "d" 647 STATUS current 648 DESCRIPTION 649 "This textual convention is an extension of the 650 LldpPortNumber convention specified in the LLDP MIB, 651 which defines a greater than zero value used to uniquely 652 identify each port contained in the chassis (that is 653 known to the LLDP agent) by a port number. This 654 extension permits the additional value of zero. The 655 semantics of the value zero are object-specific and must, 656 therefore, be defined as part of the description of any 657 object that uses this syntax. Examples of the usage of 658 this extension are situations where none or all physical 659 entities need to be referenced." 660 SYNTAX Integer32(0..4096) 662 EnergyObjectKeywordList ::= TEXTUAL-CONVENTION 663 STATUS current 664 DESCRIPTION 665 "A list of keywords that can be used to group Energy 666 Objects for reporting or searching. If multiple keywords 667 are present, then this string will contain all the 668 keywords separated by the ',' character. All alphanumeric 669 characters and symbols (other than a comma), such as #, 670 (, $, !, and &, are allowed. White spaces before and 671 after the commas are ignored, as well as within a keyword 672 itself. 674 For example, if an Energy Object were to be tagged with 675 the keyword values 'hospitality' and 'guest', then the 676 keyword list will be 'hospitality,guest'." 677 SYNTAX OCTET STRING (SIZE (0..2048)) 679 -- Objects 681 eoTable OBJECT-TYPE 682 SYNTAX SEQUENCE OF EoEntry 683 MAX-ACCESS not-accessible 684 STATUS current 685 DESCRIPTION 686 "This table lists Energy Objects." 687 ::= { energyObjectContextMIBObjects 1 } 689 eoEntry OBJECT-TYPE 690 SYNTAX EoEntry 691 MAX-ACCESS not-accessible 692 STATUS current 693 DESCRIPTION 694 "An entry describes the attributes of an Energy Object. 695 Whenever a new Energy Object is added or an existing 696 Energy Object is deleted, a row in the eoTable is added 697 or deleted." 699 INDEX {entPhysicalIndex } 700 ::= { eoTable 1 } 702 EoEntry ::= SEQUENCE { 703 eoEthPortIndex PethPsePortIndexOrZero, 704 eoEthPortGrpIndex PethPsePortGroupIndexOrZero, 705 eoLldpPortNumber LldpPortNumberOrZero, 706 eoMgmtMacAddress MacAddress, 707 eoMgmtAddressType InetAddressType, 708 eoMgmtAddress InetAddress, 709 eoMgmtDNSName OCTET STRING, 710 eoDomainName SnmpAdminString, 711 eoRoleDescription SnmpAdminString, 712 eoKeywords EnergyObjectKeywordList, 713 eoImportance Integer32, 714 eoPowerCategory INTEGER, 715 eoAlternateKey SnmpAdminString, 716 eoPowerInterfaceType INTEGER 717 } 719 eoEthPortIndex OBJECT-TYPE 720 SYNTAX PethPsePortIndexOrZero 721 MAX-ACCESS read-only 722 STATUS current 723 DESCRIPTION 724 "This variable uniquely identifies the power Ethernet 725 port to which a Power over Enternet device is connected . 726 If the Power over Ethernet MIB RFC 3621 is supported by 727 the SNMP agent managing the Energy Object, then the 728 Energy Object eoethPortIndex MUST contain the 729 corresponding value of pethPsePortIndex. If such a power 730 Ethernet port cannot be specified or is not known then 731 the object is zero." 732 REFERENCE "RFC 3621 " 733 DEFVAL { 0 } 735 ::= { eoEntry 1 } 737 eoEthPortGrpIndex OBJECT-TYPE 738 SYNTAX PethPsePortGroupIndexOrZero 739 MAX-ACCESS read-only 740 STATUS current 741 DESCRIPTION 742 "This variable uniquely identifies the group containing 743 the port to which a power over Ethernet device PSE is 744 connected [RFC3621]. If the Power over Ethernet MIB RFC 745 3621 is supported by the SNMP agent managing the Energy 746 Object, then the Energy Object eoEthPortGrpIndex MUST 747 contain the corresponding value of eoethPortGrpIndex. If 748 such a power Ethernet port cannot be specified or is not 749 known then the object is zero." 750 REFERENCE "RFC 3621" 751 DEFVAL { 0 } 753 ::= { eoEntry 2 } 755 eoLldpPortNumber OBJECT-TYPE 756 SYNTAX LldpPortNumberOrZero 757 MAX-ACCESS read-only 758 STATUS current 759 DESCRIPTION 760 "This variable uniquely identifies the port component 761 (contained in the local chassis with the LLDP agent) as 762 defined by the lldpLocPortNum in the [LLDP-MIB] and 763 [LLDP-MED-MIB]. If the [LLDP-MIB] is supported by the 764 SNMP agent managing the Energy Object, then the Energy 765 Object eoLldpPortNumber MUST contain the corresponding 766 value of lldpLocPortNum from the [LLDP-MIB]. If such a 767 port number cannot be specified or is not known then the 768 object is zero." 769 REFERENCE "LLDP MIB, IEEE 802.1AB-2005, 770 LLDP-MED-MIB, ANSI/TIA-1057" 771 DEFVAL { 0 } 773 ::= { eoEntry 3 } 775 eoMgmtMacAddress OBJECT-TYPE 776 SYNTAX MacAddress 777 MAX-ACCESS read-only 778 STATUS current 779 DESCRIPTION 780 "This object specifies a MAC address of the Energy 781 Object." 782 ::= { eoEntry 4 } 784 eoMgmtAddressType OBJECT-TYPE 785 SYNTAX InetAddressType 786 MAX-ACCESS read-only 787 STATUS current 788 DESCRIPTION 789 "This object specifies the eoMgmtAddress type, i.e. an 790 IPv4 address or an IPv6 address. This object MUST be 791 populated when eoMgmtAddress is populated." 792 ::= { eoEntry 5 } 794 eoMgmtAddress OBJECT-TYPE 795 SYNTAX InetAddress 796 MAX-ACCESS read-only 797 STATUS current 798 DESCRIPTION 799 "This object specifies the management address as an IPv4 800 address or IPv6 address of Energy Object. The IP address 801 type, i.e. IPv4 or IPv6, is determined by the 802 eoMgmtAddressType value. This object can be used as an 803 alternate key to help link the Energy Object with other 804 keyed information that may be stored within the EnMS(s)." 805 ::= { eoEntry 6 } 807 eoMgmtDNSName OBJECT-TYPE 808 SYNTAX OCTET STRING 809 MAX-ACCESS read-only 810 STATUS current 811 DESCRIPTION 812 "This object specifies a DNS name of the eoMgmtAddress. 813 This object can be used as an alternate key to help link 814 the Energy Object with other keyed information that may 815 be stored within the EnMS(s). A DNS Name must always be a 816 fully qualified name. This MIB uses the same encoding as 817 the DNS protocol." 818 REFERENCE 819 "RFC-1034 section 3.1." 820 ::= { eoEntry 7 } 822 eoDomainName OBJECT-TYPE 823 SYNTAX SnmpAdminString 824 MAX-ACCESS read-write 825 STATUS current 826 DESCRIPTION 827 "This object specifies the name of an Energy Management 828 Domain for the Energy Object. By default, this object 829 should be an empty string. The value of eoDomainName must 830 remain constant at least from one re-initialization of 831 the entity local management system to the next re- 832 initialization." 833 ::= { eoEntry 8 } 835 eoRoleDescription OBJECT-TYPE 836 SYNTAX SnmpAdminString 837 MAX-ACCESS read-write 838 STATUS current 839 DESCRIPTION 840 "This object specifies an administratively assigned name 841 to indicate the purpose an Energy Object serves in the 842 network. 844 For example, we can have a phone deployed to a lobby with 845 eoRoleDescription as 'Lobby phone'. 847 This object specifies that the value is the zero-length 848 string value if no role description is configured. 849 The value of eoRoleDescription must remain constant at 850 least from one re-initialization of the entity local 851 management system to the next re-initialization. " 852 ::= { eoEntry 9 } 854 eoKeywords OBJECT-TYPE 855 SYNTAX EnergyObjectKeywordList 856 MAX-ACCESS read-write 857 STATUS current 858 DESCRIPTION 859 "This object specifies a list of keywords that can be 860 used to group Energy Objects for reporting or searching. 861 The value is the zero-length string if no keywords have 862 been configured. If multiple keywords are present, then 863 this string will contain all the keywords separated by 864 the ',' character. For example, if an Energy Object were 865 to be tagged with the keyword values 'hospitality' and 866 'guest', then the keyword list will be 867 'hospitality,guest'. 869 If write access is implemented and a value is written 870 into the instance, the agent must retain the supplied 871 value in the eoKeywords instance associated with 872 the same physical entity for as long as that entity 873 remains instantiated. This includes instantiations 874 across all re-initializations/reboots of the local 875 management agent. " 876 ::= { eoEntry 10 } 878 eoImportance OBJECT-TYPE 879 SYNTAX Integer32 (1..100) 880 MAX-ACCESS read-write 881 STATUS current 882 DESCRIPTION 883 "This object specifies a ranking of how important the 884 Energy Object is (on a scale of 1 to 100) compared with 885 other Energy Objects in the same Energy Management 886 Domain. The ranking should provide a business or 887 operational context for the Energy Object as compared to 888 other similar Energy Objects. This ranking could be used 889 as input for policy-based network management. 891 Although network managers must establish their own 892 ranking, the following is a broad recommendation: 894 90 to 100 Emergency response 895 80 to 90 Executive or business critical 896 70 to 79 General or Average 897 60 to 69 Staff or support 898 40 to 59 Public or guest 899 1 to 39 Decorative or hospitality 901 The value of eoImportance must remain constant at least 902 from one re-initialization of the Energy Object local 903 management system to the next re-initialization. " 904 DEFVAL { 1 } 905 ::= { eoEntry 11 } 907 eoPowerCategory OBJECT-TYPE 908 SYNTAX INTEGER { 909 consumer(0), 910 producer(1), 911 meter(2), 912 distributor(3), 913 store(4) 914 } 915 MAX-ACCESS read-only 916 STATUS current 917 DESCRIPTION 918 "This object describes the Energy Object category, which 919 indicates the expected behavior or physical property of 920 the Energy Object, based on its design. An Energy Object 921 can be a consumer(0), producer(1), meter(2), 922 distributor(3) or store(4). 924 In some cases, a meter is required to measure the power 925 consumption. In such a case, this meter Energy Object 926 category is meter(2). If a device is distributing 927 electric Energy, the category of the Energy Object is 928 distributor (3). If a device is storing electric Energy, 929 the category of the device can be store (4). " 930 ::= { eoEntry 12 } 932 eoAlternateKey OBJECT-TYPE 933 SYNTAX SnmpAdminString 934 MAX-ACCESS read-write 935 STATUS current 936 DESCRIPTION 937 "The eoAlternateKey object specifies an alternate key 938 string that can be used to identify the Energy Object. 939 Since Energy Management Systems (EnMS) and Network 940 Management Systems (NMS) may need to correlate objects 941 across management systems, this alternate key is provided 942 to provide such a link. This optional value is intended 943 as a foreign key or alternate identifier for a 944 manufacturer or EnMS/NMS to use to correlate the unique 945 Energy Object Id in other systems or namespaces. If an 946 alternate key is not available or is not applicable then 947 the value is the zero-length string. 948 The value of eoAlternateKey must remain constant at 949 least from one re-initialization of the entity local 950 management system to the next re-initialization. " 951 ::= { eoEntry 13 } 953 eoPowerInterfaceType OBJECT-TYPE 954 SYNTAX INTEGER { 955 inlet(0), 956 outlet(1), 957 both(2) 958 } 959 MAX-ACCESS read-only 960 STATUS current 961 DESCRIPTION 962 "This object describes the Power Interface for an Energy 963 Object. A Power Interface is an interface at which a 964 Energy Object is connected to a power transmission 965 medium, at which it can in turn receive power, provide 966 power, or both. A Power Interface type can be an inlet(0) 967 or outlet(1) or both(2), respectively." 968 ::= { eoEntry 14 } 970 eoRelationTable OBJECT-TYPE 971 SYNTAX SEQUENCE OF EoRelationEntry 972 MAX-ACCESS not-accessible 973 STATUS current 974 DESCRIPTION 975 "This table describes the relationships between Energy 976 Objects." 977 ::= { energyObjectContextMIBObjects 2 } 979 eoRelationEntry OBJECT-TYPE 980 SYNTAX EoRelationEntry 981 MAX-ACCESS not-accessible 982 STATUS current 983 DESCRIPTION 984 "An entry in this table specifies the Energy relationship 985 between Energy objects. Energy relations between two 986 Energy objects are defined in the RFC7326." 987 REFERENCE 988 " RFC7326, Energy Management Framework, RFC abcs, 989 Jan 2014" 990 INDEX { entPhysicalIndex, eoRelationIndex } 991 ::= { eoRelationTable 1 } 993 EoRelationEntry ::= SEQUENCE { 994 eoRelationIndex Integer32, 995 eoRelationID UUIDorZero, 996 eoRelationship IANAEnergyRelationship, 997 eoRelationStatus RowStatus, 998 eoRelationStorageType StorageType 999 } 1001 eoRelationIndex OBJECT-TYPE 1002 SYNTAX Integer32 (0..2147483647) 1003 MAX-ACCESS not-accessible 1004 STATUS current 1005 DESCRIPTION 1006 "This object is an arbitrary index to identify the Energy 1007 Object related to another Energy Object" 1008 ::= { eoRelationEntry 1 } 1010 eoRelationID OBJECT-TYPE 1011 SYNTAX UUIDorZero 1012 MAX-ACCESS read-create 1013 STATUS current 1014 DESCRIPTION 1015 "This object specifies the Universally Unique Identifier 1016 (UUID) of the peer (other) Energy Object. The UUID must 1017 comply the specifications of UUID in UUID-TC-MIB. 1019 If UUID of the energy object is unknown or non-existent, 1020 the eoRelationID will be set to a zero-length string 1021 instead. It is preferable that the value of 1022 entPhysicalUUID from ENTITY-MIB is used for values for 1023 this object." 1025 REFERENCE 1026 "RFC 6933, Entity MIB - version 4, May 2013 " 1027 ::= { eoRelationEntry 2 } 1029 eoRelationship OBJECT-TYPE 1030 SYNTAX IANAEnergyRelationship 1031 MAX-ACCESS read-create 1032 STATUS current 1033 DESCRIPTION 1034 "This object describes the relations between Energy 1035 objects. For each Energy object, the relations between 1036 the other Energy objects are specified using the bitmap." 1037 ::= { eoRelationEntry 3 } 1039 eoRelationStatus OBJECT-TYPE 1040 SYNTAX RowStatus 1041 MAX-ACCESS read-create 1042 STATUS current 1043 DESCRIPTION 1044 "The status controls and reflects the creation and 1045 activation status of a row in this table to specify energy 1046 relationship between Energy objects. 1048 An entry status may not be active(1) unless all objects in 1049 the entry have the appropriate values. 1050 No attempt to modify a row columnar object instance value 1051 in the eoRelationTable should be issued while the value of 1052 eoRelationStatus is active(1). The data can be destroyed by 1053 setting up the eoRelationStatus to destroy(2)." 1055 ::= { eoRelationEntry 4 } 1057 eoRelationStorageType OBJECT-TYPE 1058 SYNTAX StorageType 1059 MAX-ACCESS read-create 1060 STATUS current 1061 DESCRIPTION 1062 "This variable indicates the storage type for this row." 1063 DEFVAL { nonVolatile } 1064 ::= {eoRelationEntry 5 } 1066 -- Conformance 1068 energyObjectContextMIBCompliances OBJECT IDENTIFIER 1069 ::= { energyObjectContextMIBConform 1 } 1071 energyObjectContextMIBGroups OBJECT IDENTIFIER 1072 ::= { energyObjectContextMIBConform 2 } 1074 energyObjectContextMIBFullCompliance MODULE-COMPLIANCE 1075 STATUS current 1076 DESCRIPTION 1077 "When this MIB is implemented with support for 1078 read-write, then such an implementation can 1079 claim full compliance. Such devices can then 1080 be both monitored and configured with this MIB. 1081 Module Compliance of ENTITY-MIB with respect to 1082 entity4CRCompliance MUST be supported." 1084 MODULE -- this module 1085 MANDATORY-GROUPS { 1086 energyObjectContextMIBTableGroup, 1087 energyObjectRelationTableGroup 1088 } 1090 GROUP energyObjectOptionalMIBTableGroup 1091 DESCRIPTION 1092 "A compliant implementation does not have to 1093 implement. " 1094 ::= { energyObjectContextMIBCompliances 1 } 1096 energyObjectContextMIBReadOnlyCompliance MODULE-COMPLIANCE 1097 STATUS current 1098 DESCRIPTION 1099 "When this MIB is implemented without support for 1100 read-write (i.e. in read-only mode), then such an 1101 implementation can claim read-only compliance. 1102 Such a device can then be monitored but cannot be 1103 Configured with this MIB. 1104 Module Compliance of ENTITY-MIB with respect to 1105 entity4CRCompliance MUST be supported." 1106 MODULE -- this module 1108 MANDATORY-GROUPS { 1109 energyObjectContextMIBTableGroup, 1110 energyObjectRelationTableGroup 1111 } 1113 GROUP energyObjectOptionalMIBTableGroup 1114 DESCRIPTION 1115 "A compliant implementation does not have to implement 1116 the managed objects in this GROUP. " 1118 ::= { energyObjectContextMIBCompliances 2 } 1120 -- Units of Conformance 1122 energyObjectContextMIBTableGroup OBJECT-GROUP 1123 OBJECTS { 1124 eoDomainName, 1125 eoRoleDescription, 1126 eoAlternateKey, 1127 eoKeywords, 1128 eoImportance, 1129 eoPowerCategory, 1130 eoPowerInterfaceType 1131 } 1132 STATUS current 1133 DESCRIPTION 1134 "This group contains the collection of all the objects 1135 related to the EnergyObject. " 1137 ::= { energyObjectContextMIBGroups 1 } 1139 energyObjectOptionalMIBTableGroup OBJECT-GROUP 1140 OBJECTS { 1141 eoEthPortIndex, 1142 eoEthPortGrpIndex, 1143 eoLldpPortNumber, 1144 eoMgmtMacAddress, 1145 eoMgmtAddressType, 1146 eoMgmtAddress, 1147 eoMgmtDNSName 1148 } 1149 STATUS current 1150 DESCRIPTION 1151 "This group contains the collection of all the objects 1152 related to the Energy Object." 1153 ::= { energyObjectContextMIBGroups 2 } 1155 energyObjectRelationTableGroup OBJECT-GROUP 1156 OBJECTS { 1158 eoRelationID, 1159 eoRelationship, 1160 eoRelationStatus, 1161 eoRelationStorageType 1162 } 1163 STATUS current 1164 DESCRIPTION 1165 "This group contains the collection of all objects 1166 specifying the relationship between Energy Objects." 1167 ::= { energyObjectContextMIBGroups 3 } 1169 END 1171 IANA-ENERGY-RELATION-MIB DEFINITIONS ::= BEGIN 1172 IMPORTS 1173 MODULE-IDENTITY, mib-2 1174 FROM SNMPv2-SMI 1175 TEXTUAL-CONVENTION 1176 FROM SNMPv2-TC; 1178 ianaEnergyRelationMIB MODULE-IDENTITY 1179 LAST-UPDATED "201406110000Z" -- June 11, 2014 1180 ORGANIZATION "IANA" 1181 CONTACT-INFO " 1182 Internet Assigned Numbers Authority 1183 Postal: ICANN 1184 4676 Admiralty Way, Suite 330 1185 Marina del Rey, CA 90292 1186 Tel: +1-310-823-9358 1187 EMail: iana&iana.org" 1189 DESCRIPTION 1190 "This MIB module defines a TEXTUAL-CONVENTION that 1191 describes the relationships between Energy Objects. 1193 Copyright (C) The IETF Trust (2014). 1195 The initial version of this MIB module was published in 1196 RFC YYYY; for full legal notices see the RFC itself. 1197 Supplementary information may be available at 1198 http://www.ietf.org/copyrights/ianamib.html" 1200 REVISION "201406110000Z" -- June 11, 2014 1201 DESCRIPTION "Initial version of this MIB as published in 1202 RFC YYYY." 1203 ::= { mib-2 xxx2 } 1205 -- RFC Editor, please replace xxx2 with the IANA allocation 1206 -- for this MIB module and YYYY with the number of the 1207 -- approved RFC 1209 -- Textual Conventions 1211 IANAEnergyRelationship ::= TEXTUAL-CONVENTION 1212 STATUS current 1213 DESCRIPTION 1214 "An enumerated value specifying the type of 1215 relationship between an Energy Object A, on 1216 which the relationship is specified, with the 1217 Energy Object B, identified by the UUID. 1219 The enumeration 'poweredBy' is applicable if the 1220 Energy Object A is poweredBy Energy Object B. 1222 The enumeration 'powering' is applicable if the 1223 Energy Object A is powering Energy Object B. 1225 The enumeration 'meteredBy' is applicable if the 1226 Energy Object A is meteredBy Energy Object B. 1228 The enumeration 'metering' is applicable if the 1229 Energy Object A is metering Energy Object B. 1231 The enumeration 'aggregatedBy' is applicable if the 1232 Energy Object A is aggregatedBy Energy Object B. 1234 The enumeration 'aggregating' is applicable if the 1235 Energy Object A is aggregating Energy Object B." 1237 SYNTAX INTEGER { 1238 poweredBy(1), -- power relationship 1239 powering(2), 1240 meteredBy(3), -- meter relationship 1241 metering(4), 1242 aggregatedBy(5), -- aggregation relationship 1243 aggregating(6) 1244 } 1246 END 1248 6. Implementation Status 1250 [Note to RFC Editor: Please remove this section and the 1251 reference to [RFC6982] before publication.] 1253 This section records the status of known implementations of the 1254 EMAN-Monitoring MIB at the time of posting of this Internet- 1255 Draft, and is based on a proposal described in [RFC6982]. 1257 The description of implementations in this section is intended 1258 to assist the IETF in its decision processes in progressing 1259 drafts to RFCs. 1261 6.1. SNMP Research 1263 Organization: SNMP Research, Inc. 1265 Maturity: Prototype based upon early drafts of the MIBs. 1266 We anticipate updating it to more recent 1267 documents as development schedules allow. 1269 Coverage: Code was generated to implement all MIB objects 1270 in ENTITY-MIB (Version 4), 1271 ENERGY-OBJECT-CONTEXT-MIB, 1272 ENERGY-OBJECT-MIB, 1273 POWER-CHARACTERISTICS-MIB, 1274 and BATTERY-MIB. 1276 Implementation experience: The documents are implementable. 1278 Comments: Technical comments about the 1279 ENERGY-OBJECT-CONTEXT-MIB, 1280 ENERGY-OBJECT-MIB, and 1281 BATTERY-MIB 1282 were submitted to the EMAN Working Group 1283 E-mail list. 1285 Licensing: Proprietary, royalty licensing 1287 Contact: Alan Luchuk, luchuk at snmp.com 1289 URL: http://www.snmp.com/ 1291 6.2. Python 1293 Priyanka Rao has mentioned on the mailing list 1294 (http://www.ietf.org/mail- 1295 archive/web/eman/current/msg02063.html) that she has 1296 a python implementation. 1298 7. Security Considerations 1300 There are a number of management objects defined in this MIB 1301 module with a MAX-ACCESS clause of read-write and/or read- 1302 create. Such objects may be considered sensitive or vulnerable 1303 in some network environments. The support for SET operations in 1304 a non-secure environment without proper protection opens devices 1305 to attack. These are the tables and objects and their 1306 sensitivity/vulnerability: 1308 . Unauthorized changes to the eoDomainName, entPhysicalName, 1309 eoRoleDescription, eoKeywords, and/or eoImportance MAY 1310 disrupt power and energy collection, and therefore any 1311 predefined policies defined in the network. 1313 SNMP versions prior to SNMPv3 did not include adequate security. 1314 Even if the network itself is secure (for example by using 1315 IPsec), there is no control as to who on the secure network is 1316 allowed to access and GET/SET (read/change/create/delete) the 1317 objects in this MIB module. 1319 Implementations SHOULD provide the security features described 1320 by the SNMPv3 framework (see [RFC3410]), and implementations 1321 claiming compliance to the SNMPv3 standard MUST include full 1322 support for authentication and privacy via the User-based 1323 Security Model (USM) [RFC3414] with the AES cipher algorithm 1324 [RFC3826]. Implementations MAY also provide support for the 1325 Transport Security Model (TSM) [RFC5591] in combination with a 1326 secure transport such as SSH [RFC5592] or TLS/DTLS [RFC6353]. 1328 Further, deployment of SNMP versions prior to SNMPv3 is NOT 1329 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 1330 enable cryptographic security. It is then a customer/operator 1331 responsibility to ensure that the SNMP entity giving access to 1332 an instance of this MIB module is properly configured to give 1333 access to the objects only to those principals (users) that have 1334 legitimate rights to indeed GET or SET (change/create/delete) 1335 them. 1337 In certain situations, energy and power monitoring can reveal 1338 sensitive information about individuals' activities and habits. 1339 Implementors of this specification should use appropriate 1340 privacy protections as discussed in Section 9 of RFC 6988 and 1341 monitoring of individuals and homes should only occur with 1342 proper authorization. 1344 8. IANA Considerations 1346 The MIB modules in this document use the following IANA-assigned 1347 OBJECT IDENTIFIER values recorded in the SMI Numbers registry: 1349 Descriptor OBJECT IDENTIFIER value 1351 ---------- ----------------------- 1353 energyObjectContextMIB { mib-2 xxx1 } 1355 Editor's Note (to be removed prior to publication): IANA is 1356 requested to assign a value for "xxx1" under the 'mib-2' subtree 1357 and to record the assignment in the SMI Numbers registry. When 1358 the assignment has been made, the RFC Editor is asked to replace 1359 "xxx1" (here and in the MIB module) with the assigned value and 1360 to remove this note. 1362 This document defines the first version of the IANA-maintained 1363 IANA-ENERGY-RELATION-MIB module, which allows new definitions of 1364 relationships between Energy Objects. 1366 A Specification Required as defined in RFC 5226 [RFC5226], is 1367 REQUIRED for each modification of the energy relationships. 1369 The MIB module in this document uses the following IANA-assigned 1370 OBJECT IDENTIFIER values recorded in the SMI Numbers registry. 1372 Descriptor OBJECT IDENTIFIER value 1374 ---------- ----------------------- 1376 ianaEnergyRelationMIB { mib-2 xxx2 } 1378 Editor's Note (to be removed prior to publication): IANA is 1379 requested to assign a value for "xxx2" under the 'mib-2' subtree 1380 and to record the assignment in the SMI Numbers registry. When 1381 the assignment has been made, the RFC Editor is asked to replace 1382 "xxx2" (here and in the MIB module) with the assigned value and 1383 to remove this note. 1385 9. Acknowledgement 1387 We would like to thank Juergen Quittek and Juergen Schoenwalder 1388 for their suggestions on the new design of eoRelationTable which 1389 was a proposed solution for the open issue on the representation 1390 of Energy Object as a UUIDlist. 1392 Many thanks to Juergen Quittek for many comments on the wording, 1393 text and design of the MIB thus resulting in an improved draft. 1395 Many thanks to Alan Luchuk for the review of the MIB and his 1396 comments. 1398 In addition the authors thank Bill Mielke for his multiple 1399 reviews, Brad Schoening and Juergen Schoenwaelder for their 1400 suggestions and Michael Brown for dramatically improving this 1401 draft. 1403 And finally thanks the EMAN WG chairs: Nevil Brownlee and Tom 1404 Nadeau. 1406 10. References 1408 10.1. Normative References 1410 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 1411 Requirement Levels, BCP 14, RFC 2119, March 1997. 1413 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1414 Schoenwaelder, Ed., "Structure of Management 1415 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1416 1999. 1418 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1419 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 1420 STD 58, RFC 2579, April 1999. 1422 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 1423 "Conformance Statements for SMIv2", STD 58, RFC 2580, 1424 April 1999. 1426 [RFC3621] Berger, A., and D. Romascanu, "Power Ethernet MIB", 1427 RFC3621, December 2003. 1429 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1430 Unique IDentifier (UUID) URN Namespace ", RFC 4122, 1431 July 2005. 1433 [RFC6933] Bierman, A. Romascanu,D. Quittek, J. and M. 1434 Chandramouli, "Entity MIB (Version 4)", RFC 6933, May 1435 2013. 1437 [LLDP-MIB] IEEE 802.1AB-2005, "Management Information Base 1438 module for LLDP configuration, statistics, local system 1439 data and remote systems data components", May 2005. 1441 [LLDP-MED-MIB] ANSI/TIA-1057, "The LLDP Management Information 1442 Base extension module for TIA-TR41.4 media endpoint 1443 discovery information", July 2005. 1445 [EMAN-MON-MIB] M. Chandramouli, Schoening, B., Quittek, J., 1446 Dietz, T., and B. Claise "Power and Energy Monitoring 1447 MIB", draft-ietf-eman-energy-monitoring-mib-13, 1448 November 2014. 1450 10.2. Informative References 1452 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 1453 "Introduction and Applicability Statements for Internet 1454 Standard Management Framework", RFC 3410, December 1455 2002. 1457 [RFC3433] Bierman, A., Romascanu, D., and K.C. Norseth, "Entity 1458 Sensor Management Information Base", RFC 3433, December 1459 2002. 1461 [RFC5226] Narten, T. Alverstrand, H., A. and K. McCloghrie, 1462 "Guidelines for Writing an IANA Considerations Section 1463 in RFCs ", BCP 26, RFC 5226, May 2008. 1465 [RFC6988] Quittek, J., Winter, R., Dietz, T., Claise, B., and M. 1466 Chandramouli, "Requirements for Energy Management", RFC 1467 6988, September 2013. 1469 [RFC7326] Parello, J., Claise, B., Schoening, B., and J. 1470 Quittek, "Energy Management Framework", RFC 7326, 1471 September, 2014. 1473 [EMAN-AS] Schoening, B., Chandramouli, M, and B. Nordman, 1474 "Energy Management (EMAN) Applicability Statement", 1475 draft-ietf-eman-applicability-statement-08.txt, work in 1476 progress, October 2014. 1478 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of 1479 Running Code: The Implementation Status Section", RFC 1480 6982, July 2013. 1482 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security 1483 Model (USM) for version 3 of the Simple Network 1484 ManagementProtocol (SNMPv3)", STD 62, RFC 3414, 1485 December 2002. 1487 [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The 1488 Advanced Encryption Standard (AES) Cipher Algorithm in 1489 the SNMP User-based Security Model", RFC 3826, June 1490 2004. 1492 [RFC5591] Harrington, D. and W. Hardaker, "Transport Security 1493 Model for the Simple Network Management Protocol 1494 (SNMP)", RFC 5591, June 2009. 1496 [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure 1497 Shell Transport Model for the Simple Network Management 1498 Protocol (SNMP)", RFC 5592, June 2009. 1500 [RFC6353] Hardaker, W., "Transport Layer Security (TLS) 1501 Transport Model for the Simple Network Management 1502 Protocol (SNMP)", RFC 6353, July 2011. 1504 Authors' Addresses 1506 Benoit Claise 1507 Cisco Systems, Inc. 1508 De Kleetlaan 6a b1 1509 Diegem 1813 1510 BE 1512 Phone: +32 2 704 5622 1513 Email: bclaise@cisco.com 1515 John Parello 1516 Cisco Systems, Inc. 1517 3550 Cisco Way 1518 San Jose, California 95134 1519 US 1521 Phone: +1 408 525 2339 1522 Email: jparello@cisco.com 1524 Mouli Chandramouli 1525 Cisco Systems, Inc. 1526 Sarjapur Outer Ring Road 1527 Bangalore 560103 1528 IN 1530 Phone: +91 80 4429 2409 1531 Email: moulchan@cisco.com