idnits 2.17.1 draft-ietf-entmib-state-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 == Line 824 has weird spacing: '...for the purpo...' == 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 (February 2004) is 7368 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 103, but not defined == Missing Reference: 'Alarm MIB' is mentioned on line 177, but not defined ** Obsolete normative reference: RFC 2737 (Obsoleted by RFC 4133) -- Obsolete informational reference (is this intentional?): RFC 1493 (Obsoleted by RFC 4188) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 3 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-03.txt D. Perkins 4 Category: Standards Track SNMPinfo 5 Expiration Date: August 2004 February 2004 7 Entity State MIB 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as 23 "work in progress." 25 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 at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This memo defines a portion of the Management Information Base (MIB) 35 for use with network management protocols in the Internet community. 36 In particular, it describes extensions to the Entity MIB to 37 provide information about the state of physical entities. 39 Table of Contents 41 1. The Internet-Standard Management Framework 42 2. Entity State 43 2.1. Hierarchical State Management 44 2.2. Entity Redundancy 45 3. Relationship to Other MIBs 46 3.1. Relation to Interfaces MIB 47 3.2. Relation to Alarm MIB 48 3.3. Relation to Bridge MIB 49 3.4. Relation to Host Resource MIB 50 4. Definitions 51 5. Security Considerations 52 6. Intellectual Property 53 7. Authors' Addresses 54 8. Acknowledgements 55 9. References 56 10. Full Copyright Statement 57 1. The Internet-Standard Management Framework 59 For a detailed overview of the documents that describe the current 60 Internet-Standard Management Framework, please refer to section 7 of 61 RFC 3410 [RFC3410]. 63 Managed objects are accessed via a virtual information store, termed 64 the Management Information Base or MIB. MIB objects are generally 65 accessed through the Simple Network Management Protocol (SNMP). 66 Objects in the MIB are defined using the mechanisms defined in the 67 Structure of Management Information (SMI). This memo specifies a MIB 68 module that is compliant to the SMIv2, which is described in STD 58, 69 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 70 [RFC2580]. 72 2. Entity State 74 The goal in adding state objects to the Entity MIB [RFC2737] is to 75 define a useful subset of the possible state attributes that could 76 be tracked for a given entity that both fit into the state models 77 such as those used in the Interfaces MIB [RFC2863] as well as 78 leverage existing well-deployed models. The entStateTable contains 79 state objects that are a subset of the popular ISO/OSI states that 80 are also defined in ITU's X.731 specification [X.731]. Objects are 81 defined to capture administrative, operational and usage states. In 82 addition there are further state objects defined to provide 83 additional information for these three basic states. 85 Administrative state indicates permission to use or prohibition 86 against using the entity and is imposed through the management 87 services. 89 Operational state indicates whether or not the entity is physically 90 installed and working. Note that unlike the ifOperStatus [RFC2863], 91 this operational state is independent of the administrative state. 93 Usage state indicates whether or not the entity is in use at a 94 specific instance, and if so, whether or not it currently has spare 95 capacity to serve additional users. In the context of this MIB, the 96 user is equivalent to an entity, so this term is substituted. This 97 state refers to the ability of the entity to service other entities 98 within its containment hierarchy. 100 Alarm state indicates whether or not there are any alarms active 101 against the entity. In addition to those alarm status defined in 102 X.731 [X.731], warning and indeterminate status are also defined to 103 provide a more complete mapping to the Alarm MIB [Alarm-MIB]. 105 Standby state indicates whether the entity is currently running as 106 hot standby, cold standby or is currently providing service. 108 The terms state and status are used interchangeably in this memo. 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 2.1 Hierarchical State Management 116 Physical entities exist within a containment hierarchy. Physical 117 containment is defined by the entPhysicalContainedIn 118 object[RFC2737]. This raises some interesting issues not addressed 119 in existing work on state management [X.731]. 121 There are two types of state for an entity: 123 1) The state of the entity independent of the states of its parents 124 and children in its containment hierarchy. This is often referred to 125 as raw state. 127 2) The state of the entity, as it may be influenced by the state of 128 its parents and children. This is often referred to as computed 129 state. 131 All state objects in this memo are raw state. 133 2.2 Entity Redundancy 135 While this memo is not attempting to address the entire problem 136 space around redundancy, the entStateStandby object provides an 137 important piece of state information for entities, which helps 138 identify which pieces of redundant equipment are currently providing 139 service, and which are waiting in either hot or cold standby mode. 141 3 Relation to other MIBs 143 3.1 Relationship to the Interfaces MIB 145 The Interfaces MIB [RFC2863] defines the ifAdminStatus object, which 146 has states of up, down and testing and the ifOperStatus object, 147 which has states of up, down, testing, unknown, dormant, notPresent 148 and lowerLayerDown. 150 An ifAdminStatus of 'up' is equivalent to setting the entStateAdmin 151 object to 'unlocked'. An ifAdminStatus of 'down' is equivalent to 152 setting the entStateAdmin object to either 'locked' or 153 'shuttingDown', depending on a systems interpretation of 'down'. 155 An ifOperStatus of 'up' is equivalent to an entStateOper value of 156 'enabled'. An ifOperStatus of 'down' due to operational failure is 157 equivalent to an entStateOper value of 'disabled'. An ifOperStatus 158 of 'down' due to being administratively disabled is equivalent to an 159 entStateAdmin value of 'locked' and an entStateOper value of either 160 'enabled' or 'disabled' depending on whether there are any known 161 issues that would prevent the entity from becoming operational when 162 its entStateAdmin is set to 'unlocked'. An ifOperStatus of 163 'unknown' is equivalent to an entStateOper value of 'unavailable'. 164 The ifOperStatus values of 'testing' and 'dormant' are not 165 explicitly supported by this MIB, but the state objects will be able 166 to reflect other aspects of the entities administrative and 167 operational state. The ifOperStatus values of 'notPresent' and 168 'lowerLayerDown' are in some ways computed states and so are 169 therefore not supported in this MIB. They can though be computed by 170 examining the states of entities within this objects containment 171 hierarchy and other available related states. 173 3.2 Relation to Alarm MIB 175 The entStateAlarm object indicates whether or not there are any 176 active alarms against this entity. If there are active alarms, then 177 the alarmActiveTable in the Alarm MIB [Alarm MIB] should be searched 178 for alarmActiveResourceId that match this entPhysicalIndex. 180 Alternatively, if the alarmActiveTable is queried first and an 181 active alarm with a value of alarmActiveResourceId that matches this 182 entPhysicalIndex is found, then entStateAlarm can be used to quickly 183 determine if there are additional active alarms against this 184 physical entity. 186 3.3 Relation to Bridge MIB 188 For entities of physical type of 'port' that support the 189 dot1dStpPortEnable object in the Bridge MIB [RFC1493], a value of 190 'enabled' is equivalent to setting the entStateAdmin object to 191 'unlocked'. Setting dot1dStpPortEnable to 'disabled' is equivalent 192 to setting the entStateAdmin object to 'locked'. 194 3.4 Relation to the Host Resources MIB 196 The hrDeviceStatus object in the Host Resources MIB [RFC2790] 197 provides an operational state for devices. For entities that 198 logically correspond to the concept of a device, a value of 199 'unknown' for hrDeviceStatus corresponds to an entStateOper value of 200 'unavailable'. A value of 'running' corresponds to an entStateOper 201 value of 'enabled'. A value of 'warning' also corresponds to an 202 entStateOper value of 'enabled', but with appropriate bits set in 203 the entStateAlarm object to indicate the alarms corresponding to the 204 unusual error condition detected. A value of 'testing' or 'down' is 205 equivalent to an entStateOper value of 'disabled'. 207 4. Definitions 209 ENTITY-STATE-MIB DEFINITIONS ::= BEGIN 211 IMPORTS 212 MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, mib-2 213 FROM SNMPv2-SMI 214 TEXTUAL-CONVENTION, DateAndTime 215 FROM SNMPv2-TC 216 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 217 FROM SNMPv2-CONF 218 entPhysicalIndex 219 FROM ENTITY-MIB; 221 entityStateMIB MODULE-IDENTITY 222 LAST-UPDATED "200402150000Z" 223 ORGANIZATION "IETF Entity MIB Working Group" 224 CONTACT-INFO 225 " General Discussion: entmib@ietf.org 226 To Subscribe: 227 http://www.ietf.org/mailman/listinfo/entmib 229 http://www.ietf.org/html.charters/entmib-charter.html 231 Sharon Chisholm 232 Nortel Networks 233 PO Box 3511 Station C 234 Ottawa, Ont. K1Y 4H7 235 Canada 236 schishol@nortelnetworks.com 238 David T. Perkins 239 548 Qualbrook Ct 240 San Jose, CA 95110 241 USA 242 Phone: 408 394-8702 243 dperkins@snmpinfo.com 244 " 245 DESCRIPTION 246 "This MIB defines a state extension to the Entity MIB. 248 Copyright (C) The Internet Society 2004. This version 249 of this MIB module is part of RFC yyyy; see the RFC 250 itself for full legal notices." 251 -- RFC Ed.: replace yyyy with actual RFC number & remove 252 -- this note 253 REVISION "200402150000Z" 254 DESCRIPTION 255 "Initial version, published as RFC YYYY." 256 -- RFC-Editor assigns yyyy 257 ::= { mib-2 XX } -- to be assigned by IANA 259 -- Textual conventions 261 AdminState ::= TEXTUAL-CONVENTION 262 STATUS current 263 DESCRIPTION 264 " Represents the various possible administrative states. 266 A value of 'locked' means the resource is administratively 267 prohibited from use. A value of 'shuttingDown' means that 268 usage is administratively limited to current instances of 269 use. A value of 'unlocked' means the resource is not 270 administratively prohibited from use. A value of 271 'unavailable' means that this resource is unable to 272 report administrative state." 273 REFERENCE 274 "ITU Recommendation X.731, 'Information Technology - Open 275 Systems Interconnection - System Management: State 276 Management Function', 1992" 277 SYNTAX INTEGER 278 { 279 unavailable(1), 280 locked(2), 281 shuttingDown(3), 282 unlocked(4) 283 } 285 OperState ::= TEXTUAL-CONVENTION 286 STATUS current 287 DESCRIPTION 288 " Represents the possible values of operational states. 290 A value of 'disabled' means the resource is totally 291 inoperable. A value of 'enabled' means the resource 292 is partially or fully operable. A value of 'testing' 293 means the resource is currently being tested 294 and cannot there fore report whether it is operational 295 or not. A value of 'unavailable' means that this 296 resource is unable to report operational state. " 297 REFERENCE 298 "ITU Recommendation X.731, 'Information Technology - Open 299 Systems Interconnection - System Management: State 300 Management Function', 1992" 301 SYNTAX INTEGER 302 { 303 unavailable (1), 304 disabled(2), 305 enabled(3), 306 testing (4) 307 } 309 UsageState ::= TEXTUAL-CONVENTION 310 STATUS current 311 DESCRIPTION 312 " Represents the possible values of usage states. 313 A value of 'idle' means the resource is servicing no 314 users. A value of 'active' means the resource is 315 currently in use and it has sufficient spare capacity 316 to provide for additional users. A value of 'busy' 317 means the resource is currently in use, but it 318 currently has no spare capacity to provide for 319 additional users. A value of 'unavailable' means 320 that this resource is unable to report usage state." 321 REFERENCE 322 "ITU Recommendation X.731, 'Information Technology - Open 323 Systems Interconnection - System Management: State 324 Management Function', 1992" 325 SYNTAX INTEGER 326 { 327 unavailable (1), 328 idle(2), 329 active(3), 330 busy(4) 331 } 333 AlarmStatus ::= TEXTUAL-CONVENTION 334 STATUS current 335 DESCRIPTION 336 "Represents the possible values of alarm status. 337 An Alarm [ALARM-MIB] is a persistent indication 338 of an error or warning condition. 340 When no bits of this attribute are set, then none 341 of the value of under repair is set, the resource is 342 currently being repaired, which depending on the 343 implementation, may make the other values in this bit 344 string unreliable. 346 When the value of 'critical' is set, one or more critical 347 alarms are active against the resource. When the value 348 of 'major' is set, one or more major alarms are active 349 against the resource. When the value of 'minor' is set, 350 one or more minor alarms are active against the resource. 351 When the value of 'warning' is set, one or more warning 352 alarms are active against the resource. When the value 353 of 'indeterminate' is set, one or more alarms whose of 354 perceived severity cannot be determined are active 355 against this resource. 357 When the value of 'alarmOutstanding' is set, one or more 358 alarms is active against the resource. The fault may 359 or may not be disabling. This bit provides a high-level 360 summary that can be used to determine whether or not 361 to examine the rest of the values. A value of 362 'unavailable' means that this resource is unable to 363 report alarm state." 364 REFERENCE 365 "ITU Recommendation X.731, 'Information Technology - Open 366 Systems Interconnection - System Management: State 367 Management Function', 1992" 368 SYNTAX BITS 369 { 370 unavailable (0), 371 underRepair(1), 372 critical(2), 373 major(3), 374 minor(4), 375 alarmOutstanding(5), 376 -- The following are not defined in X.733 377 warning (6), 378 indeterminate (7) 379 } 381 StandbyStatus ::= TEXTUAL-CONVENTION 382 STATUS current 383 DESCRIPTION 384 " Represents the possible values of standby status. 386 A value of 'hotStandby' means the resource is not 387 providing service, but it will be immediately able to 388 take over the role of the resource to be backed-up, 389 without the need for initialization activity, and will 390 contain the same information as the resource to be 391 backed up. A value of 'coldStandy' means that the 392 resource is to back-up another resource, but will not 393 be immediately able to take over the role of a resource 394 to be backed up, and will require some initialization 395 activity. A value of 'providingService' means the 396 resource is providing service. A value of 397 'unavailable' means that this resource is unable to 398 report standby state." 399 REFERENCE 400 "ITU Recommendation X.731, 'Information Technology - Open 401 Systems Interconnection - System Management: State 402 Management Function', 1992" 403 SYNTAX INTEGER 404 { 405 unavailable (1), 406 hotStandby(2), 407 coldStandby(3), 408 providingService(4) 409 } 411 -- Entity State Objects 413 entStateObjects OBJECT IDENTIFIER ::= { entityStateMIB 1 } 415 entStateTable OBJECT-TYPE 416 SYNTAX SEQUENCE OF EntStateEntry 417 MAX-ACCESS not-accessible 418 STATUS current 419 DESCRIPTION 420 "A table of information about state/status of entities. 421 This is a sparse augment of the entPhysicalTable. Entries 422 appear in this table for values of 423 entPhysicalClass [RFC2737] that in this implementation 424 are able to report any of the state or status stored in 425 this table. 426 " 427 ::= { entStateObjects 1 } 429 entStateEntry OBJECT-TYPE 430 SYNTAX EntStateEntry 431 MAX-ACCESS not-accessible 432 STATUS current 433 DESCRIPTION 434 "State information about this physical entity." 435 INDEX { entPhysicalIndex } 436 ::= { entStateTable 1 } 438 EntStateEntry ::= SEQUENCE { 439 entStateLastChanged DateAndTime, 440 entStateAdmin AdminState, 441 entStateOper OperState, 442 entStateUsage UsageState, 443 entStateAlarm AlarmStatus, 444 entStateStandby StandbyStatus 445 } 447 entStateLastChanged OBJECT-TYPE 448 SYNTAX DateAndTime 449 MAX-ACCESS read-only 450 STATUS current 451 DESCRIPTION 452 "The value of this object is the date and 453 time when the value of any of entStateAdmin, 454 entStateOper, entStateUsage, entStateAlarm, 455 or entStateStandby changed for this entity. 457 If there has been no change since 458 the last re-initialization of the local system, 459 this object contains the date and time of 460 local system initialization. If there has been 461 no change since the entity was added to the 462 local system, this object contains the date and 463 time of the insertion" 464 ::= { entStateEntry 1 } 466 entStateAdmin OBJECT-TYPE 467 SYNTAX AdminState 468 MAX-ACCESS read-write 469 STATUS current 470 DESCRIPTION 471 "The administrative state for this entity. 472 Setting this object to 'notSupported' will result 473 in an 'inconsistentValue' error. For entities that 474 do not support administrative state, all set 475 operations will result in an 'inconsistentValue' 476 error 478 Some physical entities exhibit only a subset of the 479 remaining administrative state values. Some entities 480 cannot be locked, and hence this object exhibits only 481 the 'unlocked' state. Other entities can not be shutdown 482 gracefully, and hence this object does not exhibit the 483 'shuttingDown' state. A value of 'inconsistentValue' 484 will be returned if attempts are made to set this 485 object to values not supported by its administrative 486 model." 487 ::= { entStateEntry 2 } 489 entStateOper OBJECT-TYPE 490 SYNTAX OperState 491 MAX-ACCESS read-only 492 STATUS current 493 DESCRIPTION 494 "The operational state for this entity. 496 Note that unlike the state model used within the 497 Interfaces MIB [RFC2863], this object does not follow 498 the administrative state. An administrative state of 499 down does not predict an operational state 500 of disabled. 502 A value of 'disabled' means that an entity is totally 503 inoperable and unable to provide service both to entities 504 within its containment hierarchy, or to other receivers 505 of its service as defined in ways outside the scope of 506 this MIB. 508 A value of 'enabled' means that an entity is fully or 509 partially operable and able to provide service both to 510 entities within its containment hierarchy, or to other 511 receivers of its service as defined in ways outside the 512 scope of this MIB. 514 Note that some implementations may not be able to 515 accurately report entStateOper while the 516 entStateAdmin object has a value other than 'unlocked'. 517 In these cases, this object MUST have a value 518 of 'unavailable'." 519 ::= { entStateEntry 3 } 521 entStateUsage OBJECT-TYPE 522 SYNTAX UsageState 523 MAX-ACCESS read-only 524 STATUS current 525 DESCRIPTION 526 "The usage state for this entity. 528 Note that in the context of a physical entity, this 529 object refers to an entity's ability to service more 530 physical entities in a containment hierarchy. A value 531 of 'idle' means this entity is able to contain other 532 entities but that no other entity is currently 533 contained within this entity. 535 A value of 'active' means that at least one entity is 536 contained within this entity, but that it could handle 537 more. A value of 'busy' means that the entity is unable 538 to handle any additional entities being contained in it. 540 Some entities will exhibit only a subset of the 541 usage state values. Entities that are unable to ever 542 service any entities within a containment hierarchy will 543 always have a usage state of 'busy'. Some entities will 544 only ever be able to support one entity within its 545 containment hierarchy and will therefore only exhibit 546 values of 'idle' and 'busy'." 547 ::= { entStateEntry 4 } 549 entStateAlarm OBJECT-TYPE 550 SYNTAX AlarmStatus 551 MAX-ACCESS read-only 552 STATUS current 553 DESCRIPTION 554 "The alarm status for this entity. It does not include 555 the alarms raised on child components within its 556 containment hierarchy. 558 Note that this differs from 'indeterminate' which 559 means that that alarm state is supported and there 560 are alarms against this entity, but the severity of 561 some of the alarms is not known. 563 If no bits are set, then this entity supports reporting 564 of alarms, but there are currently no active alarms 565 against this entity. 567 " 568 ::= { entStateEntry 5 } 570 entStateStandby OBJECT-TYPE 571 SYNTAX StandbyStatus 572 MAX-ACCESS read-only 573 STATUS current 574 DESCRIPTION 575 "The standby status for this entity. 577 Some entities will exhibit only a subset of the 578 remaining standby state values. If this entity 579 cannot operate in a standby role, the value of this 580 object will always be 'providingService'." 581 ::= { entStateEntry 6 } 583 -- Notifications 584 entStateNotifications OBJECT IDENTIFIER ::= { entityStateMIB 0 } 586 entStateOperEnabled NOTIFICATION-TYPE 587 OBJECTS { entStateAdmin, 588 entStateAlarm 589 } 590 STATUS current 591 DESCRIPTION 592 "An entStateOperEnabled Notification signifies that the 593 SNMP entity, acting in an agent role, has detected that 594 the entStateOper object for one of its entities has left 595 the 'disabled' state and transitioned into the 'enabled' 596 state. 598 The entity this notification refers can be identified by 599 extracting the entPhysicalIndex from one of the 600 variable bindings. The entStateAdmin and entStateAlarm 601 varbinds may be examined to find out additional 602 information on the administrative state at the time of 603 the operation state change as well to find out whether 604 there were any known alarms against the entity at that 605 time that may explain why the physical entity has become 606 operationally disabled." 607 ::= { entStateNotifications 1 } 609 entStateOperDisabled NOTIFICATION-TYPE 610 OBJECTS { entStateAdmin, 611 entStateAlarm } 612 STATUS current 613 DESCRIPTION 614 "An entStateOperDisabled Notification signifies that the 615 SNMP entity, acting in an agent role, has detected that 616 the entStateOper object for one of its entities has left 617 the 'enabled' state and transitioned into the 618 'disabled' state. 620 The entity this notification refers can be identified by 621 extracting the entPhysicalIndex from one of the 622 variable bindings. The entStateAdmin and entStateAlarm 623 varbinds may be examined to find out additional 624 information on the administrative state at the time of 625 the operation state change as well to find out whether 626 there were any known alarms against the entity at that 627 time that may have affect on the physical entity's 628 ability to stay operationally enabled." 629 ::= { entStateNotifications 2 } 631 -- Conformance and Compliance 633 entStateConformance OBJECT IDENTIFIER ::= { entityStateMIB 3 } 635 entStateCompliances OBJECT IDENTIFIER 636 ::= { entStateConformance 1 } 638 entStateCompliance MODULE-COMPLIANCE 639 STATUS current 640 DESCRIPTION 641 "The compliance statement for systems supporting 642 the Entity State MIB." 643 MODULE -- this module 644 MANDATORY-GROUPS { 645 entStateGroup 646 } 647 GROUP entStateNotificationsGroup 648 DESCRIPTION 649 "This group is optional." 650 OBJECT entStateAdmin 651 MIN-ACCESS read-only 652 DESCRIPTION 653 "Write access is not required." 654 ::= { entStateCompliances 1 } 656 entStateGroups OBJECT IDENTIFIER ::= { entStateConformance 2 } 658 entStateGroup OBJECT-GROUP 659 OBJECTS { 660 entStateLastChanged, 661 entStateAdmin, 662 entStateOper, 663 entStateUsage, 664 entStateAlarm, 665 entStateStandby 666 } 667 STATUS current 668 DESCRIPTION 669 "Standard Entity State group." 670 ::= { entStateGroups 1} 672 entStateNotificationsGroup NOTIFICATION-GROUP 673 NOTIFICATIONS { 674 entStateOperEnabled, 675 entStateOperDisabled 676 } 677 STATUS current 678 DESCRIPTION 679 "Standard Entity State Notification group." 680 ::= { entStateGroups 2} 682 END 684 5. Security Considerations 686 There is one management object defined in this MIB that has a 687 MAX-ACCESS clause of read-write. The object may be considered 688 sensitive or vulnerable in some network environments. The support 689 for SET operations in a non-secure environment without proper 690 protection can have a negative effect on network operations. 692 The following object is defined with a MAX-ACCESS clause of 693 read-write: entStateAdmin. 695 SNMP versions prior to SNMPv3 did not include adequate security. 696 Even if the network itself is secure (for example by using IPSec), 697 even then, there is no control as to who on the secure network is 698 allowed to access and GET/SET (read/change/create/delete) the 699 objects in this MIB module. 701 It is RECOMMENDED that implementers consider the security features 702 as provided by the SNMPv3 framework (see [RFC3410], section 8), 703 including full support for the SNMPv3 cryptographic mechanisms (for 704 authentication and privacy). 706 Further, deployment of SNMP versions prior to SNMPv3 is NOT 707 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 708 enable cryptographic security. It is then a customer/operator 709 responsibility to ensure that the SNMP entity giving access to an 710 instance of this MIB module is properly configured to give access to 711 the objects only to those principals (entities) that have legitimate 712 rights to indeed GET or SET (change/create/delete) them. 714 Note that setting the entStateAdmin to 'locked' or 'shuttingDown' 715 can cause disruption of services ranging from those running on a 716 port to those on an entire device, depending on the type of entity. 717 Access to this object should be properly protected. 719 Access to the objects defined in this MIB allows one to figure out 720 what the active and standby resources in a network are. This 721 information can be used to optimize attacks on networks so even 722 read-only access to this MIB should be properly protected. 724 6. Intellectual Property 726 The IETF takes no position regarding the validity or scope of any 727 intellectual property or other rights that might be claimed to 728 pertain to the implementation or use of the technology described in 729 this document or the extent to which any license under such rights 730 might or might not be available; neither does it represent that it 731 has made any effort to identify any such rights. Information on the 732 IETF's procedures with respect to rights in standards-track and 733 standards-related documentation can be found in BCP-11. Copies of 734 claims of rights made available for publication and any assurances 735 of licenses to be made available, or the result of an attempt made 736 to obtain a general license or permission for the use of such 737 proprietary rights by implementors or users of this specification 738 can be obtained from the IETF Secretariat. 740 The IETF invites any interested party to bring to its attention any 741 copyrights, patents or patent applications, or other proprietary 742 rights which may cover technology that may be required to practice 743 this standard. Please address the information to the IETF Executive 744 Director. 746 7. Authors' Addresses 748 Sharon Chisholm 749 Nortel Networks 750 PO Box 3511, Station C 751 Ottawa, Ontario, K1Y 4H7 752 Canada 753 Email: schishol@nortelnetworks.com 755 David T. Perkins 756 548 Qualbrook Ct 757 San Jose, CA 95110 758 USA 759 Phone: 408 394-8702 760 Email: dperkins@snmpinfo.com 762 8. Acknowledgments 764 This document is a product of the Entity MIB Working Group. 766 9. References 768 9.1 Normative 770 [ALARM-MIB] Chisholm, S., Romascanu, D., "Alarm MIB", 771 draft-ietf-disman-alarm-mib-18.txt, February 2004 773 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 774 Requirement Levels", BCP 14, RFC 2119, March 1997. 776 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 777 Rose, M. and S. Waldbusser, "Structure of Management 778 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 779 1999. 781 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 782 Rose, M. and S. Waldbusser, "Textual Conventions for 783 SMIv2", STD 58, RFC 2579, April 1999. 785 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 786 Rose, M. and S. Waldbusser, "Conformance Statements for 787 SMIv2", STD 58, RFC 2580, April 1999. 789 [RFC2737] McCloghrie, K., Bierman, A., "Entity MIB (Version 2)", 790 December 1999. 792 [X.731] ITU Recommendation X.731, "Information Technology - Open 793 Systems Interconnection - System Management: State 794 Management Function", 1992 796 8.2 Informative References 798 [RFC1493] Decker, E., Langille, P., Rijsinghani, A., McCloghrie, K., 799 "Definitions of Managed Objects for Bridges", RFC 1493, 800 July 1993 802 [RFC2790] Waldbusser, S., Grillo, P., "Host Resources MIB", 803 RFC 2790, March 2000 805 [RFC2863] McCloghrie, K., Kastenholz, F., "The Interfaces Group 806 MIB using SMIv2", RFC2863, June 2000 808 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 809 "Introduction and Applicability Statements for Internet- 810 Standard Management Framework", RFC 3410, December 2002. 812 10. Full Copyright Statement 814 Copyright (C) The Internet Society (2004). All Rights Reserved. 816 This document and translations of it may be copied and furnished to 817 others, and derivative works that comment on or otherwise explain it 818 or assist in its implementation may be prepared, copied, published 819 and distributed, in whole or in part, without restriction of any kind, 820 provided that the above copyright notice and this paragraph are 821 included on all such copies and derivative works. However, this 822 document itself may not be modified in any way, such as by removing 823 the copyright notice or references to the Internet Society or other 824 Internet organizations, except as needed for the purpose of 825 developing Internet standards in which case the procedures for 826 copyrights defined in the Internet Standards process must be followed, 827 or as required to translate it into languages other than English. 829 The limited permissions granted above are perpetual and will not be 830 revoked by the Internet Society or its successors or assigns. 832 This document and the information contained herein is provided on an 833 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 834 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 835 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 836 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 837 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.