idnits 2.17.1 draft-ietf-eman-energy-aware-mib-06.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 60 lines 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 193 has weird spacing: '...xOrZero eoEth...' -- The document date (July 10, 2012) is 4309 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) == Unused Reference: 'RFC3986' is defined on line 1354, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4133 (Obsoleted by RFC 6933) -- Possible downref: Non-RFC (?) normative reference: ref. 'LLDP-MIB' -- Possible downref: Non-RFC (?) normative reference: ref. 'LLDP-MED-MIB' == Outdated reference: A later version (-13) exists of draft-ietf-eman-energy-monitoring-mib-02 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-14) exists of draft-ietf-eman-requirements-07 == Outdated reference: A later version (-19) exists of draft-ietf-eman-framework-04 == Outdated reference: A later version (-11) exists of draft-ietf-eman-applicability-statement-01 == Outdated reference: A later version (-09) exists of draft-parello-eman-definitions-05 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 4 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: January 11, 2013 Cisco Systems, Inc. 6 July 10, 2012 8 Energy Object Context MIB 9 draft-ietf-eman-energy-aware-mib-06 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 January 11, 2013. 35 Copyright Notice 37 Copyright (c) 2012 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 55 relationships between reporting devices, remote devices, and 56 monitoring devices. 58 Conventions used in this document 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 61 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 62 RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 63 be interpreted as described in RFC 2119 [RFC2119]. 65 Table of Contents 67 1. Introduction............................................ 3 68 1.1. Energy Management Document Overview.................3 69 2. The Internet-Standard Management Framework.............. 4 70 3. Requirements and Use Cases.............................. 4 71 4. Terminology............................................. 4 72 5. Architecture Concepts Applied to the MIB Module......... 5 73 5.1 Energy Object Identification.........................8 74 5.2 Energy Object Context................................9 75 5.3 Links to Other Identifiers..........................10 76 5.4 Child: Energy Object Relationships..................10 77 5.5 Parent: Energy Object Relationships.................12 78 5.6 Energy Object Identity Persistence..................12 80 6. MIB Definitions........................................ 12 81 7. Security Considerations................................ 29 82 8. IANA Considerations.................................... 30 83 9. Acknowledgement........................................ 30 84 10. Open Issues........................................... 31 85 11. References............................................ 31 86 11.1. Normative References..............................31 87 11.2. Informative References............................32 89 1. Introduction 91 The EMAN standards provide a specification for Energy 92 Management. This document defines a subset of a Management 93 Information Base (MIB) for use with network management protocols 94 for Energy monitoring of network devices and devices attached to 95 the network and possibly extending to devices in the industrial 96 automation setting with a network interface. 98 The focus of the MIB module specified in this document is on the 99 identification of Energy Objects and reporting the context and 100 relationships of Energy Objects as defined in [EMAN-FMWK]. The 101 module addresses Energy Object Identification, Energy Object 102 Context, and Energy Object Relationships. 104 1.1. Energy Management Document Overview 106 This document specifies the ENERGY-OBJECT-CONTEXT-MIB module. 107 This document is based on the Energy Management Framework [EMAN- 108 FMWK] and meets the requirements on identification of Energy 109 Objects and their context and relationships as specified in the 110 Energy Management requirements [EMAN-REQ]. 112 A second MIB module required by the [EMAN-FMWK], the Power and 113 Energy Monitoring MIB [EMAN-MON-MIB], monitors the Energy 114 Objects for Power States, for the Power and Energy consumption. 115 Power State monitoring includes: retrieving Power States, Power 116 State properties, current Power State, Power State transitions, 117 and Power State statistics. In addition, this MIB module 118 provides the Power Characteristics properties of the Power 119 and Energy, along with optional characteristics. 121 The applicability statement document [EMAN-AS] provides the list 122 of use cases, and describes the common aspects of between 123 existing Energy standards and the EMAN standard, and shows how 124 the EMAN framework relates to other frameworks. 126 2. The Internet-Standard Management Framework 128 For a detailed overview of the documents that describe the 129 current Internet-Standard Management Framework, please refer to 130 section 7 of RFC 3410 [RFC3410]. 132 Managed objects are accessed via a virtual information store, 133 termed the Management Information Base or MIB. MIB objects are 134 generally accessed through the Simple Network Management 135 Protocol (SNMP). Objects in the MIB are defined using the 136 mechanisms defined in the Structure of Management Information 137 (SMI). This memo specifies MIB modules that are compliant with 138 SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, 139 RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 141 3. Requirements and Use Cases 143 Firstly, to illustrate the importance of energy monitoring in 144 networks and secondly to list some of the important areas to be 145 addressed by the energy management Framework, several use cases 146 and network scenarios are presented in the EMAN applicability 147 statement document [EMAN-AS]. In addition, for each scenario, 148 the target devices for energy management, and how those devices 149 powered and metered are also presented. To address the network 150 scenarios, requirements for power and energy monitoring for 151 networking devices are specified in [EMAN-REQ]. Based on the 152 requirements [EMAN-REQ], the [EMAN-FMWK] presents an solution 153 approach. 155 Accordingly, the scope of the MIB module in this document is in 156 accordance to the requirements specified in [EMAN-REQ] and 157 [EMAN-FMWK]. 159 4. Terminology 161 EDITOR'S NOTE: 163 The individual draft submission [EMAN-TERMINOLOGY] contains the 164 terminology used in this draft. Please refer to WG draft [EMAN- 165 FMWK] for the definitions of the terminology used in this draft. 167 5. Architecture Concepts Applied to the MIB Module 169 This section describes the basic concepts specified in the 170 Energy Management Architecture [EMAN-FMWK], with specific 171 information related to the MIB module specified in this 172 document. 174 The Energy Object Context MIB module defined in this document 175 defines MIB objects for identification of Energy Objects, and 176 reporting context and relationship of an Energy Object. The 177 managed objects are contained in two tables eoTable and 178 eoProxyTable. 180 The first table eoTable focuses on the link to the other MIB 181 modules, context of the Energy Object. The second table 182 eoRelationTable specifies the relationships between Energy 183 Objects. This is a simplified representation of relationship 184 between Energy Objects. The third table eoProxyTable describes 185 the proxy capabilities of a Energy Object Parent for a specific 186 local Energy Object Child. 188 +- eoTable(2) 189 | 190 +- eoEntry(1) [entPhysicalIndex] 191 | | 192 | +-- r-n PethPsePortIndexOrZero eoEthPortIndex(1) 193 | +-- r-n PethPsePortGroupIndexOrZero eoEthPortGrpIndex(2) 194 | +-- r-n LldpPortNumberOrZero eoLldpPortNumber(3) 195 | +-- rwn MacAddress eoMgmtMacAddress(4) 196 | +-- r-n eoMgmtAddressType eoMgmtAddressType(5) 197 | +-- r-n InetAddress eoMgmtAddress(6) 198 | +-- r-n SnmpAdminString eoMgmtDNSName(7) 199 | +-- rwn SnmpAdminString eoDomainName(8) 200 | +-- rwn SnmpAdminString eoRoleDescription(9) 201 | +-- rwn EnergyObjectKeywordList eoKeywords(10) 202 | +-- rwn Integer32 eoImportance(11) 203 | +-- r-n INTEGER eoPowerCategory(12) 204 | +-- rwn SnmpAdminString eoAlternateKey(13) 205 | 206 | +- eoRelationTable 207 | | 208 | +- eoRelationEntry [entPhysicalIndex, eoRelationIndex] 209 | | | 210 | | +-- --n INTEGER eoRelationIndex(1) 211 | | +-- --n OctetString eoRelationID(2) 212 | | +-- r-n BITS eoRelationship(3) 213 | +- eoProxyTable(3) 214 | 215 | +- eoProxyEntry (1)[entPhysicalIndex , eoProxyIndex ] 216 | | 217 | | +-- --n INTEGER eoProxyIndex(1) 218 | | +-- --n OctetString eoProxyID(2) 219 | | +-- r-n BITS eoProxyAbilities(3) 221 The following UML diagram illustrates the relationship of the 222 MIB objects in the eoTable, eoRelationTable and eoProxyTable 223 that describe the identity, context and relationship of an 224 Energy Object. 226 +--------------------------+ 227 | EO Context Information | 228 | ------------------------ | 229 | eoRoleDescription | 230 | eoKeywords | 231 | eoImportance | 232 | eoPowerCategory | 233 +--------------------------+ 234 | 235 | 236 v 238 +--------------------------------+ 239 |-> | EO Identification | 240 | | ------------------------------ | 241 | | entPhysIndex (*) | 242 | | entPhysicalName (*) | 243 | | entPhysicalUris (*) (EO UUID) | 244 | | 245 | | eoEthPortIndex (**) | 246 | | eoEthPortGrpIndex (**) | 247 | | eoLldpPortNumber (***) | 248 | | eoAlternateKey | 249 | | | 250 | | eoDomainName | 251 | | eoMgmtMacAddress (optional) | 252 | | eoMgmtAddress (optional) | 253 | | eoMgmtAddressType (optional) | 254 | | eoMgmtDNSName (optional) | 255 | | | 256 | +--------------------------------+ 257 | 258 | 260 | 261 | 262 | 263 | 264 | +--------------------------+ 265 |---- | EO Relationship | 266 | | ------------------------ | 267 | | eoRelationIndex | 268 | | eoRelationID | 269 | | eoRelationship | 270 | +--------------------------+ 271 | 272 | 273 | +--------------------------+ 274 |---- | EO Proxy Relationship | 275 | | ------------------------ | 276 | | eoProxyIndex | 277 | | eoProxyID | 278 | | eoProxyAbilities | 279 | +--------------------------+ 280 | 281 | 282 | +-----------------------------------------+ 283 | | EO Identity Persistence | 284 |---| ------------------------------------- | 285 | eoTablePersistence (boolean) | 286 +-----------------------------------------+ 288 (*) Compliance From the ENTITY MIB [RFC4133] 289 (**) Link with the Power over Ethernet MIB [RFC3621] 290 (***) Link with LLDP MIBs [LLDP-MIB] [LLDP-MED-MIB] 292 Figure 1: MIB Objects Grouping 294 As displayed in figure 1, the MIB objects can be classified in 295 different logical grouping of MIB objects. 297 1) The Energy Object Identification. See Section 5.1 "Energy 298 Object Identification". Devices and their sub-components are 299 characterized by the power-related attributes of a physical 300 entity present in the ENTITY MIB [RFC4133]. 302 2) The Context Information. See Section 5.2 "Energy Object 303 Context" 304 3) The links to other MIB modules. See Section 5.3 "Links to 305 other Identifiers" 306 4) The Energy Object Child Relationships specific information. 307 See Section 5.4 "Child: Energy Objects Relationship." 308 5) The Energy Object Parent Relationships specific information. 309 See Section 5.5 "Parent: Energy Objects Relationship." 310 6) The Energy Object Identity Persistence. See Section 5.6 311 "Energy Object Identity Persistence" 313 5.1 Energy Object Identification 315 Refer to the "Energy Object Information" section in [EMAN-FMWK] 316 for background information about Energy Objects. 318 Every Energy Object MUST implement the unique index, 319 entPhysicalIndex, from the ENTITY MIB [RFC4133], which is used 320 as index for the primary Energy Object information in the 321 ENERGY-OBJECT-CONTEXT-MIB module. 323 Every Energy Object MUST have a printable name assigned to it. 324 Energy Objects MUST implement the entPhysicalName object 325 specified in the ENTITY-MIB, which must contain the Energy 326 Object name. 328 By the [RFC4133] definition, the entPhysicalUris contains a 329 white space separated list of Uniform Resource Identifier 330 (s)(URIs). For the ENERGY-OBJECT-CONTEXT-MIB compliance, every 331 Energy Object instance MUST implement the entPhysicalUris from 332 the ENTITY MIB [RFC4133]. The entPhysicalUris MUST contain the 333 Energy Object UUID, in a form consistent with [RFC4122]. Note 334 that the entPhysicalUris, from the ENTITY-MIB, is a read-write 335 managed object, and that, as a consequence the UUID could be set 336 by a management system. 338 As displayed in [RFC4122], the following is an example of the 339 string representation of a UUID as a URN: urn:uuid:f81d4fae- 340 7dec-11d0-a765-00a0c91e6bf6. 342 Other ENTITY MIB related managed objects, in addition to 343 entPhysicalIndex, entPhysicalName, and entPhysicalUris [RFC4133] 344 MAY be implemented. For example, to understand the relationship 345 between Energy Object Components and Energy Objects, the ENTITY- 346 MIB physical containment tree [RFC4133] MUST be implemented. 348 A second example deals with one of the ENTITY-MIB extensions: if 349 the Energy Object temperature is required, the managed objects 350 from the ENTITY-SENSOR-MIB [RFC3433] should be supported. 352 When an Energy Object Parent acts as a Power Aggregator or a 353 Power Proxy, the Energy Object Parent and its Energy Object 354 Child/Children MUST be members of the same Energy Management 355 Domain, specified by the eoDomainName MIB Object. 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 [EMAN-FMWK] 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 Parent. The Energy Object Children MAY inherit 366 the some of the domain parameters (possibly domain name, some of 367 the context information such as role or keywords, importance) 368 from the Energy Object Parent or the Energy Management Domain 369 MAY be configured directly in an Energy Object Child. 371 5.2 Energy Object Context 373 Refer to the "Energy Object Context" section in [EMAN-FMWK] for 374 background information. 376 An Energy Object must provide a value for eoImportance in the 377 range of 1..100 to help differentiate the use or relative value 378 of the device. The importance range is from 1 (least important) 379 to 100 (most important). The default importance value is 1. 381 An Energy Object can provide a set of eoKeywords. These keywords 382 are a list of tags that can be used for grouping and summary 383 reporting within or between Energy Management Domains. 385 An Energy Object can be classified based on the physical 386 properties of the Energy Object. That Energy Object can be 387 classified as consuming power or supplying power to other 388 devices or that Energy Object can perform both of those 389 functions and finally, an Energy Object can be a passive meter. 391 Additionally, an Energy Object can provide an eoRoleDescription 392 string that indicates the purpose the Energy Object serves in 393 the network. 395 5.3 Links to Other Identifiers 397 While the entPhysicalIndex is the primary index for all MIB 398 objects in the ENERGY-OBJECT-CONTEXT-MIB module, the Energy 399 Management Systems (EnMS) must be able to make the link with the 400 identifier(s) in other supported MIB modules. 402 If the Energy Object is a PoE port, and if the Power over 403 Ethernet MIB [RFC3621] is supported by the Energy Object SNMP 404 agent, then the Energy Object eoethPortIndex and 405 eoethPortGrpIndex MUST contain the values of pethPsePortIndex 406 and pethPsePortGroupIndex [RFC3621]. 408 The Energy Object eoLldpPortNumber MUST contain the 409 lldpLocPortNum from the LLDP MIB [LLDP-MIB], if the LLDP-MED 410 MIB is supported on the Energy Object SNMP agent. 412 The intent behind the links to the other MIB module 413 identifier(s) is to correlate the instances in the different MIB 414 modules. This will allow the ENERGY-OBJECT-CONTEXT-MIB MIB 415 module to reference other MIB modules in cases where the Power 416 over Ethernet and the LLDP MIB modules are supported by the SNMP 417 agent. Some use cases may not implement any of these two MIB 418 modules for the Energy Objects. However, in situation where any 419 of these two MIB modules are implemented, the EnMS must be able 420 to correlate the instances in the different MIB modules. 422 The eoAlternateKey alternate key object specifies a manufacturer 423 defined string that can be used to identify the Energy Object. 424 Since EnMS may need to correlate objects across management 425 systems, this alternate key is provided to facilitate such a 426 link. This optional value is intended as a foreign key or 427 alternate identifier for a manufacturer or EnMS to use to 428 correlate the unique Energy Object Id in other systems or 429 namespaces. If an alternate key is not available or is not 430 applicable then the value is the zero-length string. 432 5.4 Child: Energy Object Relationships 434 Refer to the "Energy Object Parent and Child" section in [EMAN- 435 FMWK] for the definition and background information. 437 In order to link the Energy Object Child and the Energy Object 438 Parent, a separate table (eoRelationTable) has been introduced 439 in this MIB module. The following relationships between Energy 440 objects have been considered in the eoRelationTable. 442 Metering Relationship -> meteredby , metering 444 Power Source Relationship -> poweredby , powering 446 Aggregation Relationship -> aggregatedby , aggregating 448 Proxy Relationship -> proxyby , proxying 450 Each Energy object can have one or more Energy Object 451 relationships with other Energy Objects. Depending on the 452 direction of the relationship, an Energy Object can be 453 considered as an Energy Object Parent or an Energy Object Child. 454 The relationship between the Energy Objects is specified with an 455 arbitrary index and the UUID of the remote Energy Object. The 456 UUID MUST comply to the RFC 4122 specifications. It is 457 important to note that it is possible that an Energy Object may 458 not have an Energy Object relationship with other Energy 459 Objects. 461 Proxy is a special relationship, and the Energy Object can 462 designate another Energy Object that can have the proxy 463 capabilities such as energy reporting, power state 464 configurations, non physical wake capabilities (such as Wake-on- 465 LAN)), or any combination of capabilities. 467 The eoProxyAbilities object is specific to the Proxy 468 Relationship. This object describes the capabilities of the 469 Energy Object Parent for the Energy Object Child represented by 470 the entPhysicalIndex. The possible capabilities are: report, 471 configuration, and/or wakeonlan. This object only applies to an 472 Energy Object Child. 474 Since the communication between the Energy Object Parent and 475 Energy Object Child may not be via SNMP (as defined in EMAN- 476 FMWK), an Energy Object Child can have additional MIB objects 477 that can be used for easier identification by the EnMS. The 478 optional objects eoMgmtMacAddress, eoMgmtAddressType 479 eoMgmtDNSName can be used to help identify the relationship 480 between the child and other NMS objects. These objects can be 481 used as an alternate key to help link the Energy Object with 482 other keyed information that may be stored within the EnMS(s). 484 5.5 Parent: Energy Object Relationships 486 When the Energy Object is an Energy Object Parent, the 487 relationship table specifies the relationships to every Energy 488 Object children. The explicit relationship between the Energy 489 Object parent and each Energy Object child can be powering, 490 metering, proxying and aggregating. 492 5.6 Energy Object Identity Persistence 494 In some situations, the Energy Object identity information 495 should be persistent even after a device reload. For example, 496 in a static setup where a switch monitors a series of connected 497 PoE phones, there is a clear benefit for the EnMS if the Energy 498 Object Identification and all associated information persist, as 499 it saves a network discovery. However, in other situations, 500 such as a wireless access point monitoring the mobile user PCs, 501 there is not much advantage to persist the Energy Object 502 Information. The identity information of an Energy Object 503 should be persisted and there is value in the writable MIB 504 objects persisted. 506 6. MIB Definitions 508 -- ************************************************************ 509 -- 510 -- 511 -- This MIB is used for describing the identity and the 512 -- context information of Energy Objects in network 513 -- 514 -- 515 -- ************************************************************* 517 ENERGY-OBJECT-CONTEXT-MIB DEFINITIONS ::= BEGIN 519 IMPORTS 520 MODULE-IDENTITY, 521 OBJECT-TYPE, 522 mib-2, 523 Integer32 524 FROM SNMPv2-SMI 525 TEXTUAL-CONVENTION, MacAddress, TruthValue 526 FROM SNMPv2-TC 527 MODULE-COMPLIANCE, 528 OBJECT-GROUP 529 FROM SNMPv2-CONF 530 SnmpAdminString 531 FROM SNMP-FRAMEWORK-MIB 532 InetAddressType, InetAddress 533 FROM INET-ADDRESS-MIB 534 entPhysicalIndex 535 FROM ENTITY-MIB; 537 energyAwareMIB MODULE-IDENTITY 538 LAST-UPDATED "201207100000Z" 539 ORGANIZATION "IETF EMAN Working Group" 540 CONTACT-INFO 541 "WG Charter: 542 http://datatracker.ietf.org/wg/eman/charter/ 544 Mailing Lists: 545 General Discussion: eman@ietf.org 546 To Subscribe: https://www.ietf.org/mailman/listinfo/eman 547 Archive: http://www.ietf.org/mail-archive/web/eman 549 Editors: 550 John Parello 551 Cisco Systems, Inc. 552 3550 Cisco Way 553 San Jose, California 95134 554 US 555 Phone: +1 408 525 2339 556 Email: jparello@cisco.com 558 Benoit Claise 559 Cisco Systems, Inc. 560 De Kleetlaan 6a b1 561 Degem 1831 562 Belgium 563 Phone: +32 2 704 5622 564 Email: bclaise@cisco.com 566 Mouli Chandramouli 567 Cisco Systems, Inc. 568 Sarjapur Outer Ring Road 569 Bangalore, 570 IN 571 Phone: +91 80 4426 3947 572 Email: moulchan@cisco.com" 574 DESCRIPTION 575 "This MIB is used for describing the identity and the 576 context information of Energy Objects" 577 REVISION 578 "201207100000Z" 579 DESCRIPTION 580 "Initial version, published as RFC XXXX." 582 ::= { mib-2 xxxxx } 584 energyAwareMIBNotifs OBJECT IDENTIFIER 585 ::= { energyAwareMIB 0 } 587 energyAwareMIBObjects OBJECT IDENTIFIER 588 ::= { energyAwareMIB 2 } 590 energyAwareMIBConform OBJECT IDENTIFIER 591 ::= { energyAwareMIB 3 } 593 -- Textual Conventions 595 PethPsePortIndexOrZero ::= TEXTUAL-CONVENTION 596 DISPLAY-HINT "d" 597 STATUS current 598 DESCRIPTION 599 "This textual convention is an extension of the 600 pethPsePortIndex convention, which defines a greater than 601 zero value used to identify a power Ethernet PSE port. 602 This extension permits the additional value of zero. The 603 semantics of the value zero are object-specific and must, 604 therefore, be defined as part of the description of any 605 object that uses this syntax. Examples of the usage of 606 this extension are situations where none or all physical 607 entities need to be referenced." 609 SYNTAX Integer32 (0..2147483647) 611 PethPsePortGroupIndexOrZero::= TEXTUAL-CONVENTION 612 DISPLAY-HINT "d" 613 STATUS current 614 DESCRIPTION 615 "This textual convention is an extension of the 616 pethPsePortGroupIndex convention from the Power Over 617 Ethernet MIB [RFC3621], which defines a greater than zero 618 value used to identify group containing the port to which 619 a power Ethernet PSE is connected. This extension 620 permits the additional value of zero. The semantics of 621 the value zero are object-specific and must, therefore, 622 be defined as part of the description of any object that 623 uses this syntax. Examples of the usage of this 624 extension are situations where none or all physical 625 entities need to be referenced." 626 SYNTAX Integer32 (0..2147483647) 628 LldpPortNumberOrZero ::= TEXTUAL-CONVENTION 629 DISPLAY-HINT "d" 630 STATUS current 631 DESCRIPTION 632 "This textual convention is an extension of the 633 LldpPortNumber convention specified in the LLDP MIB, 634 which defines a greater than zero value used to uniquely 635 identify each port contained in the chassis (that is 636 known to the LLDP agent) by a port number. This 637 extension permits the additional value of zero. The 638 semantics of the value zero are object-specific and must, 639 therefore, be defined as part of the description of any 640 object that uses this syntax. Examples of the usage of 641 this extension are situations where none or all physical 642 entities need to be referenced." 643 SYNTAX Integer32(0..4096) 645 EnergyObjectUUID ::= TEXTUAL-CONVENTION 646 STATUS current 647 DESCRIPTION 648 "An arbitrary value that uniquely identifies the Energy 649 Object. The object contains a single URI and, therefore, 650 the syntax of this object must conform to IETF RFC 652 4122." 653 REFERENCE 654 "RFC 3986, Uniform Resource Identifiers (URI): Generic 655 Syntax, section 2, August 1998. 656 RFC 4122, Uniform Resource Identifier (UUID) URN 657 Namespace, July 2005." 658 SYNTAX OCTET STRING (SIZE (0..65535)) 660 EnergyObjectKeywordList ::= TEXTUAL-CONVENTION 661 STATUS current 662 DESCRIPTION 663 "A list of keywords that can be used to group Energy 664 Objects for reporting or searching. If multiple keywords 665 are present, then this string will contain all the 666 keywords separated by the ',' character. All alphanumeric 667 characters and symbols (other than a comma), such as #, 668 (, $, !, and &, are allowed. White spaces before and 669 after the commas are excluded, as well as within a 670 keyword itself. 672 For example, if an Energy Object were to be tagged with 673 the keyword values 'hospitality' and 'guest', then the 674 keyword list will be 'hospitality,guest'." 675 SYNTAX OCTET STRING (SIZE (0..2048)) 677 EnergyRelations ::= TEXTUAL-CONVENTION 678 STATUS current 679 DESCRIPTION 680 "This object specifies relationship between Energy 681 Objects. For example, poweredby relationship indicates, 682 Energy Object A is powered by Energy Object B. From the 683 point of view of Energy Object B, it is powering Energy 684 Object A. " 685 SYNTAX BITS { 686 none (0), -- 687 poweredby(1), -- power relationship 688 powering(2), 689 meteredby(3), -- meter relationship 690 metering(4), 691 proxyby(5), -- proxy relatioship 692 proxying(6), 693 aggregatedby(7), -- aggregation relationship 694 aggregating(8) 695 } 697 -- Objects 699 eoTablePersistence OBJECT-TYPE 700 SYNTAX TruthValue 701 MAX-ACCESS read-write 702 STATUS current 703 DESCRIPTION 704 "This object enables/disables persistence re- 705 initializations of the local management subsystem for 706 all entries in the eoTable, eoRelationsTable and 707 eoProxyTable. A value of true(1) enables the persistence, 708 while a value of false(2) disables the persistence." 709 ::= { energyAwareMIBObjects 1 } 711 eoTable OBJECT-TYPE 712 SYNTAX SEQUENCE OF EoEntry 713 MAX-ACCESS not-accessible 714 STATUS current 715 DESCRIPTION 716 "This table lists Energy Objects." 717 ::= { energyAwareMIBObjects 2 } 719 eoEntry OBJECT-TYPE 720 SYNTAX EoEntry 721 MAX-ACCESS not-accessible 722 STATUS current 723 DESCRIPTION 724 "An entry describes the attributes of an Energy Object. 725 Whenever a new Energy Object is added or an existing 726 Energy Object is deleted, a row in the eoTable is added 727 or deleted." 729 INDEX {entPhysicalIndex } 730 ::= { eoTable 1 } 732 EoEntry ::= SEQUENCE { 733 eoEthPortIndex PethPsePortIndexOrZero, 734 eoEthPortGrpIndex PethPsePortGroupIndexOrZero, 735 eoLldpPortNumber LldpPortNumberOrZero, 736 eoMgmtMacAddress MacAddress, 737 eoMgmtAddressType InetAddressType, 738 eoMgmtAddress InetAddress, 739 eoMgmtDNSName SnmpAdminString, 740 eoDomainName SnmpAdminString, 741 eoRoleDescription SnmpAdminString, 742 eoKeywords EnergyObjectKeywordList, 743 eoImportance Integer32, 744 eoPowerCategory INTEGER, 745 eoAlternateKey SnmpAdminString 747 } 749 eoEthPortIndex OBJECT-TYPE 750 SYNTAX PethPsePortIndexOrZero 751 MAX-ACCESS read-only 752 STATUS current 753 DESCRIPTION 754 "This variable uniquely identifies the power Ethernet 755 port to which the attached device is connected [RFC3621]. 756 In addition, PoE MIB should be instantiated on the 757 device. If such a power Ethernet port cannot be specified 758 or is not known then the object is zero." 759 ::= { eoEntry 1 } 761 eoEthPortGrpIndex OBJECT-TYPE 762 SYNTAX PethPsePortGroupIndexOrZero 763 MAX-ACCESS read-only 764 STATUS current 765 DESCRIPTION 766 "This variable uniquely identifies the group containing 767 the port to which a power Ethernet PSE is connected 768 [RFC3621]. In addition, PoE MIB should be instantiated on 769 the device. If such a group cannot be specified or is not 770 known then the object is zero." 771 ::= { eoEntry 2 } 773 eoLldpPortNumber OBJECT-TYPE 774 SYNTAX LldpPortNumberOrZero 775 MAX-ACCESS read-only 776 STATUS current 777 DESCRIPTION 778 "This variable uniquely identifies the port component 779 (contained in the local chassis with the LLDP agent) as 780 defined by the lldpLocPortNum in the [LLDP-MIB] and 781 [LLDP-MED-MIB]. In addition, LLDP MIB should be 782 instantiated on the device If such a port number cannot 783 be specified or is not known then the object is zero." 784 ::= { eoEntry 3 } 786 eoMgmtMacAddress OBJECT-TYPE 787 SYNTAX MacAddress 788 MAX-ACCESS read-only 789 STATUS current 790 DESCRIPTION 791 "This object specifies a MAC address of the Energy 792 Object. This object typically only applies to Energy 793 Object Children. This object can be used as an alternate 794 key to help link the Energy Object with other keyed 795 information that may be stored within the EnMS(s). The 796 eoMgmtMacAddress MIB object SHOULD be implemented for 797 Energy Object Children, and MAY be implemented for Energy 798 Object Parents." 799 ::= { eoEntry 4 } 801 eoMgmtAddressType OBJECT-TYPE 802 SYNTAX InetAddressType 803 MAX-ACCESS read-only 804 STATUS current 805 DESCRIPTION 806 "This object specifies the eoMgmtAddress type, i.e. an 807 IPv4 address or an IPv6 address. This object MUST be 808 populated when eoMgmtAddress is populated. The 809 eoMgmtAddressType MIB object SHOULD be implemented for 810 Energy Object Children, and MAY be implemented for Energy 811 Object Parents." 812 ::= { eoEntry 5 } 814 eoMgmtAddress OBJECT-TYPE 815 SYNTAX InetAddress 816 MAX-ACCESS read-only 817 STATUS current 818 DESCRIPTION 819 "This object specifies the management address as an IPv4 820 address or IPv6 address of Energy Object. The IP address 821 type, i.e. IPv4 or IPv6, is determined by the 822 eoMgmtAddressType value. This object can be used as an 823 alternate key to help link the Energy Object with other 824 keyed information that may be stored within the EnMS(s). 825 The eoMgmtAddress MIB object SHOULD be implemented for 826 Energy Object Children, and MAY be implemented for Energy 827 Object Parents." 828 ::= { eoEntry 6 } 830 eoMgmtDNSName OBJECT-TYPE 831 SYNTAX SnmpAdminString 832 MAX-ACCESS read-only 833 STATUS current 834 DESCRIPTION 835 "This object specifies the DNS name of the eoMgmtAddress. 836 This object can be used as an alternate key to help link 837 the Energy Object with other keyed information that may 838 be stored within the EnMS(s). The eoMgmtDNSName MIB 839 objects SHOULD be implemented for Energy Object Children, 840 and MAY be implemented for Energy Object Parents." 842 ::= { eoEntry 7 } 844 eoDomainName OBJECT-TYPE 845 SYNTAX SnmpAdminString 846 MAX-ACCESS read-write 847 STATUS current 848 DESCRIPTION 849 "This object specifies the name of an Energy Management 850 Domain for the Energy Object. This object specifies a 851 zero-length string value if no Energy Management Domain 852 name is configured. The value of eoDomainName must remain 853 constant at least from one re-initialization of the 854 Energy Objects local management system to the next re- 855 initialization." 857 ::= { eoEntry 8 } 859 eoRoleDescription OBJECT-TYPE 860 SYNTAX SnmpAdminString 861 MAX-ACCESS read-write 862 STATUS current 863 DESCRIPTION 864 "This object specifies an administratively assigned name 865 to indicate the purpose an Energy Object serves in the 866 network. 868 For example, we can have a phone deployed to a lobby with 869 eoRoleDescription as 'Lobby phone'. 871 This object specifies the value is the zero-length string 872 value if no role description is configured." 874 ::= { eoEntry 9 } 876 eoKeywords OBJECT-TYPE 877 SYNTAX EnergyObjectKeywordList 878 MAX-ACCESS read-write 879 STATUS current 880 DESCRIPTION 881 "This object specifies a list of keywords that can be 882 used to group Energy Objects for reporting or searching. 883 The value is the zero-length string if no keywords have 884 been configured. If multiple keywords are present, then 885 this string will contain all the keywords separated by 886 the ',' character. For example, if an Energy Object were 887 to be tagged with the keyword values 'hospitality' and 888 'guest', then the keyword list will be 889 'hospitality,guest'. 891 If write access is implemented and a value is written 892 into the instance, the agent must retain the supplied 893 value in the eoKeywords instance associated with 894 the same physical entity for as long as that entity 895 remains instantiated. This includes instantiations 896 across all re-initializations/reboots of the local 897 management agent. eoKeywords shall be persistent 898 independent of eoTablePersistence. " 899 ::= { eoEntry 10 } 901 eoImportance OBJECT-TYPE 902 SYNTAX Integer32 (1..100) 903 MAX-ACCESS read-write 904 STATUS current 905 DESCRIPTION 906 "This object specifies a ranking of how important the 907 Energy Object is (on a scale of 1 to 100) compared with 908 other Energy Objects in the same Energy Management 909 Domain. The ranking should provide a business or 910 operational context for the Energy Object as compared to 911 other similar Energy Objects. This ranking could be used 912 as input for policy-based network management. 914 Although network managers must establish their own 915 ranking, the following is a broad recommendation: 917 90 to 100 Emergency response 918 80 to 90 Executive or business critical 919 70 to 79 General or Average 920 60 to 69 Staff or support 921 40 to 59 Public or guest 922 1 to 39 Decorative or hospitality" 923 DEFVAL { 1 } 924 ::= { eoEntry 11 } 926 eoPowerCategory OBJECT-TYPE 927 SYNTAX INTEGER { 928 consumer(0), 929 producer(1), 930 consumerproducer(2), 931 meter(3) 932 } 933 MAX-ACCESS read-only 934 STATUS current 935 DESCRIPTION 936 "This object describes the Energy Object category, which 937 indicates the expected behavior or physical property of 938 the Energy Object, based on its design. An Energy Object 939 can be a consumer(0), producer(1), or consumerproducer 940 (2) or meter (3). 942 There are devices with a dual mode - consuming energy and 943 producing of energy and those are identified as 944 consumerproducer. 946 In some cases, a meter is required to measure the power 947 consumption. In such a case, this meter Energy Object 948 category is meter(3). " 949 ::= { eoEntry 12 } 951 eoAlternateKey OBJECT-TYPE 952 SYNTAX SnmpAdminString 953 MAX-ACCESS read-write 954 STATUS current 955 DESCRIPTION 956 "This object specifies a manufacturer defined string that 957 can be used to identify the Energy Object. Since Energy 958 Management Systems (EnMS) and Network Management Systems 959 (NMS) may need to correlate objects across management 960 systems, this alternate key is provided to provide such a 961 link. This optional value is intended as a foreign key or 962 alternate identifier for a manufacturer or EnMS/NMS to 963 use to correlate the unique Energy Object Id in other 964 systems or namespaces. If an alternate key is not 965 available or is not applicable then the value is the 966 zero-length string." 968 ::= { eoEntry 13 } 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 Objects." 976 ::= { energyAwareMIBObjects 3 } 978 eoRelationEntry OBJECT-TYPE 979 SYNTAX EoRelationEntry 980 MAX-ACCESS not-accessible 981 STATUS current 982 DESCRIPTION 983 "An entry in this table describes the relationship between 984 Energy objects." 985 INDEX { entPhysicalIndex, eoRelationIndex } 986 ::= { eoRelationTable 1 } 988 EoRelationEntry ::= SEQUENCE { 989 eoRelationIndex Integer32, 990 eoRelationID EnergyObjectUUID, 991 eoRelationship EnergyRelations 992 } 994 eoRelationIndex OBJECT-TYPE 995 SYNTAX Integer32 (0..2147483647) 996 MAX-ACCESS not-accesible 997 STATUS current 998 DESCRIPTION 999 "This object is an arbitrary index to identify the Energy Object 1000 related to another Energy Object" 1001 ::= { eoRelationEntry 1 } 1003 eoRelationID OBJECT-TYPE 1004 SYNTAX EnergyObjectUUID 1005 MAX-ACCESS read-only 1006 STATUS current 1007 DESCRIPTION 1009 "This object specifies the Universally Unique Identifier (UUID) 1010 of the peer (other) Energy Object. The UUID must comply to the 1011 RFC 4122 specifications. " 1012 ::= { eoRelationEntry 2 } 1014 eoRelationship OBJECT-TYPE 1015 SYNTAX EnergyRelations 1016 MAX-ACCESS read-write 1017 STATUS current 1018 DESCRIPTION 1019 "This object describes the relations between Energy objects. For 1020 each Energy object, the relations between the other Energy 1021 objects are specified using the bitmap. If the Energy Object is 1022 a Parent and has no other relations, none(0) is specified." 1023 ::= { eoRelationEntry 3 } 1025 eoProxyTable OBJECT-TYPE 1026 SYNTAX SEQUENCE OF EoProxyEntry 1027 MAX-ACCESS not-accessible 1028 STATUS current 1029 DESCRIPTION 1030 "This table describes the proxy capabilities of a Energy 1031 Object Parent for a specific local Energy Object Child. " 1032 ::= { energyAwareMIBObjects 4 } 1034 eoProxyEntry OBJECT-TYPE 1035 SYNTAX EoProxyEntry 1036 MAX-ACCESS not-accessible 1037 STATUS current 1038 DESCRIPTION 1039 "An entry describes the attributes of an Energy Object. 1040 Whenever a new Energy Object is added or deleted, a row 1041 in the eoProxyTable is added or deleted." 1042 INDEX { entPhysicalIndex, eoProxyIndex } 1043 ::= { eoProxyTable 1 } 1045 EoProxyEntry ::= SEQUENCE { 1046 eoProxyIndex Integer32, 1047 eoProxyID EnergyObjectUUID, 1048 eoProxyAbilities BITS 1049 } 1051 eoProxyIndex OBJECT-TYPE 1052 SYNTAX Integer32 (0..2147483647) 1053 MAX-ACCESS not-accessible 1054 STATUS current 1055 DESCRIPTION 1056 "This object is an arbitrary index for an Energy Object." 1057 ::= { eoProxyEntry 1 } 1059 eoProxyID OBJECT-TYPE 1060 SYNTAX EnergyObjectUUID 1061 MAX-ACCESS read-only 1062 STATUS current 1063 DESCRIPTION 1064 "This object describes the Universally Unique Identifier 1065 (UUID) of the Energy Object Parent. 1067 The UUID must comply to the RFC 4122 specifications. 1069 The object contains an URI and, therefore, the syntax of 1070 this object must conform to RFC 3986, section 2." 1071 REFERENCE 1072 "RFC 3986, Uniform Resource Identifiers (URI): Generic 1073 Syntax, section 2, August 1998. 1074 RFC 4122, Uniform Resource Identifier (UUID) URN 1075 Namespace, July 2005." 1077 ::= { eoProxyEntry 2 } 1079 eoProxyAbilities OBJECT-TYPE 1080 SYNTAX BITS { 1081 none(0), 1082 report(1), 1083 configuration(2), 1084 wakeonlan(3) 1085 } 1086 MAX-ACCESS read-only 1087 STATUS current 1088 DESCRIPTION 1089 "This object describes the proxy capabilities of the 1090 Energy Object Parent for the local Energy Object 1091 Child speficied in the EoRelationTable. none (0) is be 1092 used when the Energy Object Parent does not have any 1093 proxy abilities regarding the Energy Object Child. 1094 report(1) indicates that the Energy Object Parent reports 1095 the usage for the Energy Object Child. 1096 configuration(2) indicates that the Energy Object Parent 1097 can configure the Power Level for the Energy Object 1098 Child. 1100 wakeonlan(3) indicates that the Energy Object Parent can 1101 wake up the Energy Object Child (the mechanism is 1102 unspecified)." 1103 ::= { eoProxyEntry 3 } 1105 -- Conformance 1107 energyAwareMIBCompliances OBJECT IDENTIFIER 1108 ::= { energyAwareMIBObjects 5 } 1110 energyAwareMIBGroups OBJECT IDENTIFIER 1111 ::= { energyAwareMIBObjects 6 } 1113 energyAwareMIBFullCompliance MODULE-COMPLIANCE 1114 STATUS current 1115 DESCRIPTION 1116 "When this MIB is implemented with support for 1117 read-write, then such an implementation can 1118 claim full compliance. Such devices can then 1119 be both monitored and configured with this MIB. 1120 The entPhysicalIndex, entPhysicalName, and 1121 entPhysicalUris [RFC4133] MUST be implemented." 1123 MODULE -- this module 1124 MANDATORY-GROUPS { 1125 energyAwareMIBTableGroup, 1126 energyAwareRelationTableGroup 1128 } 1130 GROUP energyAwareOptionalMIBTableGroup 1131 DESCRIPTION 1132 "A compliant implementation does not have to 1133 implement. The entPhysicalIndex, 1134 entPhysicalName, and entPhysicalUris [RFC4133] 1135 MUST be implemented. " 1137 GROUP energyAwareProxyTableGroup 1139 DESCRIPTION "A compliant MIB implementation does 1140 not have to implement. The entPhysicalIndex, 1141 entPhysicalName, and entPhysicalUris [RFC4133] 1142 MUST be implemented." 1144 ::= { energyAwareMIBCompliances 1 } 1146 energyAwareMIBReadOnlyCompliance MODULE-COMPLIANCE 1147 STATUS current 1148 DESCRIPTION 1149 "When this MIB is implemented without support for 1150 read-write (i.e. in read-only mode), then such an 1151 implementation can claim read-only compliance. Such a 1152 device can then be monitored but cannot be configured 1153 with this MIB. The entPhysicalIndex, entPhysicalName, 1154 and entPhysicalUris [RFC4133] MUST be implemented." 1155 MODULE -- this module 1157 MANDATORY-GROUPS { 1158 energyAwareMIBTableGroup, 1159 energyAwareRelationTableGroup 1161 } 1163 GROUP energyAwareOptionalMIBTableGroup 1164 DESCRIPTION 1165 "A compliant implementation does not have to implement 1166 the managed objects in this GROUP. Thee entPhysicalIndex, 1167 entPhysicalName, and entPhysicalUris [RFC4133] MUST be 1168 implemented. " 1170 OBJECT eoTablePersistence 1171 MIN-ACCESS read-only 1172 DESCRIPTION 1173 "Write access is not required." 1175 ::= { energyAwareMIBCompliances 2 } 1177 -- Units of Conformance 1179 energyAwareMIBTableGroup OBJECT-GROUP 1180 OBJECTS { 1181 eoTablePersistence, 1182 eoDomainName, 1183 eoRoleDescription, 1184 eoAlternateKey, 1185 eoKeywords, 1186 eoImportance, 1187 eoPowerCategory 1189 } 1190 STATUS current 1191 DESCRIPTION 1192 "This group contains the collection of all the objects 1193 related to the EnergyObject. The entPhysicalIndex, 1194 entPhysicalName, and entPhysicalUris [RFC4133] 1195 MUST be implemented." 1196 ::= { energyAwareMIBGroups 1 } 1198 energyAwareOptionalMIBTableGroup OBJECT-GROUP 1199 OBJECTS { 1201 eoEthPortIndex, 1202 eoEthPortGrpIndex, 1203 eoLldpPortNumber, 1204 eoMgmtMacAddress, 1205 eoMgmtAddressType, 1206 eoMgmtAddress, 1207 eoMgmtDNSName 1208 } 1209 STATUS current 1210 DESCRIPTION 1211 "This group contains the collection of all the objects 1212 related to the Energy Object." 1213 ::= { energyAwareMIBGroups 2 } 1215 energyAwareRelationTableGroup OBJECT-GROUP 1216 OBJECTS { 1217 -- Note that object eoRelationIndex is not 1218 -- included since it is not-accessible 1220 eoRelationID, 1221 eoRelationship 1222 } 1223 STATUS current 1224 DESCRIPTION 1225 "This group contains the collection of all objects 1226 specifying the relationship between Energy Objects." 1227 ::= { energyAwareMIBGroups 3 } 1229 energyAwareProxyTableGroup OBJECT-GROUP 1230 OBJECTS { 1231 -- Note that object eoProxyIndex is not 1232 -- included since it is not-accessible 1233 eoProxyID, 1234 eoProxyAbilities 1236 } 1237 STATUS current 1238 DESCRIPTION 1239 "This group contains the collection of all objects 1240 specifying the Proxy relationship." 1241 ::= { energyAwareMIBGroups 4 } 1243 END 1245 7. Security Considerations 1247 Some of the readable objects in these MIB modules (i.e., objects 1248 with a MAX-ACCESS other than not-accessible) may be considered 1249 sensitive or vulnerable in some network environments. It is 1250 thus important to control even GET and/or NOTIFY access to these 1251 objects and possibly to even encrypt the values of these objects 1252 when sending them over the network via SNMP. 1254 There are a number of management objects defined in these MIB 1255 modules with a MAX-ACCESS clause of read-write and/or read- 1256 create. Such objects MAY be considered sensitive or vulnerable 1257 in some network environments. The support for SET operations in 1258 a non-secure environment without proper protection can have a 1259 negative effect on network operations. The following are the 1260 tables and objects and their sensitivity/vulnerability: 1262 . Unauthorized changes to the eoDomainName, entPhysicalName, 1263 eoRoleDescription, eoKeywords, and/or eoImportance MAY 1264 disrupt power and energy collection, and therefore any 1265 predefined policies defined in the network. 1267 SNMP versions prior to SNMPv3 did not include adequate security. 1268 Even if the network itself is secure (for example, by using 1269 IPsec), there is still no secure control over who on the secure 1270 network is allowed to access and GET/SET 1271 (read/change/create/delete) the objects in these MIB modules. 1273 It is RECOMMENDED that implementers consider the security 1274 features as provided by the SNMPv3 framework (see [RFC3410], 1275 section 8), including full support for the SNMPv3 cryptographic 1276 mechanisms (for authentication and privacy). 1278 Further, deployment of SNMP versions prior to SNMPv3 is NOT 1279 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 1280 enable cryptographic security. It is then a customer/operator 1281 responsibility to ensure that the SNMP entity giving access to 1282 an instance of these MIB modules is properly configured to give 1283 access to the objects only to those principals (users) that have 1284 legitimate rights to GET or SET (change/create/delete) them. 1286 8. IANA Considerations 1288 The MIB module in this document uses the following IANA-assigned 1289 OBJECT IDENTIFIER values recorded in the SMI Numbers registry: 1291 Descriptor OBJECT IDENTIFIER value 1292 ---------- ----------------------- 1293 energyAwareMIB { mib-2 xxx } 1295 Additions to this MIB module are subject to Expert Review 1296 [RFC5226], i.e., review by one of a group of experts designated 1297 by an IETF Area Director. The group of experts MUST check the 1298 requested MIB objects for completeness and accuracy of the 1299 description. Requests for MIB objects that duplicate the 1300 functionality of existing objects SHOULD be declined. The 1301 smallest available OID SHOULD be assigned to a new MIB objects. 1302 The specification of new MIB objects SHOULD follow the structure 1303 specified in Section 6 and MUST be published using a well- 1304 established and persistent publication medium. 1306 9. Acknowledgement 1308 We would like to thank Juergen Quittek and Juergen Schoenwalder 1309 for their suggestions on the new design of EnergyRelationsTable 1310 which was a proposed solution for the open issue on the 1311 representation of Energy Object children as a UUIDlist. 1313 Many thanks to Juergen Quittek for many comments on the wording, 1314 text and design of the MIB thus resulting in an improved draft. 1316 In addition the authors thank Bill Mielke for his multiple 1317 reviews, Brad Schoening and Juergen Schoenwaelder for their 1318 suggestions and Michael Brown for dramatically improving this 1319 draft. 1321 10. Open Issues 1323 OPEN ISSUE 1: Do we need global persistence with the object 1324 eoTablePersistence; some objects in the eoTable are read-only 1325 objects. 1327 OPEN ISSUE 2: Can we have persistence of entPhysicalIndex or 1328 entPhysicalUris. That implies persistence of Entity MIB objects. 1329 How about persistence of PoE MIB objects ? 1331 11. References 1333 11.1. Normative References 1335 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 1336 Requirement Levels, BCP 14, RFC 2119, March 1997. 1338 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1339 Schoenwaelder, Ed., "Structure of Management 1340 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1341 1999. 1343 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1344 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 1345 STD 58, RFC 2579, April 1999. 1347 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 1348 "Conformance Statements for SMIv2", STD 58, RFC 2580, 1349 April 1999. 1351 [RFC3621] Berger, A., and D. Romascanu, "Power Ethernet MIB", 1352 RFC3621, December 2003. 1354 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, 1355 "Uniform Resource Identifier (URI): Generic Syntax", 1356 RFC 3986, January 2005 1358 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1359 Unique IDentifier (UUID) URN Namespace ", RFC 4122, 1360 July 2005. 1362 [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 1363 3)", RFC 4133, August 2005. 1365 [LLDP-MIB] IEEE 802.1AB-2005, "Management Information Base 1366 module for LLDP configuration, statistics, local system 1367 data and remote systems data components", May 2005. 1369 [LLDP-MED-MIB] ANSI/TIA-1057, "The LLDP Management Information 1370 Base extension module for TIA-TR41.4 media endpoint 1371 discovery information", July 2005. 1373 [EMAN-MON-MIB] M. Chandramouli, Schoening, B., Quittek, J., 1374 Dietz, T., and B. Claise "Power and Energy Monitoring 1375 MIB", draft-ietf-eman-energy-monitoring-mib-02, March 1376 2012. 1378 11.2. Informative References 1380 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 1381 "Introduction and Applicability Statements for Internet 1382 Standard Management Framework", RFC 3410, December 1383 2002. 1385 [RFC3433] Bierman, A., Romascanu, D., and K.C. Norseth, "Entity 1386 Sensor Management Information Base", RFC 3433, December 1387 2002. 1389 [RFC5226] Narten, T. Alverstrand, H., A. and K. McCloghrie, 1390 "Guidelines for Writing an IANA Considerations Section 1391 in RFCs ", BCP 26, RFC 5226, May 2008. 1393 [EMAN-REQ] Quittek, J., Winter, R., Dietz, T., Claise, B., and 1394 M. Chandramouli, " Requirements for Energy Management", 1395 draft-ietf-eman-requirements-07, work in progress, July 1396 2012. 1398 [EMAN-FMWK] Claise, B., Parello, J., Schoening, B., and J. 1399 Quittek, "Energy Management Framework", draft-ietf- 1400 eman-framework-04, work in progress, March 2012. 1402 [EMAN-AS] Schoening, B., Chandramouli, M, and B. Nordman, 1403 "Energy Management (EMAN) Applicability Statement", 1404 draft-ietf-eman-applicability-statement-01.txt, work 1405 in progress, June 2012. 1407 [EMAN-TERMINOLOGY] J. Parello, "Energy Management Terminology", 1408 draft-parello-eman-definitions-05, work in progress, 1409 March 2012. 1411 Authors' Addresses 1413 Benoit Claise 1414 Cisco Systems, Inc. 1415 De Kleetlaan 6a b1 1416 Diegem 1813 1417 BE 1419 Phone: +32 2 704 5622 1420 Email: bclaise@cisco.com 1422 John Parello 1423 Cisco Systems, Inc. 1424 3550 Cisco Way 1425 San Jose, California 95134 1426 US 1428 Phone: +1 408 525 2339 1429 Email: jparello@cisco.com 1431 Mouli Chandramouli 1432 Cisco Systems, Inc. 1433 Sarjapur Outer Ring Road 1434 Bangalore 1435 IN 1437 Phone: +91 80 4426 3947 1438 Email: moulchan@cisco.com