idnits 2.17.1 draft-ietf-entmib-state-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 14. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' scope of this MIB.' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2004) is 7071 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) == Missing Reference: 'Alarm-MIB' is mentioned on line 110, but not defined == Missing Reference: 'Alarm MIB' is mentioned on line 210, but not defined == Missing Reference: 'ALARM-MIB' is mentioned on line 349, but not defined == Unused Reference: 'RFC3877' is defined on line 871, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2737 (Obsoleted by RFC 4133) -- Obsolete informational reference (is this intentional?): RFC 1493 (Obsoleted by RFC 4188) Summary: 14 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Entity MIB Working Group S. Chisholm 2 Internet Draft Nortel Networks 3 Document: draft-ietf-entmib-state-06.txt D. Perkins 4 Category: Standards Track SNMPinfo 5 Expiration Date: June 2005 December 2004 7 Entity State MIB 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, or 13 will be disclosed, and any of which I become aware will be disclosed, 14 in accordance with RFC 3668. 16 This document is an Internet-Draft and is in full conformance 17 with all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet- 27 Drafts as reference material or to cite them other than as 28 "work in progress." 30 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 This memo defines a portion of the Management Information Base (MIB) 40 for use with network management protocols in the Internet community. 41 In particular, it describes extensions to the Entity MIB to 42 provide information about the state of physical entities. 44 Table of Contents 46 1. The Internet-Standard Management Framework 47 2. Entity State 48 2.1. Hierarchical State Management 49 2.2. Entity Redundancy 50 2.3. Physical Entity Users 51 2.4. Physical Class Behaviour 52 3. Relationship to Other MIBs 53 3.1. Relation to Interfaces MIB 54 3.2. Relation to Alarm MIB 55 3.3. Relation to Bridge MIB 56 3.4. Relation to Host Resource MIB 57 4. Textual Conventions 58 5. Definitions 59 6. Security Considerations 60 7. Intellectual Property 61 8. Authors' Addresses 62 9. Acknowledgements 63 10. References 64 11. Full Copyright Statement 65 1. The Internet-Standard Management Framework 67 For a detailed overview of the documents that describe the current 68 Internet-Standard Management Framework, please refer to section 7 of 69 RFC 3410 [RFC3410]. 71 Managed objects are accessed via a virtual information store, termed 72 the Management Information Base or MIB. MIB objects are generally 73 accessed through the Simple Network Management Protocol (SNMP). 74 Objects in the MIB are defined using the mechanisms defined in the 75 Structure of Management Information (SMI). This memo specifies a MIB 76 module that is compliant to the SMIv2, which is described in STD 58, 77 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 78 [RFC2580]. 80 2. Entity State 82 The goal in adding state objects to the Entity MIB [RFC2737] is to 83 define a useful subset of the possible state attributes that could 84 be tracked for a given entity that both fit into the state models 85 such as those used in the Interfaces MIB [RFC2863] as well as 86 leverage existing well-deployed models. The entStateTable contains 87 state objects that are a subset of the popular ISO/OSI states that 88 are also defined in ITU's X.731 specification [X.731]. Objects are 89 defined to capture administrative, operational and usage states. In 90 addition there are further state objects defined to provide 91 additional information for these three basic states. 93 Administrative state indicates permission to use or prohibition 94 against using the entity and is imposed through the management 95 services. 97 Operational state indicates whether or not the entity is physically 98 installed and working. Note that unlike the ifOperStatus [RFC2863], 99 this operational state is independent of the administrative state. 101 Usage state indicates whether or not the entity is in use at a 102 specific instance, and if so, whether or not it currently has spare 103 capacity to serve additional users. In the context of this MIB, the 104 usage state refers to the ability of an entity to service other 105 entities within its containment hierarchy. 107 Alarm state indicates whether or not there are any alarms active 108 against the entity. In addition to those alarm states defined in 109 X.731 [X.731], warning and indeterminate status are also defined to 110 provide a more complete mapping to the Alarm MIB [Alarm-MIB]. 112 Standby state indicates whether the entity is currently running as 113 hot standby, cold standby or is currently providing service. 115 The terms state and status are used interchangeably in this memo. 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [RFC2119]. 121 2.1 Hierarchical State Management 123 Physical entities exist within a containment hierarchy. Physical 124 containment is defined by the entPhysicalContainedIn 125 object[RFC2737]. This raises some interesting issues not addressed 126 in existing work on state management. 128 There are two types of state for an entity: 130 1) The state of the entity independent of the states of its parents 131 and children in its containment hierarchy. This is often referred to 132 as raw state. 134 2) The state of the entity, as it may be influenced by the state of 135 its parents and children. This is often referred to as computed 136 state. 138 All state objects in this memo are raw state. 140 2.2 Entity Redundancy 142 While this memo is not attempting to address the entire problem 143 space around redundancy, the entStateStandby object provides an 144 important piece of state information for entities, which helps 145 identify which pieces of redundant equipment are currently providing 146 service, and which are waiting in either hot or cold standby mode. 148 2.3 Physical Entity Users 150 There are three ways to define the 'user' of a physical entity 152 1. Direct Containment in physical hierarchy 154 2. Anywhere in physical hierarchy 156 3. As defined by a means outside the scope of this MIB. This could 157 include logical interfaces that could run on a port, software that 158 could run on a module, etc. 160 Administrative, operational, alarm and standby state use all three 161 definitions of 'user'. Usage state only supports the concept of 162 direct containment to simplify implementations of this object. 164 2.4 Physical Class Behaviour 166 This MIB makes no effort to standardize on the behaviours and 167 characteristics of the various physical classes [RFC2737], but 168 rather how this information is reported. In looking at real-world 169 products, items within the same physical class vary substantially. 170 The MIB has therefore provided guidance on how to support objects 171 where a particular instance of a physical class can not support part 172 or all of a particular state. 174 3 Relation to other MIBs 176 3.1 Relationship to the Interfaces MIB 178 The Interfaces MIB [RFC2863] defines the ifAdminStatus object, which 179 has states of up, down and testing and the ifOperStatus object, 180 which has states of up, down, testing, unknown, dormant, notPresent 181 and lowerLayerDown. 183 An ifAdminStatus of 'up' is equivalent to setting the entStateAdmin 184 object to 'unlocked'. An ifAdminStatus of 'down' is equivalent to 185 setting the entStateAdmin object to either 'locked' or 186 'shuttingDown', depending on a systems interpretation of 'down'. 188 An ifOperStatus of 'up' is equivalent to an entStateOper value of 189 'enabled'. An ifOperStatus of 'down' due to operational failure is 190 equivalent to an entStateOper value of 'disabled'. An ifOperStatus 191 of 'down' due to being administratively disabled is equivalent to an 192 entStateAdmin value of 'locked' and an entStateOper value of either 193 'enabled' or 'disabled' depending on whether there are any known 194 issues that would prevent the entity from becoming operational when 195 its entStateAdmin is set to 'unlocked'. An ifOperStatus of 196 'unknown' is equivalent to an entStateOper value of 'unknown'. The 197 ifOperStatus values of 'testing' and 'dormant' are not explicitly 198 supported by this MIB, but the state objects will be able to reflect 199 other aspects of the entities administrative and operational state. 200 The ifOperStatus values of 'notPresent' and 'lowerLayerDown' are in 201 some ways computed states and so are therefore not supported in this 202 MIB. They can though be computed by examining the states of entities 203 within this objects containment hierarchy and other available 204 related states. 206 3.2 Relation to Alarm MIB 208 The entStateAlarm object indicates whether or not there are any 209 active alarms against this entity. If there are active alarms, then 210 the alarmActiveTable in the Alarm MIB [Alarm MIB] should be searched 211 for alarmActiveResourceId that match this entPhysicalIndex. 213 Alternatively, if the alarmActiveTable is queried first and an 214 active alarm with a value of alarmActiveResourceId that matches this 215 entPhysicalIndex is found, then entStateAlarm can be used to quickly 216 determine if there are additional active alarms against this 217 physical entity. 219 3.3 Relation to Bridge MIB 221 For entities of physical type of 'port' that support the 222 dot1dStpPortEnable object in the Bridge MIB [RFC1493], a value of 223 'enabled' is equivalent to setting the entStateAdmin object to 224 'unlocked'. Setting dot1dStpPortEnable to 'disabled' is equivalent 225 to setting the entStateAdmin object to 'locked'. 227 3.4 Relation to the Host Resources MIB 229 The hrDeviceStatus object in the Host Resources MIB [RFC2790] 230 provides an operational state for devices. For entities that 231 logically correspond to the concept of a device, a value of 232 'unknown' for hrDeviceStatus corresponds to an entStateOper value of 233 'unknown'. A value of 'running' corresponds to an entStateOper value 234 of 'enabled'. A value of 'warning' also corresponds to an 235 entStateOper value of 'enabled', but with appropriate bits set in 236 the entStateAlarm object to indicate the alarms corresponding to the 237 unusual error condition detected. A value of 'testing' or 'down' is 238 equivalent to an entStateOper value of 'disabled'. 240 4. Textual Conventions 242 ENTITY-STATE-TC-MIB DEFINITIONS ::= BEGIN 244 IMPORTS 245 MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI 246 TEXTUAL-CONVENTION FROM SNMPv2-TC; 248 entityStateTc MODULE-IDENTITY 249 LAST-UPDATED "200407190000Z" 250 ORGANIZATION "IETF Entity MIB Working Group" 251 CONTACT-INFO 252 "General Discussion: entmib@ietf.org 253 To Subscribe: 254 http://www.ietf.org/mailman/listinfo/entmib 256 http://www.ietf.org/html.charters/entmib-charter.html 258 Sharon Chisholm 259 Nortel Networks 260 PO Box 3511 Station C 261 Ottawa, Ont. K1Y 4H7 262 Canada 263 schishol@nortelnetworks.com 264 David T. Perkins 265 548 Qualbrook Ct 266 San Jose, CA 95110 267 USA 268 Phone: 408 394-8702 269 dperkins@snmpinfo.com" 270 DESCRIPTION 271 "This MIB defines state textual conventions. 273 Copyright (C) The Internet Society 2004. This version 274 of this MIB module is part of RFC yyyy; see the RFC 275 itself for full legal notices." 276 -- RFC Ed.: replace yyyy with actual RFC number & remove 277 -- this note 278 REVISION "200407190000Z" 279 DESCRIPTION 280 "Initial version, published as RFC yyyy." 281 -- RFC-Editor assigns yyyy 282 ::= { mib-2 XX } -- to be assigned by IANA 284 EntityAdminState ::= TEXTUAL-CONVENTION 285 STATUS current 286 DESCRIPTION 287 " Represents the various possible administrative states. 289 A value of 'locked' means the resource is administratively 290 prohibited from use. A value of 'shuttingDown' means that 291 usage is administratively limited to current instances of 292 use. A value of 'unlocked' means the resource is not 293 administratively prohibited from use. A value of 294 'unknown' means that this resource is unable to 295 report administrative state." 296 SYNTAX INTEGER 297 { 298 unknown (1), 299 locked (2), 300 shuttingDown (3), 301 unlocked (4) 302 } 304 EntityOperState ::= TEXTUAL-CONVENTION 305 STATUS current 306 DESCRIPTION 307 " Represents the possible values of operational states. 309 A value of 'disabled' means the resource is totally 310 inoperable. A value of 'enabled' means the resource 311 is partially or fully operable. A value of 'testing' 312 means the resource is currently being tested 313 and cannot therefore report whether it is operational 314 or not. A value of 'unknown' means that this 315 resource is unable to report operational state. " 317 SYNTAX INTEGER 318 { 319 unknown (1), 320 disabled (2), 321 enabled (3), 322 testing (4) 323 } 325 EntityUsageState ::= TEXTUAL-CONVENTION 326 STATUS current 327 DESCRIPTION 328 " Represents the possible values of usage states. 329 A value of 'idle' means the resource is servicing no 330 users. A value of 'active' means the resource is 331 currently in use and it has sufficient spare capacity 332 to provide for additional users. A value of 'busy' 333 means the resource is currently in use, but it 334 currently has no spare capacity to provide for 335 additional users. A value of 'unknown' means 336 that this resource is unable to report usage state." 337 SYNTAX INTEGER 338 { 339 unknown (1), 340 idle (2), 341 active (3), 342 busy (4) 343 } 345 EntityAlarmStatus ::= TEXTUAL-CONVENTION 346 STATUS current 347 DESCRIPTION 348 "Represents the possible values of alarm status. 349 An Alarm [ALARM-MIB] is a persistent indication 350 of an error or warning condition. 352 When no bits of this attribute are set, then no active 353 alarms are known against this entity and it is not under 354 repair. 356 When the 'value of underRepair' is set, the resource is 357 currently being repaired, which, depending on the 358 implementation, may make the other values in this bit 359 string not meaningful. 361 When the value of 'critical' is set, one or more critical 362 alarms are active against the resource. When the value 363 of 'major' is set, one or more major alarms are active 364 against the resource. When the value of 'minor' is set, 365 one or more minor alarms are active against the resource. 366 When the value of 'warning' is set, one or more warning 367 alarms are active against the resource. When the value 368 of 'indeterminate' is set, one or more alarms whose of 369 perceived severity cannot be determined are active 370 against this resource. 372 A value of 'unknown' means that this resource is 373 unable to report alarm state." 374 SYNTAX BITS 375 { 376 unknown (0), 377 underRepair (1), 378 critical(2), 379 major(3), 380 minor(4), 381 -- The following are not defined in X.733 382 warning (5), 383 indeterminate (6) 384 } 386 EntityStandbyStatus ::= TEXTUAL-CONVENTION 387 STATUS current 388 DESCRIPTION 389 " Represents the possible values of standby status. 391 A value of 'hotStandby' means the resource is not 392 providing service, but it will be immediately able to 393 take over the role of the resource to be backed-up, 394 without the need for initialization activity, and will 395 contain the same information as the resource to be 396 backed up. A value of 'coldStandy' means that the 397 resource is to back-up another resource, but will not 398 be immediately able to take over the role of a resource 399 to be backed up, and will require some initialization 400 activity. A value of 'providingService' means the 401 resource is providing service. A value of 402 'unknown' means that this resource is unable to 403 report standby state." 404 SYNTAX INTEGER 405 { 406 unknown (1), 407 hotStandby (2), 408 coldStandby (3), 409 providingService (4) 410 } 412 END 414 5. Definitions 416 ENTITY-STATE-MIB DEFINITIONS ::= BEGIN 418 IMPORTS 419 MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, mib-2 420 FROM SNMPv2-SMI 421 DateAndTime 422 FROM SNMPv2-TC 423 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 424 FROM SNMPv2-CONF 425 entPhysicalIndex 426 FROM ENTITY-MIB 427 EntityAdminState, EntityOperState, EntityUsageState, 428 EntityAlarmStatus, EntityStandbyStatus 429 FROM ENTITY-STATE-TC-MIB; 431 entityStateMIB MODULE-IDENTITY 432 LAST-UPDATED "200407190000Z" 433 ORGANIZATION "IETF Entity MIB Working Group" 434 CONTACT-INFO 435 " General Discussion: entmib@ietf.org 436 To Subscribe: 437 http://www.ietf.org/mailman/listinfo/entmib 439 http://www.ietf.org/html.charters/entmib-charter.html 441 Sharon Chisholm 442 Nortel Networks 443 PO Box 3511 Station C 444 Ottawa, Ont. K1Y 4H7 445 Canada 446 schishol@nortelnetworks.com 448 David T. Perkins 449 548 Qualbrook Ct 450 San Jose, CA 95110 451 USA 452 Phone: 408 394-8702 453 dperkins@snmpinfo.com 454 " 455 DESCRIPTION 456 "This MIB defines a state extension to the Entity MIB. 458 Copyright (C) The Internet Society 2004. This version 459 of this MIB module is part of RFC yyyy; see the RFC 460 itself for full legal notices." 461 -- RFC Ed.: replace yyyy with actual RFC number & remove 462 -- this note 463 REVISION "200407190000Z" 464 DESCRIPTION 465 "Initial version, published as RFC YYYY." 466 -- RFC-Editor assigns yyyy 467 ::= { mib-2 XX } -- to be assigned by IANA 469 -- Entity State Objects 471 entStateObjects OBJECT IDENTIFIER ::= { entityStateMIB 1 } 473 entStateTable OBJECT-TYPE 474 SYNTAX SEQUENCE OF EntStateEntry 475 MAX-ACCESS not-accessible 476 STATUS current 477 DESCRIPTION 478 "A table of information about state/status of entities. 479 This is a sparse augment of the entPhysicalTable. Entries 480 appear in this table for values of 481 entPhysicalClass [RFC2737] that in this implementation 482 are able to report any of the state or status stored in 483 this table. 484 " 485 ::= { entStateObjects 1 } 487 entStateEntry OBJECT-TYPE 488 SYNTAX EntStateEntry 489 MAX-ACCESS not-accessible 490 STATUS current 491 DESCRIPTION 492 "State information about this physical entity." 493 INDEX { entPhysicalIndex } 494 ::= { entStateTable 1 } 496 EntStateEntry ::= SEQUENCE { 497 entStateLastChanged DateAndTime, 498 entStateAdmin EntityAdminState, 499 entStateOper EntityOperState, 500 entStateUsage EntityUsageState, 501 entStateAlarm EntityAlarmStatus, 502 entStateStandby EntityStandbyStatus 503 } 505 entStateLastChanged OBJECT-TYPE 506 SYNTAX DateAndTime 507 MAX-ACCESS read-only 508 STATUS current 509 DESCRIPTION 510 "The value of this object is the date and 511 time when the value of any of entStateAdmin, 512 entStateOper, entStateUsage, entStateAlarm, 513 or entStateStandby changed for this entity. 515 If there has been no change since 516 the last re-initialization of the local system, 517 this object contains the date and time of 518 local system initialization. If there has been 519 no change since the entity was added to the 520 local system, this object contains the date and 521 time of the insertion." 522 ::= { entStateEntry 1 } 524 entStateAdmin OBJECT-TYPE 525 SYNTAX EntityAdminState 526 MAX-ACCESS read-write 527 STATUS current 528 DESCRIPTION 529 "The administrative state for this entity. 531 This object refers to an entities administrative 532 permission to service both other entities within 533 its containment hierarchy as well other users of 534 its services defined by means outside the scope 535 of this MIB. 537 Setting this object to 'notSupported' will result 538 in an 'inconsistentValue' error. For entities that 539 do not support administrative state, all set 540 operations will result in an 'inconsistentValue' 541 error. 543 Some physical entities exhibit only a subset of the 544 remaining administrative state values. Some entities 545 cannot be locked, and hence this object exhibits only 546 the 'unlocked' state. Other entities can not be shutdown 547 gracefully, and hence this object does not exhibit the 548 'shuttingDown' state. A value of 'inconsistentValue' 549 will be returned if attempts are made to set this 550 object to values not supported by its administrative 551 model." 552 ::= { entStateEntry 2 } 554 entStateOper OBJECT-TYPE 555 SYNTAX EntityOperState 556 MAX-ACCESS read-only 557 STATUS current 558 DESCRIPTION 559 "The operational state for this entity. 561 Note that unlike the state model used within the 562 Interfaces MIB [RFC2863], this object does not follow 563 the administrative state. An administrative state of 564 down does not predict an operational state 565 of disabled. 567 A value of 'testing' means that entity currently being 568 tested and cannot there fore report whether it is 569 operational or not. 571 A value of 'disabled' means that an entity is totally 572 inoperable and unable to provide service both to entities 573 within its containment hierarchy, or to other receivers 574 of its service as defined in ways outside the scope of 575 this MIB. 577 A value of 'enabled' means that an entity is fully or 578 partially operable and able to provide service both to 579 entities within its containment hierarchy, or to other 580 receivers of its service as defined in ways outside the 581 scope of this MIB. 583 Note that some implementations may not be able to 584 accurately report entStateOper while the 585 entStateAdmin object has a value other than 'unlocked'. 586 In these cases, this object MUST have a value 587 of 'unknown'." 588 ::= { entStateEntry 3 } 590 entStateUsage OBJECT-TYPE 591 SYNTAX EntityUsageState 592 MAX-ACCESS read-only 593 STATUS current 594 DESCRIPTION 595 "The usage state for this entity. 597 This object refers to an entity's ability to service more 598 physical entities in a containment hierarchy. A value 599 of 'idle' means this entity is able to contain other 600 entities but that no other entity is currently 601 contained within this entity. 603 A value of 'active' means that at least one entity is 604 contained within this entity, but that it could handle 605 more. A value of 'busy' means that the entity is unable 606 to handle any additional entities being contained in it. 608 Some entities will exhibit only a subset of the 609 usage state values. Entities that are unable to ever 610 service any entities within a containment hierarchy will 611 always have a usage state of 'busy'. Some entities will 612 only ever be able to support one entity within its 613 containment hierarchy and will therefore only exhibit 614 values of 'idle' and 'busy'." 615 ::= { entStateEntry 4 } 617 entStateAlarm OBJECT-TYPE 618 SYNTAX EntityAlarmStatus 619 MAX-ACCESS read-only 620 STATUS current 621 DESCRIPTION 622 "The alarm status for this entity. It does not include 623 the alarms raised on child components within its 624 containment hierarchy. 626 A value of 'unknown' means that this entity is 627 unable to report alarm state. Note that this differs 628 from 'indeterminate' which means that that alarm state 629 is supported and there are alarms against this entity, 630 but the severity of some of the alarms is not known 632 If no bits are set, then this entity supports reporting 633 of alarms, but there are currently no active alarms 634 against this entity. 635 " 636 ::= { entStateEntry 5 } 638 entStateStandby OBJECT-TYPE 639 SYNTAX EntityStandbyStatus 640 MAX-ACCESS read-only 641 STATUS current 642 DESCRIPTION 643 "The standby status for this entity. 645 Some entities will exhibit only a subset of the 646 remaining standby state values. If this entity 647 cannot operate in a standby role, the value of this 648 object will always be 'providingService'." 649 ::= { entStateEntry 6 } 651 -- Notifications 652 entStateNotifications OBJECT IDENTIFIER ::= { entityStateMIB 0 } 654 entStateOperEnabled NOTIFICATION-TYPE 655 OBJECTS { entStateAdmin, 656 entStateAlarm 657 } 658 STATUS current 659 DESCRIPTION 660 "An entStateOperEnabled notification signifies that the 661 SNMP entity, acting in an agent role, has detected that 662 the entStateOper object for one of its entities has 663 transitioned into the 'enabled' state. 665 The entity this notification refers can be identified by 666 extracting the entPhysicalIndex from one of the 667 variable bindings. The entStateAdmin and entStateAlarm 668 varbinds may be examined to find out additional 669 information on the administrative state at the time of 670 the operation state change as well to find out whether 671 there were any known alarms against the entity at that 672 time that may explain why the physical entity has become 673 operationally disabled." 674 ::= { entStateNotifications 1 } 676 entStateOperDisabled NOTIFICATION-TYPE 677 OBJECTS { entStateAdmin, 678 entStateAlarm } 679 STATUS current 680 DESCRIPTION 681 "An entStateOperDisabled notification signifies that the 682 SNMP entity, acting in an agent role, has detected that 683 the entStateOper object for one of its entities has 684 transitioned into the 'disabled' state. 686 The entity this notification refers can be identified by 687 extracting the entPhysicalIndex from one of the 688 variable bindings. The entStateAdmin and entStateAlarm 689 varbinds may be examined to find out additional 690 information on the administrative state at the time of 691 the operation state change as well to find out whether 692 there were any known alarms against the entity at that 693 time that may have affect on the physical entity's 694 ability to stay operationally enabled." 695 ::= { entStateNotifications 2 } 697 -- Conformance and Compliance 699 entStateConformance OBJECT IDENTIFIER ::= { entityStateMIB 2 } 701 entStateCompliances OBJECT IDENTIFIER 702 ::= { entStateConformance 1 } 704 entStateCompliance MODULE-COMPLIANCE 705 STATUS current 706 DESCRIPTION 707 "The compliance statement for systems supporting 708 the Entity State MIB." 709 MODULE -- this module 710 MANDATORY-GROUPS { 711 entStateGroup 712 } 713 GROUP entStateNotificationsGroup 714 DESCRIPTION 715 "This group is optional." 716 OBJECT entStateAdmin 717 MIN-ACCESS read-only 718 DESCRIPTION 719 "Write access is not required." 720 ::= { entStateCompliances 1 } 722 entStateGroups OBJECT IDENTIFIER ::= { entStateConformance 2 } 724 entStateGroup OBJECT-GROUP 725 OBJECTS { 726 entStateLastChanged, 727 entStateAdmin, 728 entStateOper, 729 entStateUsage, 730 entStateAlarm, 731 entStateStandby 732 } 733 STATUS current 734 DESCRIPTION 735 "Standard Entity State group." 736 ::= { entStateGroups 1} 738 entStateNotificationsGroup NOTIFICATION-GROUP 739 NOTIFICATIONS { 740 entStateOperEnabled, 741 entStateOperDisabled 742 } 743 STATUS current 744 DESCRIPTION 745 "Standard Entity State Notification group." 746 ::= { entStateGroups 2} 748 END 750 6. Security Considerations 752 There is one management object defined in this MIB that has a 753 MAX-ACCESS clause of read-write. The object may be considered 754 sensitive or vulnerable in some network environments. The support 755 for SET operations in a non-secure environment without proper 756 protection can have a negative effect on network operations. 758 The following object is defined with a MAX-ACCESS clause of 759 read-write: entStateAdmin. 761 SNMP versions prior to SNMPv3 did not include adequate security. 762 Even if the network itself is secure (for example by using IPSec), 763 even then, there is no control as to who on the secure network is 764 allowed to access and GET/SET (read/change/create/delete) the 765 objects in this MIB module. 767 It is RECOMMENDED that implementers consider the security features 768 as provided by the SNMPv3 framework (see [RFC3410], section 8), 769 including full support for the SNMPv3 cryptographic mechanisms (for 770 authentication and privacy). 772 Further, deployment of SNMP versions prior to SNMPv3 is NOT 773 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 774 enable cryptographic security. It is then a customer/operator 775 responsibility to ensure that the SNMP entity giving access to an 776 instance of this MIB module is properly configured to give access to 777 the objects only to those principals (entities) that have legitimate 778 rights to indeed GET or SET (change/create/delete) them. 780 Note that setting the entStateAdmin to 'locked' or 'shuttingDown' 781 can cause disruption of services ranging from those running on a 782 port to those on an entire device, depending on the type of entity. 783 Access to this object should be properly protected. 785 Access to the objects defined in this MIB allows one to figure out 786 what the active and standby resources in a network are. This 787 information can be used to optimize attacks on networks so even 788 read-only access to this MIB should be properly protected. 790 7. Intellectual Property 792 The IETF takes no position regarding the validity or scope of any 793 intellectual property or other rights that might be claimed to 794 pertain to the implementation or use of the technology described in 795 this document or the extent to which any license under such rights 796 might or might not be available; neither does it represent that it 797 has made any effort to identify any such rights. Information on the 798 IETF's procedures with respect to rights in standards-track and 799 standards-related documentation can be found in BCP-11. Copies of 800 claims of rights made available for publication and any assurances 801 of licenses to be made available, or the result of an attempt made 802 to obtain a general license or permission for the use of such 803 proprietary rights by implementors or users of this specification 804 can be obtained from the IETF Secretariat. 806 The IETF invites any interested party to bring to its attention any 807 copyrights, patents or patent applications, or other proprietary 808 rights which may cover technology that may be required to practice 809 this standard. Please address the information to the IETF Executive 810 Director. 812 8. Authors' Addresses 814 Sharon Chisholm 815 Nortel Networks 816 PO Box 3511, Station C 817 Ottawa, Ontario, K1Y 4H7 818 Canada 819 Email: schishol@nortelnetworks.com 821 David T. Perkins 822 548 Qualbrook Ct 823 San Jose, CA 95110 824 USA 825 Phone: 408 394-8702 826 Email: dperkins@snmpinfo.com 828 9. Acknowledgments 830 This document is a product of the Entity MIB Working Group. 832 10. References 834 10.1 Normative 836 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 837 Requirement Levels", BCP 14, RFC 2119, March 1997. 839 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 840 Rose, M. and S. Waldbusser, "Structure of Management 841 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 842 1999. 844 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 845 Rose, M. and S. Waldbusser, "Textual Conventions for 846 SMIv2", STD 58, RFC 2579, April 1999. 848 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 849 Rose, M. and S. Waldbusser, "Conformance Statements for 850 SMIv2", STD 58, RFC 2580, April 1999. 852 [RFC2737] McCloghrie, K., Bierman, A., "Entity MIB (Version 2)", 853 December 1999. 855 10.2 Informative References 857 [RFC1493] Decker, E., Langille, P., Rijsinghani, A., McCloghrie, K., 858 "Definitions of Managed Objects for Bridges", RFC 1493, 859 July 1993 861 [RFC2790] Waldbusser, S., Grillo, P., "Host Resources MIB", 862 RFC 2790, March 2000 864 [RFC2863] McCloghrie, K., Kastenholz, F., "The Interfaces Group 865 MIB using SMIv2", RFC2863, June 2000 867 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 868 "Introduction and Applicability Statements for Internet- 869 Standard Management Framework", RFC 3410, December 2002. 871 [RFC3877] Chisholm, S., Romascanu, D., "Alarm Management Information 872 Base (MIB)", RFC 3877, September 2004 874 [X.731] ITU Recommendation X.731, "Information Technology - Open 875 Systems Interconnection - System Management: State 876 Management Function", 1992 878 11. Full Copyright Statement 880 Copyright (C) The Internet Society (2004). This document is subject 881 to the rights, licenses and restrictions contained in BCP 78, and 882 except as set forth therein, the authors retain all their rights." 884 "This document and the information contained herein are provided on 885 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 886 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 887 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 888 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 889 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 890 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."