idnits 2.17.1 draft-ietf-entmib-state-07.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? == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 6) being 60 lines 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.' ) ** There are 22 instances of lines with control characters in the document. 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 (January 2005) is 7038 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 211, but not defined ** Obsolete normative reference: RFC 2727 (ref. 'RFC2737') (Obsoleted by RFC 3777) -- Obsolete informational reference (is this intentional?): RFC 1493 (Obsoleted by RFC 4188) Summary: 14 errors (**), 0 flaws (~~), 4 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-07.txt D. Perkins 4 Category: Standards Track SNMPinfo 5 Expiration Date: July 2005 January 2005 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. IANA Considerations 62 9. Authors' Addresses 63 10. Acknowledgements 64 11. References 65 12. Full Copyright Statement 66 1. The Internet-Standard Management Framework 68 For a detailed overview of the documents that describe the current 69 Internet-Standard Management Framework, please refer to section 7 of 70 RFC 3410 [RFC3410]. 72 Managed objects are accessed via a virtual information store, termed 73 the Management Information Base or MIB. MIB objects are generally 74 accessed through the Simple Network Management Protocol (SNMP). 75 Objects in the MIB are defined using the mechanisms defined in the 76 Structure of Management Information (SMI). This memo specifies a MIB 77 module that is compliant to the SMIv2, which is described in STD 58, 78 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 79 [RFC2580]. 81 2. Entity State 83 The goal in adding state objects to the Entity MIB [RFC2737] is to 84 define a useful subset of the possible state attributes that could 85 be tracked for a given entity that both fit into the state models 86 such as those used in the Interfaces MIB [RFC2863] as well as 87 leverage existing well-deployed models. The entStateTable contains 88 state objects that are a subset of the popular ISO/OSI states that 89 are also defined in ITU's X.731 specification [X.731]. Objects are 90 defined to capture administrative, operational and usage states. In 91 addition there are further state objects defined to provide 92 additional information for these three basic states. 94 Administrative state indicates permission to use or prohibition 95 against using the entity and is imposed through the management 96 services. 98 Operational state indicates whether or not the entity is physically 99 installed and working. Note that unlike the ifOperStatus [RFC2863], 100 this operational state is independent of the administrative state. 102 Usage state indicates whether or not the entity is in use at a 103 specific instance, and if so, whether or not it currently has spare 104 capacity to serve additional users. In the context of this MIB, the 105 usage state refers to the ability of an entity to service other 106 entities within its containment hierarchy. 108 Alarm state indicates whether or not there are any alarms active 109 against the entity. In addition to those alarm states defined in 110 X.731 [X.731], warning and indeterminate status are also defined to 111 provide a more complete mapping to the Alarm MIB [RFC3877]. 113 Standby state indicates whether the entity is currently running as 114 hot standby, cold standby or is currently providing service. 116 The terms state and status are used interchangeably in this memo. 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119 [RFC2119]. 122 2.1 Hierarchical State Management 124 Physical entities exist within a containment hierarchy. Physical 125 containment is defined by the entPhysicalContainedIn 126 object[RFC2737]. This raises some interesting issues not addressed 127 in existing work on state management. 129 There are two types of state for an entity: 131 1) The state of the entity independent of the states of its parents 132 and children in its containment hierarchy. This is often referred to 133 as raw state. 135 2) The state of the entity, as it may be influenced by the state of 136 its parents and children. This is often referred to as computed 137 state. 139 All state objects in this memo are raw state. 141 2.2 Entity Redundancy 143 While this memo is not attempting to address the entire problem 144 space around redundancy, the entStateStandby object provides an 145 important piece of state information for entities, which helps 146 identify which pieces of redundant equipment are currently providing 147 service, and which are waiting in either hot or cold standby mode. 149 2.3 Physical Entity Users 151 There are three ways to define the 'user' of a physical entity 153 1. Direct Containment in physical hierarchy 155 2. Anywhere in physical hierarchy 157 3. As defined by a means outside the scope of this MIB. This could 158 include logical interfaces that could run on a port, software that 159 could run on a module, etc. 161 Administrative, operational, alarm and standby state use all three 162 definitions of 'user'. Usage state only supports the concept of 163 direct containment to simplify implementations of this object. 165 2.4 Physical Class Behaviour 167 This MIB makes no effort to standardize on the behaviours and 168 characteristics of the various physical classes [RFC2737], but 169 rather how this information is reported. In looking at real-world 170 products, items within the same physical class vary substantially. 171 The MIB has therefore provided guidance on how to support objects 172 where a particular instance of a physical class can not support part 173 or all of a particular state. 175 3 Relation to other MIBs 177 3.1 Relationship to the Interfaces MIB 179 The Interfaces MIB [RFC2863] defines the ifAdminStatus object, which 180 has states of up, down and testing and the ifOperStatus object, 181 which has states of up, down, testing, unknown, dormant, notPresent 182 and lowerLayerDown. 184 An ifAdminStatus of 'up' is equivalent to setting the entStateAdmin 185 object to 'unlocked'. An ifAdminStatus of 'down' is equivalent to 186 setting the entStateAdmin object to either 'locked' or 187 'shuttingDown', depending on a systems interpretation of 'down'. 189 An ifOperStatus of 'up' is equivalent to an entStateOper value of 190 'enabled'. An ifOperStatus of 'down' due to operational failure is 191 equivalent to an entStateOper value of 'disabled'. An ifOperStatus 192 of 'down' due to being administratively disabled is equivalent to an 193 entStateAdmin value of 'locked' and an entStateOper value of either 194 'enabled' or 'disabled' depending on whether there are any known 195 issues that would prevent the entity from becoming operational when 196 its entStateAdmin is set to 'unlocked'. An ifOperStatus of 197 'unknown' is equivalent to an entStateOper value of 'unknown'. The 198 ifOperStatus values of 'testing' and 'dormant' are not explicitly 199 supported by this MIB, but the state objects will be able to reflect 200 other aspects of the entities administrative and operational state. 201 The ifOperStatus values of 'notPresent' and 'lowerLayerDown' are in 202 some ways computed states and so are therefore not supported in this 203 MIB. They can though be computed by examining the states of entities 204 within this objects containment hierarchy and other available 205 related states. 207 3.2 Relation to Alarm MIB 209 The entStateAlarm object indicates whether or not there are any 210 active alarms against this entity. If there are active alarms, then 211 the alarmActiveTable in the Alarm MIB [Alarm MIB] should be searched 212 for rows whose alarmActiveResourceId matches this entPhysicalIndex. 214 Alternatively, if the alarmActiveTable is queried first and an 215 active alarm with a value of alarmActiveResourceId that matches this 216 entPhysicalIndex is found, then entStateAlarm can be used to quickly 217 determine if there are additional active alarms with a different 218 severity against this physical entity. 220 3.3 Relation to Bridge MIB 222 For entities of physical type of 'port' that support the 223 dot1dStpPortEnable object in the Bridge MIB [RFC1493], a value of 224 'enabled' is equivalent to setting the entStateAdmin object to 225 'unlocked'. Setting dot1dStpPortEnable to 'disabled' is equivalent 226 to setting the entStateAdmin object to 'locked'. 228 3.4 Relation to the Host Resources MIB 230 The hrDeviceStatus object in the Host Resources MIB [RFC2790] 231 provides an operational state for devices. For entities that 232 logically correspond to the concept of a device, a value of 233 'unknown' for hrDeviceStatus corresponds to an entStateOper value of 234 'unknown'. A value of 'running' corresponds to an entStateOper value 235 of 'enabled'. A value of 'warning' also corresponds to an 236 entStateOper value of 'enabled', but with appropriate bits set in 237 the entStateAlarm object to indicate the alarms corresponding to the 238 unusual error condition detected. A value of 'testing' or 'down' is 239 equivalent to an entStateOper value of 'disabled'. 241 4. Textual Conventions 243 ENTITY-STATE-TC-MIB DEFINITIONS ::= BEGIN 245 IMPORTS 246 MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI 247 TEXTUAL-CONVENTION FROM SNMPv2-TC; 249 entityStateTc MODULE-IDENTITY 250 LAST-UPDATED "200501230000Z" 251 ORGANIZATION "IETF Entity MIB Working Group" 252 CONTACT-INFO 253 "General Discussion: entmib@ietf.org 254 To Subscribe: 255 http://www.ietf.org/mailman/listinfo/entmib 257 http://www.ietf.org/html.charters/entmib-charter.html 259 Sharon Chisholm 260 Nortel Networks 261 PO Box 3511 Station C 262 Ottawa, Ont. K1Y 4H7 263 Canada 264 schishol@nortelnetworks.com 266 Chisholm & Perkins Standards Track 267 2005 269 David T. Perkins 270 548 Qualbrook Ct 271 San Jose, CA 95110 272 USA 273 Phone: 408 394-8702 274 dperkins@snmpinfo.com" 275 DESCRIPTION 276 "This MIB defines state textual conventions. 278 Copyright (C) The Internet Society 2005. This 279 version 280 of this MIB module is part of RFC yyyy; see the RFC 281 itself for full legal notices." 282 -- RFC Ed.: replace yyyy with actual RFC number & remove 283 -- this note 284 REVISION "200501230000Z" 285 DESCRIPTION 286 "Initial version, published as RFC yyyy." 287 -- RFC-Editor assigns yyyy 288 ::= { mib-2 XX } -- to be assigned by IANA 290 EntityAdminState ::= TEXTUAL-CONVENTION 291 STATUS current 292 DESCRIPTION 293 " Represents the various possible administrative states. 295 A value of 'locked' means the resource is administratively 296 prohibited from use. A value of 'shuttingDown' means that 297 usage is administratively limited to current instances of 298 use. A value of 'unlocked' means the resource is not 299 administratively prohibited from use. A value of 300 'unknown' means that this resource is unable to 301 report administrative state." 302 SYNTAX INTEGER 303 { 304 unknown (1), 305 locked (2), 306 shuttingDown (3), 307 unlocked (4) 308 } 310 EntityOperState ::= TEXTUAL-CONVENTION 311 STATUS current 312 DESCRIPTION 313 " Represents the possible values of operational states. 315 A value of 'disabled' means the resource is totally 316 inoperable. A value of 'enabled' means the resource 317 is partially or fully operable. A value of 'testing' 318 means the resource is currently being tested 319 and cannot therefore report whether it is operational 320 or not. A value of 'unknown' means that this 321 resource is unable to report operational state. " 323 SYNTAX INTEGER 324 { 325 unknown (1), 326 disabled (2), 327 enabled (3), 328 testing (4) 329 } 331 EntityUsageState ::= TEXTUAL-CONVENTION 332 STATUS current 333 DESCRIPTION 334 " Represents the possible values of usage states. 335 A value of 'idle' means the resource is servicing no 336 users. A value of 'active' means the resource is 337 currently in use and it has sufficient spare capacity 338 to provide for additional users. A value of 'busy' 339 means the resource is currently in use, but it 340 currently has no spare capacity to provide for 341 additional users. A value of 'unknown' means 342 that this resource is unable to report usage state." 343 SYNTAX INTEGER 344 { 345 unknown (1), 346 idle (2), 347 active (3), 348 busy (4) 349 } 351 EntityAlarmStatus ::= TEXTUAL-CONVENTION 352 STATUS current 353 DESCRIPTION 354 "Represents the possible values of alarm status. 355 An Alarm [RFC3877] is a persistent indication 356 of an error or warning condition. 358 When no bits of this attribute are set, then no active 359 alarms are known against this entity and it is not under 360 repair. 362 When the 'value of underRepair' is set, the resource is 363 currently being repaired, which, depending on the 364 implementation, may make the other values in this bit 365 string not meaningful. 367 When the value of 'critical' is set, one or more critical 368 alarms are active against the resource. When the value 369 of 'major' is set, one or more major alarms are active 370 against the resource. When the value of 'minor' is set, 371 one or more minor alarms are active against the resource. 372 When the value of 'warning' is set, one or more warning 373 alarms are active against the resource. When the value 374 of 'indeterminate' is set, one or more alarms whose of 375 perceived severity cannot be determined are active 376 against this resource. 378 A value of 'unknown' means that this resource is 379 unable to report alarm state." 380 SYNTAX BITS 381 { 382 unknown (0), 383 underRepair (1), 384 critical(2), 385 major(3), 386 minor(4), 387 -- The following are not defined in X.733 388 warning (5), 389 indeterminate (6) 390 } 392 EntityStandbyStatus ::= TEXTUAL-CONVENTION 393 STATUS current 394 DESCRIPTION 395 " Represents the possible values of standby status. 397 A value of 'hotStandby' means the resource is not 398 providing service, but it will be immediately able to 399 take over the role of the resource to be backed-up, 400 without the need for initialization activity, and will 401 contain the same information as the resource to be 402 backed up. A value of 'coldStandy' means that the 403 resource is to back-up another resource, but will not 404 be immediately able to take over the role of a resource 405 to be backed up, and will require some initialization 406 activity. A value of 'providingService' means the 407 resource is providing service. A value of 408 'unknown' means that this resource is unable to 409 report standby state." 410 SYNTAX INTEGER 411 { 412 unknown (1), 413 hotStandby (2), 414 coldStandby (3), 415 providingService (4) 416 } 418 END 420 5. Definitions 422 ENTITY-STATE-MIB DEFINITIONS ::= BEGIN 424 IMPORTS 425 MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, mib-2 426 FROM SNMPv2-SMI 427 DateAndTime 428 FROM SNMPv2-TC 429 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 430 FROM SNMPv2-CONF 431 entPhysicalIndex 432 FROM ENTITY-MIB 433 EntityAdminState, EntityOperState, EntityUsageState, 434 EntityAlarmStatus, EntityStandbyStatus 435 FROM ENTITY-STATE-TC-MIB; 437 entityStateMIB MODULE-IDENTITY 438 LAST-UPDATED "200501230000Z" 439 ORGANIZATION "IETF Entity MIB Working Group" 440 CONTACT-INFO 441 " General Discussion: entmib@ietf.org 442 To Subscribe: 443 http://www.ietf.org/mailman/listinfo/entmib 445 http://www.ietf.org/html.charters/entmib-charter.html 447 Sharon Chisholm 448 Nortel Networks 449 PO Box 3511 Station C 450 Ottawa, Ont. K1Y 4H7 451 Canada 452 schishol@nortelnetworks.com 454 David T. Perkins 455 548 Qualbrook Ct 456 San Jose, CA 95110 457 USA 458 Phone: 408 394-8702 459 dperkins@snmpinfo.com 460 " 461 DESCRIPTION 462 "This MIB defines a state extension to the Entity MIB. 464 Copyright (C) The Internet Society 2005. This version 465 of this MIB module is part of RFC yyyy; see the RFC 466 itself for full legal notices." 467 -- RFC Ed.: replace yyyy with actual RFC number & remove 468 -- this note 469 REVISION "200501230000Z" 470 DESCRIPTION 471 "Initial version, published as RFC YYYY." 472 -- RFC-Editor assigns yyyy 473 ::= { mib-2 XX } -- to be assigned by IANA 475 -- Entity State Objects 477 entStateObjects OBJECT IDENTIFIER ::= { entityStateMIB 1 } 479 entStateTable OBJECT-TYPE 480 SYNTAX SEQUENCE OF EntStateEntry 481 MAX-ACCESS not-accessible 482 STATUS current 483 DESCRIPTION 484 "A table of information about state/status of entities. 485 This is a sparse augment of the entPhysicalTable. Entries 486 appear in this table for values of 487 entPhysicalClass [RFC2737] that in this implementation 488 are able to report any of the state or status stored in 489 this table. 490 " 491 ::= { entStateObjects 1 } 493 entStateEntry OBJECT-TYPE 494 SYNTAX EntStateEntry 495 MAX-ACCESS not-accessible 496 STATUS current 497 DESCRIPTION 498 "State information about this physical entity." 499 INDEX { entPhysicalIndex } 500 ::= { entStateTable 1 } 502 EntStateEntry ::= SEQUENCE { 503 entStateLastChanged DateAndTime, 504 entStateAdmin EntityAdminState, 505 entStateOper EntityOperState, 506 entStateUsage EntityUsageState, 507 entStateAlarm EntityAlarmStatus, 508 entStateStandby EntityStandbyStatus 509 } 511 entStateLastChanged OBJECT-TYPE 512 SYNTAX DateAndTime 513 MAX-ACCESS read-only 514 STATUS current 515 DESCRIPTION 516 "The value of this object is the date and 517 time when the value of any of entStateAdmin, 518 entStateOper, entStateUsage, entStateAlarm, 519 or entStateStandby changed for this entity. 521 If there has been no change since 522 the last re-initialization of the local system, 523 this object contains the date and time of 524 local system initialization. If there has been 525 no change since the entity was added to the 526 local system, this object contains the date and 527 time of the insertion." 528 ::= { entStateEntry 1 } 530 entStateAdmin OBJECT-TYPE 531 SYNTAX EntityAdminState 532 MAX-ACCESS read-write 533 STATUS current 534 DESCRIPTION 535 "The administrative state for this entity. 537 This object refers to an entities administrative 538 permission to service both other entities within 539 its containment hierarchy as well other users of 540 its services defined by means outside the scope 541 of this MIB. 543 Setting this object to 'notSupported' will result 544 in an 'inconsistentValue' error. For entities that 545 do not support administrative state, all set 546 operations will result in an 'inconsistentValue' 547 error. 549 Some physical entities exhibit only a subset of the 550 remaining administrative state values. Some entities 551 cannot be locked, and hence this object exhibits only 552 the 'unlocked' state. Other entities can not be shutdown 553 gracefully, and hence this object does not exhibit the 554 'shuttingDown' state. A value of 'inconsistentValue' 555 will be returned if attempts are made to set this 556 object to values not supported by its administrative 557 model." 558 ::= { entStateEntry 2 } 560 entStateOper OBJECT-TYPE 561 SYNTAX EntityOperState 562 MAX-ACCESS read-only 563 STATUS current 564 DESCRIPTION 565 "The operational state for this entity. 567 Note that unlike the state model used within the 568 Interfaces MIB [RFC2863], this object does not follow 569 the administrative state. An administrative state of 570 down does not predict an operational state 571 of disabled. 573 A value of 'testing' means that entity currently being 574 tested and cannot there fore report whether it is 575 operational or not. 577 A value of 'disabled' means that an entity is totally 578 inoperable and unable to provide service both to entities 579 within its containment hierarchy, or to other receivers 580 of its service as defined in ways outside the scope of 581 this MIB. 583 A value of 'enabled' means that an entity is fully or 584 partially operable and able to provide service both to 585 entities within its containment hierarchy, or to other 586 receivers of its service as defined in ways outside the 587 scope of this MIB. 589 Note that some implementations may not be able to 590 accurately report entStateOper while the 591 entStateAdmin object has a value other than 'unlocked'. 592 In these cases, this object MUST have a value 593 of 'unknown'." 594 ::= { entStateEntry 3 } 596 entStateUsage OBJECT-TYPE 597 SYNTAX EntityUsageState 598 MAX-ACCESS read-only 599 STATUS current 600 DESCRIPTION 601 "The usage state for this entity. 603 This object refers to an entity's ability to service more 604 physical entities in a containment hierarchy. A value 605 of 'idle' means this entity is able to contain other 606 entities but that no other entity is currently 607 contained within this entity. 609 A value of 'active' means that at least one entity is 610 contained within this entity, but that it could handle 611 more. A value of 'busy' means that the entity is unable 612 to handle any additional entities being contained in it. 614 Some entities will exhibit only a subset of the 615 usage state values. Entities that are unable to ever 616 service any entities within a containment hierarchy will 617 always have a usage state of 'busy'. Some entities will 618 only ever be able to support one entity within its 619 containment hierarchy and will therefore only exhibit 620 values of 'idle' and 'busy'." 621 ::= { entStateEntry 4 } 623 entStateAlarm OBJECT-TYPE 624 SYNTAX EntityAlarmStatus 625 MAX-ACCESS read-only 626 STATUS current 627 DESCRIPTION 628 "The alarm status for this entity. It does not include 629 the alarms raised on child components within its 630 containment hierarchy. 632 A value of 'unknown' means that this entity is 633 unable to report alarm state. Note that this differs 634 from 'indeterminate' which means that that alarm state 635 is supported and there are alarms against this entity, 636 but the severity of some of the alarms is not known 638 If no bits are set, then this entity supports reporting 639 of alarms, but there are currently no active alarms 640 against this entity. 641 " 642 ::= { entStateEntry 5 } 644 entStateStandby OBJECT-TYPE 645 SYNTAX EntityStandbyStatus 646 MAX-ACCESS read-only 647 STATUS current 648 DESCRIPTION 649 "The standby status for this entity. 651 Some entities will exhibit only a subset of the 652 remaining standby state values. If this entity 653 cannot operate in a standby role, the value of this 654 object will always be 'providingService'." 655 ::= { entStateEntry 6 } 657 -- Notifications 658 entStateNotifications OBJECT IDENTIFIER ::= { entityStateMIB 0 } 660 entStateOperEnabled NOTIFICATION-TYPE 661 OBJECTS { entStateAdmin, 662 entStateAlarm 663 } 664 STATUS current 665 DESCRIPTION 666 "An entStateOperEnabled notification signifies that the 667 SNMP entity, acting in an agent role, has detected that 668 the entStateOper object for one of its entities has 669 transitioned into the 'enabled' state. 671 The entity this notification refers can be identified by 672 extracting the entPhysicalIndex from one of the 673 variable bindings. The entStateAdmin and entStateAlarm 674 varbinds may be examined to find out additional 675 information on the administrative state at the time of 676 the operation state change as well to find out whether 677 there were any known alarms against the entity at that 678 time that may explain why the physical entity has become 679 operationally disabled." 680 ::= { entStateNotifications 1 } 682 entStateOperDisabled NOTIFICATION-TYPE 683 OBJECTS { entStateAdmin, 684 entStateAlarm } 685 STATUS current 686 DESCRIPTION 687 "An entStateOperDisabled notification signifies that the 688 SNMP entity, acting in an agent role, has detected that 689 the entStateOper object for one of its entities has 690 transitioned into the 'disabled' state. 692 The entity this notification refers can be identified by 693 extracting the entPhysicalIndex from one of the 694 variable bindings. The entStateAdmin and entStateAlarm 695 varbinds may be examined to find out additional 696 information on the administrative state at the time of 697 the operation state change as well to find out whether 698 there were any known alarms against the entity at that 699 time that may have affect on the physical entity's 700 ability to stay operationally enabled." 701 ::= { entStateNotifications 2 } 703 -- Conformance and Compliance 705 entStateConformance OBJECT IDENTIFIER ::= { entityStateMIB 2 } 707 entStateCompliances OBJECT IDENTIFIER 708 ::= { entStateConformance 1 } 710 entStateCompliance MODULE-COMPLIANCE 711 STATUS current 712 DESCRIPTION 713 "The compliance statement for systems supporting 714 the Entity State MIB." 715 MODULE -- this module 716 MANDATORY-GROUPS { 717 entStateGroup 718 } 719 GROUP entStateNotificationsGroup 720 DESCRIPTION 721 "This group is optional." 722 OBJECT entStateAdmin 723 MIN-ACCESS read-only 724 DESCRIPTION 725 "Write access is not required." 726 ::= { entStateCompliances 1 } 728 entStateGroups OBJECT IDENTIFIER ::= { entStateConformance 2 } 730 entStateGroup OBJECT-GROUP 731 OBJECTS { 732 entStateLastChanged, 733 entStateAdmin, 734 entStateOper, 735 entStateUsage, 736 entStateAlarm, 737 entStateStandby 738 } 739 STATUS current 740 DESCRIPTION 741 "Standard Entity State group." 742 ::= { entStateGroups 1} 744 entStateNotificationsGroup NOTIFICATION-GROUP 745 NOTIFICATIONS { 746 entStateOperEnabled, 747 entStateOperDisabled 748 } 749 STATUS current 750 DESCRIPTION 751 "Standard Entity State Notification group." 752 ::= { entStateGroups 2} 754 END 756 6. Security Considerations 758 There is one management object - entStateAdmin - defined in this MIB 759 that has a MAX-ACCESS clause of read-write. The object may be 760 considered sensitive or vulnerable in some network environments. 761 The support for SET operations in a non-secure environment without 762 proper protection can have a negative effect on network operations. 764 Note that setting the entStateAdmin to 'locked' or 'shuttingDown' 765 can cause disruption of services ranging from those running on a 766 port to those on an entire device, depending on the type of entity. 767 Access to this object should be properly protected. 769 Access to the objects defined in this MIB allows one to figure out 770 what the active and standby resources in a network are. This 771 information can be used to optimize attacks on networks so even 772 read-only access to this MIB should be properly protected. 774 SNMP versions prior to SNMPv3 did not include adequate security. 775 Even if the network itself is secure (for example by using IPSec), 776 even then, there is no control as to who on the secure network is 777 allowed to access and GET/SET (read/change/create/delete) the 778 objects in this MIB module. 780 It is RECOMMENDED that implementers consider the security features 781 as provided by the SNMPv3 framework (see [RFC3410], section 8), 782 including full support for the SNMPv3 cryptographic mechanisms (for 783 authentication and privacy). 785 Further, deployment of SNMP versions prior to SNMPv3 is NOT 786 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 787 enable cryptographic security. It is then a customer/operator 788 responsibility to ensure that the SNMP entity giving access to an 789 instance of this MIB module is properly configured to give access to 790 the objects only to those principals (entities) that have legitimate 791 rights to indeed GET or SET (change/create/delete) them. 793 7. Intellectual Property 795 The IETF takes no position regarding the validity or scope of any 796 intellectual property or other rights that might be claimed to 797 pertain to the implementation or use of the technology described in 798 this document or the extent to which any license under such rights 799 might or might not be available; neither does it represent that it 800 has made any effort to identify any such rights. Information on the 801 IETF's procedures with respect to rights in standards-track and 802 standards-related documentation can be found in BCP-11. Copies of 803 claims of rights made available for publication and any assurances 804 of licenses to be made available, or the result of an attempt made 805 to obtain a general license or permission for the use of such 806 proprietary rights by implementors or users of this specification 807 can be obtained from the IETF Secretariat. 809 The IETF invites any interested party to bring to its attention any 810 copyrights, patents or patent applications, or other proprietary 811 rights which may cover technology that may be required to practice 812 this standard. Please address the information to the IETF Executive 813 Director. 815 8. IANA Considerations 817 This draft requires no action on the part of IANA other than the 818 allocation of the MIB OID from which to root this MIB. This section 819 should be removed prior to publication as and RFC. 821 9. Authors' Addresses 823 Sharon Chisholm 824 Nortel Networks 825 PO Box 3511, Station C 826 Ottawa, Ontario, K1Y 4H7 827 Canada 828 Email: schishol@nortelnetworks.com 830 David T. Perkins 831 548 Qualbrook Ct 832 San Jose, CA 95110 833 USA 834 Phone: 408 394-8702 835 Email: dperkins@snmpinfo.com 837 10. Acknowledgments 839 This document is a product of the Entity MIB Working Group. 841 11. References 843 11.1 Normative 845 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 846 Requirement Levels", BCP 14, RFC 2119, March 1997. 848 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 849 Rose, M. and S. Waldbusser, "Structure of Management 850 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 851 1999. 853 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 854 Rose, M. and S. Waldbusser, "Textual Conventions for 855 SMIv2", STD 58, RFC 2579, April 1999. 857 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 858 Rose, M. and S. Waldbusser, "Conformance Statements for 859 SMIv2", STD 58, RFC 2580, April 1999. 861 [RFC2737] McCloghrie, K., Bierman, A., "Entity MIB (Version 2)", 862 December 1999. [Note to RFC Editor: If later version of 863 RFC2727 is available at time of publication, please update this 864 references] 866 11.2 Informative References 868 [RFC1493] Decker, E., Langille, P., Rijsinghani, A., McCloghrie, K., 869 "Definitions of Managed Objects for Bridges", RFC 1493, 870 July 1993 872 [RFC2790] Waldbusser, S., Grillo, P., "Host Resources MIB", 873 RFC 2790, March 2000 875 [RFC2863] McCloghrie, K., Kastenholz, F., "The Interfaces Group 876 MIB using SMIv2", RFC2863, June 2000 878 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 879 "Introduction and Applicability Statements for Internet- 880 Standard Management Framework", RFC 3410, December 2002. 882 [RFC3877] Chisholm, S., Romascanu, D., "Alarm Management Information 883 Base (MIB)", RFC 3877, September 2004 885 [X.731] ITU Recommendation X.731, "Information Technology - Open 886 Systems Interconnection - System Management: State 887 Management Function", 1992 889 12. Full Copyright Statement 891 Copyright (C) The Internet Society (2005). This document is subject 892 to the rights, licenses and restrictions contained in BCP 78, and 893 except as set forth therein, the authors retain all their rights." 895 "This document and the information contained herein are provided on 896 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 897 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 898 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 899 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 900 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 901 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."