idnits 2.17.1 draft-parello-eman-energy-aware-mib-00.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 == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (October 16, 2010) is 4933 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) ** 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' -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-02) exists of draft-quittek-power-monitoring-requirements-01 == Outdated reference: A later version (-02) exists of draft-claise-power-management-arch-01 == Outdated reference: A later version (-09) exists of draft-claise-energy-monitoring-mib-05 Summary: 1 error (**), 0 flaws (~~), 5 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 Cisco Systems, Inc. 5 Expires: April 16, 2011 October 16, 2010 7 Energy-aware Networks and Devices MIB 8 draft-parello-eman-energy-aware-mib-00 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance 13 with the provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet 16 Engineering Task Force (IETF), its areas, and its working 17 groups. Note that other groups may also distribute working 18 documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as 24 "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed 30 at http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on September, 2010. 34 Copyright Notice 36 Copyright (c) 2010 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with 44 respect to this document. Code Components extracted from this 45 document must include Simplified BSD License text as described 46 in Section 4.e of the Trust Legal Provisions and are provided 47 without warranty as described in the Simplified BSD License. 49 Abstract 51 This document defines a subset of the Management Information 52 Base (MIB) for power and energy monitoring of devices. 54 Conventions used in this document 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 57 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 58 and "OPTIONAL" in this document are to be interpreted as 59 described in RFC 2119 [RFC2119]. 61 Table of Contents 63 1. Introduction.............................................. 4 64 2. The Internet-Standard Management Framework................ 4 65 3. Use Cases................................................. 5 66 4. Terminology............................................... 5 67 5. Architecture Concepts Applied to the MIB Module........... 5 68 5.1 Power Monitor Information............................. 5 69 5.2 Power Monitor Meter Domain............................ 6 70 5.3 Power Monitor Parent and Child........................ 7 71 5.4 Power Monitor Context................................. 7 72 6. Structure of the MIB...................................... 7 73 7. MIB Definitions........................................... 8 74 8. Security Considerations.................................. 18 75 9. IANA Considerations...................................... 19 76 10. References.............................................. 19 77 10.1. Normative References............................... 19 78 10.2. Informative References............................. 20 79 11. Acknowledgments......................................... 21 80 TO DO 82 . The roles/capabilities that the Power Monitor Parent have 83 with Power Monitor Child(ren) are described in [POWER-MON- 84 ARCH]: 85 1. Monitoring (only reporting) 86 2. Configuration power state 87 3. Configuration: power 88 Example: on a PC, we can set power level without knowing 89 the power. A solution must be specified in this draft. 90 We have to find a way to model this role in this MIB 91 module. Bitmap is just one example. 93 1. Introduction 95 This document defines a subset of the Management Information 96 Base (MIB) for use with network management protocols for power 97 and energy monitoring of network devices and devices attached to 98 the network, as specified in the Power Management Architecture 99 [POWER-MON-ARCH], which in turn, is based on the Power 100 Monitoring Requirements [POWER-MON-REQ] . 102 This module's special focus is on monitoring energy-aware 103 networks and devices. The module addresses device 104 identification, context information, and potential relationships 105 between reporting devices, remote devices, and monitoring 106 probes. 108 Devices and their sub-components may be characterized by the 109 power-related attributes of a physical entity present in the 110 ENTITY MIB, even though ENTITY MIB compliance is not a 111 requirement due to the variety and broad base of devices 112 concerned with energy management. 114 2. The Internet-Standard Management Framework 116 For a detailed overview of the documents that describe the 117 current Internet-Standard Management Framework, please refer to 118 section 7 of RFC 3410 [RFC3410]. 120 Managed objects are accessed via a virtual information store, 121 termed the Management Information Base or MIB. MIB objects are 122 generally accessed through the Simple Network Management 123 Protocol (SNMP). Objects in the MIB are defined using the 124 mechanisms defined in the Structure of Management Information 125 (SMI). This memo specifies MIB modules that are compliant with 126 SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, 127 RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 129 3. Use Cases 131 Requirements for power and energy monitoring for networking 132 devices are specified in [POWER-MON-REQ]. The requirements in 133 [POWER-MON-REQ] cover devices typically found in communications 134 networks, such as switches, routers, and various connected 135 endpoints. For a power monitoring architecture to be useful, it 136 should also apply to facility meters, power distribution units, 137 gateway proxies for commercial building control, home automation 138 devices, and devices that interface with the utility and/or 139 smart grid. Accordingly, the scope of the MIB modules in this 140 document is broader than that specified in [POWER-MON-REQ]. 142 4. Terminology 144 The definitions of basic terms like Power Monitor, Power Monitor 145 Parent, Power Monitor Child, Power Monitor Meter Domain, Power 146 Level, and Manufacturer Power Level can be found in the Power 147 Management Architecture [POWER-MON-ARCH]. 149 5. Architecture Concepts Applied to the MIB Module 151 This section describes the basic concepts specified in the Power 152 Monitor Architecture [POWER-MON-ARCH], with specific information 153 related to the MIB module specified in this document 154 This subsection maps to the section "Architecture High Level 155 Concepts" in the Power Monitoring Architecture [POWER-MON-ARCH]. 157 5.1 Power Monitor Information 159 Refer to the "Power Monitor Information" section in [POWER-MON- 160 ARCH] for background information. An energy aware device is 161 considered an instance of a power monitor as defined in the 162 [POWER-MON-ARCH]. 164 The Power Monitor information is specified in the MIB module 165 primary table, i.e. the pmTable. Every Power Monitor SHOULD 166 have a printable name pmName, and MUST HAVE a unique Power 167 Monitor index pmIndex. 169 The pmIndex is a unique index greater than zero for each Power 170 Monitor. It is recommended that values be assigned sequentially 171 starting from 1. The value for each pmIndex must remain 172 constant at least from one re-initialization of the entity's 173 network management system to the next re-initialization. In 174 addition, the Power Monitor can potentially have an 175 entityPhysicalIndex from the ENTITY MIB [RFC4133] in the 176 pmPhysicalEntity, if supported by the Power Monitor. In case of 177 Power over Ethernet (if the Power over Ethernet MIB is supported 178 on the Power Monitor), the Power Monitor pmethPortIndex and 179 pmethPortGrpIndex must contain the values of pethPsePortIndex 180 and pethPsePortGroupIndex, respectively. In case of LLDP-MED 181 (if the LLDP-MED MIB is supported on the Power Monitor), the 182 Power Monitor pmLldpPortNumber must contain the lldpLocPortNum 183 from the LLDP MIB. 185 Possible pmName conventions are: textual DNS name, MAC-address 186 of the device, interface ifName, or a text string uniquely 187 identifying the Power Monitor. However, if entPhysicalName is 188 present for the respective pmPhysicalEntity (i.e. if the ENTITY- 189 MIB is supported), then the pmName SHOULD be identical to the 190 entPhysicalName. The pmName SHOULD be unique. As an example, 191 in the case of IP phones, pmName can be the device DNS name, 192 while in the case of router/switch line cards, the pmName should 193 contain the entPhysicalName. 195 To distinguish if a Power Monitor is considered producing, 196 consuming or metering power, the pmPowerCategory MIB object must 197 be implemented. 199 5.2 Power Monitor Meter Domain 201 Refer to the "Power Monitor Meter Domain" section in [POWER-MON- 202 ARCH] for background information. 204 Each Power Monitor MUST be a member of a Power Monitor Meter 205 Domain, specified by the pmDomainName MIB Object. The 206 pmDomainName, which is part of the pmTable, is a read-write MIB 207 object. 209 5.3 Power Monitor Parent and Child 211 Refer to the "Power Monitor Parent and Child" section in [POWER- 212 MON-ARCH] for background information. In order to link the 213 Power Monitor Child and the Power Monitor Parent, the pmParentId 214 is introduced. 216 5.4 Power Monitor Context 218 Refer to the "Power Monitor Context" section in [POWER-MON-ARCH] 219 for background information. 221 A Power Monitor can provide a pmImportance value in the range of 222 1..100 to help differentiate the use or relative value to the 223 site. The importance range is from 1 (least important) to 100 224 (most important). The default importance value is 1. 226 A Power Monitor can provide a set of pmKeywords. These keywords 227 are a list of tags that can be used for grouping and summary 228 reporting within or between Power Monitor Meter Domains. 230 Additionally, a Power Monitor can provide a pmRoleDescription 231 string that indicates the purpose the Power Monitor serves in 232 the network or for the site/business. 234 6. Structure of the MIB 236 The primary MIB object in this MIB module is the 237 EnergyAwareDeviceMIBObject. The pmTable table of 238 EnergyAwareDeviceMIBObject describes an entity in the network 239 that is a Power Monitor according the [POWER-MON-ARCH]. 241 A Power Monitor that implements the EnergyAwareDeviceMIB 242 contains information describing itself as an entity in the 243 context of the network (such as its Power Monitor Meter Domain 244 pmDomainName) and attributes for describing its business context 245 (such as pmImportance, pmRoleDescription and pmKeywords). 247 The information in this MIB describes the device itself so that 248 the device is aware of its context in a communication network 249 with respect to power. The actual power usage, which is 250 described in [POWER-MON-ARCH], is specified in [POWER-MON-MIB]. 252 7. MIB Definitions 254 -- ************************************************************ 255 -- 256 -- 257 -- This MIB is used to monitor power usage of network 258 -- devices 259 -- 260 -- ************************************************************* 262 ENERGY-AWARE-MIB DEFINITIONS ::= BEGIN 264 IMPORTS 265 MODULE-IDENTITY, 266 OBJECT-TYPE, 267 mib-2, 268 Integer32 269 FROM SNMPv2-SMI 270 TEXTUAL-CONVENTION 271 FROM SNMPv2-TC 272 MODULE-COMPLIANCE, 273 OBJECT-GROUP 274 FROM SNMPv2-CONF 275 SnmpAdminString 276 FROM SNMP-FRAMEWORK-MIB 277 PhysicalIndexOrZero 278 FROM ENTITY-MIB; 280 energyAwareMIB MODULE-IDENTITY 281 LAST-UPDATED "201010150000Z" 282 ORGANIZATION "Cisco Systems, Inc." 283 CONTACT-INFO 284 "Cisco Systems 285 Customer Service 287 Postal: 170 W Tasman Drive 288 San Jose, CA 95134 289 USA 291 Tel: +1 800 553-NETS 293 E-mail: cs-snmp@cisco.com" 295 DESCRIPTION 296 "This MIB is used to monitor power and energy in 297 devices." 298 REVISION 299 "201010150000Z" 300 DESCRIPTION 301 "Initial version, published as RFC XXXX." 303 ::= { mib-2 xxxxx } 305 energyAwareMIBNotifs OBJECT IDENTIFIER 306 ::= { energyAwareMIB 0 } 308 energyAwareMIBObjects OBJECT IDENTIFIER 309 ::= { energyAwareMIB 1 } 311 energyAwareMIBConform OBJECT IDENTIFIER 312 ::= { energyAwareMIB 2 } 314 -- Textual Conventions 316 PowerMonitorId ::= TEXTUAL-CONVENTION 317 STATUS current 318 DESCRIPTION 319 "This object indicates the Power Monitor Universally 320 Unique Identifier." 321 REFERENCE 322 "IETF RFC 4122" 323 SYNTAX OCTET STRING (SIZE (16)) 325 PethPsePortIndexOrZero ::= TEXTUAL-CONVENTION 326 DISPLAY-HINT "d" 327 STATUS current 328 DESCRIPTION 329 "This textual convention is an extension of the 330 pethPsePortIndex convention, which defines a greater than 331 zero value used to identify a power Ethernet PSE port. 332 This extension permits the additional value of zero. The 333 semantics of the value zero are object-specific and must, 334 therefore, be defined as part of the description of any 335 object that uses this syntax. Examples of the usage of 336 this extension are situations where none or all physical 337 entities need to be referenced." 338 SYNTAX Integer32 (0..2147483647) 340 PethPsePortGroupIndexOrZero::= TEXTUAL-CONVENTION 341 DISPLAY-HINT "d" 342 STATUS current 343 DESCRIPTION 344 "This textual convention is an extension of the 345 pethPsePortGroupIndex convention, which defines a greater 346 than zero value used to identify group containing the 347 port to which a power Ethernet PSE is connected. This 348 extension permits the additional value of zero. The 349 semantics of the value zero are object-specific and must, 350 therefore, be defined as part of the description of any 351 object that uses this syntax. Examples of the usage of 352 this extension are situations where none or all physical 353 entities need to be referenced." 354 SYNTAX Integer32 (0..2147483647) 356 LldpPortNumberOrZero ::= TEXTUAL-CONVENTION 357 DISPLAY-HINT "d" 358 STATUS current 359 DESCRIPTION 360 "This textual convention is an extension of the 361 LldpPortNumber convention specified in the LLDP MIB, 362 which defines a greater than zero value used to uniquely 363 identify each port contained in the chassis (that is 364 known to the LLDP agent) by a port number. This 365 extension permits the additional value of zero. The 366 semantics of the value zero are object-specific and must, 367 therefore, be defined as part of the description of any 368 object that uses this syntax. Examples of the usage of 369 this extension are situations where none or all physical 370 entities need to be referenced." 371 SYNTAX Integer32(0..4096) 373 PowerMonitorKeywordList ::= TEXTUAL-CONVENTION 374 STATUS current 375 DESCRIPTION 376 "A list of keywords that can be used to group Power 377 Monitors for reporting or searching. If multiple keywords 378 are present, then this string will contain all the 379 keywords separated by the ',' character. For example, if 380 a Power Monitor were to be tagged with the keyword values 381 'hospitality' and 'guest', then the keyword list will be 382 'hospitality,guest'." 383 SYNTAX OCTET STRING (SIZE (0..255)) 385 -- Objects 387 pmTable OBJECT-TYPE 388 SYNTAX SEQUENCE OF PmEntry 389 MAX-ACCESS not-accessible 390 STATUS current 391 DESCRIPTION 392 "This table lists Power Monitors." 393 ::= { energyAwareMIBObjects 1 } 395 pmEntry OBJECT-TYPE 396 SYNTAX PmEntry 397 MAX-ACCESS not-accessible 398 STATUS current 399 DESCRIPTION 400 "An entry describes the attributes of a Power Monitor. 401 Whenever a new Power Monitor is added or deleted a row in 402 the pmTable is added or deleted." 403 INDEX { pmIndex } 404 ::= { pmTable 1 } 406 PmEntry ::= SEQUENCE { 407 pmIndex Integer32, 408 pmPowerMonitorId PowerMonitorId, 409 pmPhysicalEntity PhysicalIndexOrZero, 410 pmEthPortIndex PethPsePortIndexOrZero, 411 pmEthPortGrpIndex PethPsePortGroupIndexOrZero, 412 pmLldpPortNumber LldpPortNumberOrZero, 413 pmName SnmpAdminString, 414 pmDomainName SnmpAdminString, 415 pmRoleDescription SnmpAdminString, 416 pmKeywords PowerMonitorKeywordList, 417 pmImportance Integer32, 418 pmPowerCategory INTEGER, 419 pmParentId PowerMonitorId 420 } 422 pmIndex OBJECT-TYPE 423 SYNTAX Integer32 (1..2147483647) 424 MAX-ACCESS not-accessible 425 STATUS current 426 DESCRIPTION 427 "A unique value, greater than zero, for each Power 428 Monitor. It is recommended that values be assigned 429 sequentially starting from 1. The value for each pmIndex 430 must remain constant at least from one re-initialization 431 of the entity's network management system to the next re- 432 initialization." 433 ::= { pmEntry 1 } 435 pmPowerMonitorId OBJECT-TYPE 436 SYNTAX PowerMonitorId 437 MAX-ACCESS read-only 438 STATUS current 439 DESCRIPTION 440 "This object indicates the Power Monitor UUID 441 identifier." 442 ::= { pmEntry 2 } 444 pmPhysicalEntity OBJECT-TYPE 445 SYNTAX PhysicalIndexOrZero 446 MAX-ACCESS read-only 447 STATUS current 448 DESCRIPTION 449 "This object contains the index of a physical entity in 450 the ENTITY MIB. This physical entity is the given 451 observation point. If such a physical entity cannot be 452 specified or is not known then the object is zero." 453 ::= { pmEntry 3 } 455 pmEthPortIndex OBJECT-TYPE 456 SYNTAX PethPsePortIndexOrZero 457 MAX-ACCESS read-only 458 STATUS current 459 DESCRIPTION 460 "This variable uniquely identifies the power Ethernet 461 port to which the attached device is connected [RFC3621]. 462 If such a power Ethernet port cannot be specified or is 463 not known then the object is zero." 464 ::= { pmEntry 4 } 466 pmEthPortGrpIndex OBJECT-TYPE 467 SYNTAX PethPsePortGroupIndexOrZero 468 MAX-ACCESS read-only 469 STATUS current 470 DESCRIPTION 471 "This variable uniquely identifies the group containing 472 the port to which a power Ethernet PSE is connected 473 [RFC3621]. If such a group cannot be specified or is not 474 known then the object is zero." 475 ::= { pmEntry 5 } 477 pmLldpPortNumber OBJECT-TYPE 478 SYNTAX LldpPortNumberOrZero 479 MAX-ACCESS read-only 480 STATUS current 481 DESCRIPTION 482 "This variable uniquely identifies the port component 483 (contained in the local chassis with the LLDP agent) as 484 defined by the lldpLocPortNum in the [LLDP-MIB] and 485 [LLDP-MED-MIB]. If such a port number cannot be specified 486 or is not known then the object is zero." 487 ::= { pmEntry 6 } 489 pmName OBJECT-TYPE 490 SYNTAX SnmpAdminString 491 MAX-ACCESS read-write 492 STATUS current 493 DESCRIPTION 494 "This object specifies a printable name, a text string, 495 for the Power Monitor. The pmName SHOULD be unique.If 496 pmPhysicalName is present for the respective 497 pmPhysicalEntity (i.e. if the ENTITY-MIB is supported), 498 then the pmName SHOULD be identical to the 499 pmPhysicalName. If pmPhysicalName is not present, the 500 process to assign the pmName can be implementation 501 specific. Example: DNS Name, MAC address in canonical 502 form, ifName, etc. 503 However, if pmPhysicalName is present for the respective 504 pmPhysicalEntity (i.e. if the ENTITY-MIB is supported), 505 then the pmName should be identical to the 506 pmPhysicalName." 507 ::= { pmEntry 7 } 509 pmDomainName OBJECT-TYPE 510 SYNTAX SnmpAdminString 511 MAX-ACCESS read-write 512 STATUS current 513 DESCRIPTION 514 "This object specifies the name of a Power Monitor Meter 515 Domain for the Power Monitor. This object specifies a 516 null string if no Power Monitor Domain name is 517 configured. The value of pmDomainName must remain 518 constant at least from one re-initialization of the 519 entity's network management system to the next re- 520 initialization." 521 ::= { pmEntry 8 } 523 pmRoleDescription OBJECT-TYPE 524 SYNTAX SnmpAdminString 525 MAX-ACCESS read-write 526 STATUS current 527 DESCRIPTION 528 "This object specifies an administratively assigned name 529 to indicate the purpose a Power Monitor serves in the 530 network. 532 For example, we can have a phone deployed to a lobby with 533 pmRoleDescription as 'Lobby IP phone'. 535 This object specifies a null string if no role 536 description is configured." 537 ::= { pmEntry 9 } 539 pmKeywords OBJECT-TYPE 540 SYNTAX PowerMonitorKeywordList 541 MAX-ACCESS read-write 542 STATUS current 543 DESCRIPTION 544 "This object specifies a list of keywords that can be 545 used to group Power Monitors for reporting or searching. 546 This object specifies the null string if no keywords have 547 been configured. If multiple keywords are present, then 548 this string will contain all the keywords separated by 549 the ',' character. For example, if a Power Monitor were 550 to be tagged with the keyword values 'hospitality' and 551 'guest', then the keyword list will be 552 'hospitality,guest'. 554 If write access is implemented and a value is written 555 into the instance, the agent must retain the supplied 556 value in the pmKeywords instance associated with 557 the same physical entity for as long as that entity 558 remains instantiated. This includes instantiations 559 across all re-initializations/reboots of the network 560 management system." 561 ::= { pmEntry 10 } 563 pmImportance OBJECT-TYPE 564 SYNTAX Integer32 (1..100) 565 MAX-ACCESS read-write 566 STATUS current 567 DESCRIPTION 568 "This object specifies a ranking of how important the 569 Power Monitor is (on a scale of 1 to 100) compared with 570 other Power Monitors in the same Power Monitor Meter 571 Domain. The ranking should provide a business or 572 operational context for the Power Monitor as compared to 573 other similar Power Monitors. This ranking could be used 574 as input for policy-based network management. 576 Although network managers must establish their own 577 ranking, the following is a broad recommendation: 579 90 to 100 Emergency response 580 80 to 90 Executive or business critical 581 70 to 79 General or Average 582 60 to 69 Staff or support 583 40 to 59 Public or guest 584 1 to 39 Decorative or hospitality" 585 DEFVAL { 1 } 586 ::= { pmEntry 11 } 588 pmPowerCategory OBJECT-TYPE 589 SYNTAX INTEGER { 590 consumer(0), 591 provider(1), 592 meter(2) 593 } 594 MAX-ACCESS read-only 595 STATUS current 596 DESCRIPTION 597 "This object describes the Power Monitor and indicates 598 the expected power usage of the Power Monitor. A Power 599 Monitor could be designed or manufactured to be a 600 provider(1), consumer(0) or meter(2) of power. 602 The actual power direction is indicated by the sign of 603 pmPower, with positive representing consumption and 604 negative representing production, and may or may not 605 match the expected value of pmPowerCategory. In these 606 cases the two objects can be used to detect unexpected 607 conditions of the Power Monitor. 609 For example a generator with a category of provider(1) 610 that is malfunctioning and is consuming power as 611 indicated by a positive pmPower value." 612 ::= { pmEntry 12 } 614 pmParentId OBJECT-TYPE 615 SYNTAX PowerMonitorId 616 MAX-ACCESS read-only 617 STATUS current 618 DESCRIPTION 619 "If the current Power Monitor has a Power Monitor Parent, 620 then its Power Monitor Id value is set in pmParentId. 621 Otherwise, the pmParentId value is the null string." 622 ::= { pmEntry 13 } 624 -- Conformance 626 energyAwareMIBCompliances OBJECT IDENTIFIER 627 ::= { energyAwareMIBObjects 3 } 629 energyAwareMIBGroups OBJECT IDENTIFIER 630 ::= { energyAwareMIBObjects 4 } 632 energyAwareMIBFullCompliance MODULE-COMPLIANCE 633 STATUS current 634 DESCRIPTION 635 "When this MIB is implemented with support for 636 read-create, then such an implementation can 637 claim full compliance. Such devices can then 638 be both monitored and configured with this MIB." 639 MODULE -- this module 640 MANDATORY-GROUPS { 641 energyAwareMIBTableGroup 642 } 644 ::= { energyAwareMIBCompliances 1 } 646 energyAwareMIBReadOnlyCompliance MODULE-COMPLIANCE 647 STATUS current 648 DESCRIPTION 649 "When this MIB is implemented without support for 650 read-create (i.e. in read-only mode), then such an 651 implementation can claim read-only compliance. Such a 652 device can then be monitored but can not be configured 653 with this MIB." 654 MODULE -- this module 655 MANDATORY-GROUPS { 656 energyAwareMIBTableGroup 657 } 659 OBJECT pmName 660 MIN-ACCESS read-only 661 DESCRIPTION 662 "Write access is not required." 664 OBJECT pmDomainName 665 MIN-ACCESS read-only 666 DESCRIPTION 667 "Write access is not required." 669 OBJECT pmRoleDescription 670 MIN-ACCESS read-only 671 DESCRIPTION 672 "Write access is not required." 674 OBJECT pmKeywords 675 MIN-ACCESS read-only 676 DESCRIPTION 677 "Write access is not required." 679 OBJECT pmImportance 680 MIN-ACCESS read-only 681 DESCRIPTION 682 "Write access is not required." 684 ::= { energyAwareMIBCompliances 2 } 686 -- Units of Conformance 688 energyAwareMIBTableGroup OBJECT-GROUP 689 OBJECTS { 690 -- Note that object pmIndex is NOT 691 -- included since it is not-accessible 692 pmPowerMonitorId, 693 pmPhysicalEntity, 694 pmEthPortIndex, 695 pmEthPortGrpIndex, 696 pmLldpPortNumber, 697 pmName, 698 pmDomainName, 699 pmRoleDescription, 700 pmKeywords, 701 pmImportance, 702 pmPowerCategory, 703 pmParentId 704 } STATUS current 705 DESCRIPTION 706 "This group contains the collection of all the objects 707 related to the PowerMonitor." 708 ::= { energyAwareMIBGroups 1 } 710 END 712 8. Security Considerations 714 Some of the readable objects in these MIB modules (i.e., objects 715 with a MAX-ACCESS other than not-accessible) may be considered 716 sensitive or vulnerable in some network environments. It is 717 thus important to control even GET and/or NOTIFY access to these 718 objects and possibly to even encrypt the values of these objects 719 when sending them over the network via SNMP. 721 There are a number of management objects defined in these MIB 722 modules with a MAX-ACCESS clause of read-write and/or read- 723 create. Such objects MAY be considered sensitive or vulnerable 724 in some network environments. The support for SET operations in 725 a non-secure environment without proper protection can have a 726 negative effect on network operations. The following are the 727 tables and objects and their sensitivity/vulnerability: 729 . Unauthorized changes to the pmDomainName, pmName, 730 pmRoleDescription, pmKeywords, and/or pmImportance MAY 731 disrupt power and energy collection, and therefore any 732 predefined policies defined in the network. 734 SNMP versions prior to SNMPv3 did not include adequate security. 735 Even if the network itself is secure (for example, by using 736 IPsec), there is still no secure control over who on the secure 737 network is allowed to access and GET/SET 738 (read/change/create/delete) the objects in these MIB modules. 740 It is RECOMMENDED that implementers consider the security 741 features as provided by the SNMPv3 framework (see [RFC3410], 742 section 8), including full support for the SNMPv3 cryptographic 743 mechanisms (for authentication and privacy). 745 Further, deployment of SNMP versions prior to SNMPv3 is NOT 746 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 747 enable cryptographic security. It is then a customer/operator 748 responsibility to ensure that the SNMP entity giving access to 749 an instance of these MIB modules is properly configured to give 750 access to the objects only to those principals (users) that have 751 legitimate rights to GET or SET (change/create/delete) them. 753 9. IANA Considerations 755 The MIB module in this document uses the following IANA-assigned 756 OBJECT IDENTIFIER values recorded in the SMI Numbers registry: 758 Descriptor OBJECT IDENTIFIER value 759 ---------- ----------------------- 760 energyAwareMIB { mib-2 xxx } 762 Additions to this MIB module are subject to Expert Review 763 [RFC5226], i.e., review by one of a group of experts designated 764 by an IETF Area Director. The group of experts MUST check the 765 requested MIB objects for completeness and accuracy of the 766 description. Requests for MIB objects that duplicate the 767 functionality of existing objects SHOULD be declined. The 768 smallest available OID SHOULD be assigned to a new MIB objects. 769 The specification of new MIB objects SHOULD follow the structure 770 specified in Section 6 and MUST be published using a well- 771 established and persistent publication medium. 773 10. References 775 10.1. Normative References 777 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 778 Requirement Levels, BCP 14, RFC 2119, March 1997. 780 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 781 Schoenwaelder, Ed., "Structure of Management 782 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 783 1999. 785 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 786 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 787 STD 58, RFC 2579, April 1999. 789 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 790 "Conformance Statements for SMIv2", STD 58, RFC 2580, 791 April 1999. 793 [RFC3621] Berger, A., and D. Romascanu, "Power Ethernet MIB", 794 RFC3621, December 2003. 796 [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 797 3)", RFC 4133, August 2005. 799 [LLDP-MIB] IEEE 802.1AB-2005, "Management Information Base 800 module for LLDP configuration, statistics, local system 801 data and remote systems data components", May 2005. 803 [LLDP-MED-MIB] ANSI/TIA-1057, "The LLDP Management Information 804 Base extension module for TIA-TR41.4 media endpoint 805 discovery information", July 2005. 807 10.2. Informative References 809 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 810 "Introduction and Applicability Statements for Internet 811 Standard Management Framework ", RFC 3410, December 812 2002. 814 [RFC5226] Narten, T. Alverstrand, H., A. and K. McCloghrie, 815 "Guidelines for Writing an IANA Considerations Section 816 in RFCs ", BCP 26, RFC 5226, May 2008. 818 [POWER-MON-REQ] Quittek, J., Winter, R., Dietz, T., Claise, B., 819 and M. Chandramouli, "Requirements for Power 820 Monitoring", draft-quittek-power-monitoring- 821 requirements-01 (work in progress), October 2009. 823 [POWER-MON-ARCH] Claise, B., Parello, J., and B. Schoening, 824 "Power Management Architecture", draft-claise-power- 825 management-arch-01 (work in progress), August 2010. 827 [POWER-MON-MIB] Claise, B., Chandramouli, M., Parello, J., and 828 B. Schoening, "Power and Energy Monitoring MIB", draft- 829 claise-energy-monitoring-mib-05 (work in progress), 830 September 2010. 832 11. Acknowledgments 834 The authors would like to Brad Schoening and Mouli Chandramouli 835 for their help, and Michael Brown for improving the text 836 dramatically. 838 Authors' Addresses 840 Benoit Claise 841 Cisco Systems Inc. 842 De Kleetlaan 6a b1 843 Diegem 1813 844 BE 846 Phone: +32 2 704 5622 847 Email: bclaise@cisco.com 849 John Parello 850 Cisco Systems Inc. 851 3550 Cisco Way 852 San Jose, California 95134 853 US 855 Phone: +1 408 525 2339 856 Email: jparello@cisco.com