idnits 2.17.1 draft-ietf-entmib-state-00.txt: -(52): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(56): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(108): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(156): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(212): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(266): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(318): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(372): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(426): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(479): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(530): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(581): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(634): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(688): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(742): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(792): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(839): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(894): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(902): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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? == There are 24 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 18 longer pages, the longest (page 5) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 210 has weird spacing: '...receive packe...' == Line 886 has weird spacing: '...for the purpo...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 2003) is 7770 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: 'RFC2863' is mentioned on line 198, but not defined == Unused Reference: 'ALARM-MIB' is defined on line 799, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 828, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-disman-alarm-mib-09 ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Downref: Normative reference to an Informational RFC: RFC 1215 ** Downref: Normative reference to an Historic RFC: RFC 1901 ** Obsolete normative reference: RFC 1905 (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 1906 (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2570 (Obsoleted by RFC 3410) ** Obsolete normative reference: RFC 2571 (Obsoleted by RFC 3411) ** Obsolete normative reference: RFC 2572 (Obsoleted by RFC 3412) ** Obsolete normative reference: RFC 2573 (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2574 (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 2575 (Obsoleted by RFC 3415) Summary: 17 errors (**), 0 flaws (~~), 10 warnings (==), 2 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-00.txt D. Perkins 4 Category: Standards Track SNMPinfo & 5 RiverStone Networks 6 Expiration Date: July 2003 January 2003 8 Entity State MIB 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as 24 "work in progress." 26 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This memo defines a portion of the Management Information Base (MIB) 36 for use with network management protocols in the Internet community. 37 In particular, it describes extensions to the entity MIB to 38 provide information about the state of the entity. 40 Table of Contents 42 1. The SNMP Management Framework 43 2. Entity State 44 2.1. State Relationships 45 2.2. Physical Classes and State 46 2.3. Relation to Alarm MIB 47 3. Definitions 48 4. Security Considerations 49 5. Authors' Addresses 50 6. Acknowledgements 52 Chisholm & Perkins Standards Track [Page 1]� 53 7. References 54 8. Full Copyright Statement 56 Chisholm & Perkins Standards Track [Page 2]� 57 1. The SNMP Management Framework 59 The SNMP Management Framework presently consists of five major 60 components: 62 o An overall architecture, described in RFC 2571 [RFC2571]. 64 o Mechanisms for describing and naming objects and events for the 65 purpose of management. The first version of this Structure of 66 Management Information (SMI) is called SMIv1 and described in 67 STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 68 1215 [RFC1215]. The second version, called SMIv2, is described 69 in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and 70 STD 58, RFC 2580 [RFC2580]. 72 o Message protocols for transferring management information. The 73 first version of the SNMP message protocol is called SNMPv1 and 74 described in STD 15, RFC 1157 [RFC1157]. A second version of 75 the SNMP message protocol, which is not an Internet standards 76 track protocol, is called SNMPv2c and described in RFC 1901 77 [RFC1901] and RFC 1906 [RFC1906]. The third version of the 78 message protocol is called SNMPv3 and described in RFC 1906 79 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. 81 o Protocol operations for accessing management information. The 82 first set of protocol operations and associated PDU formats is 83 described in STD 15, RFC 1157 [RFC1157]. A second set of 84 protocol operations and associated PDU formats is described in 85 RFC 1905 [RFC1905]. 87 o A set of fundamental applications described in RFC 2573 88 [RFC2573] and the view-based access control mechanism described 89 in RFC 2575 [RFC2575]. 91 A more detailed introduction to the current SNMP Management Framework 92 can be found in RFC 2570 [RFC2570]. 94 Managed objects are accessed via a virtual information store, termed 95 the Management Information Base or MIB. Objects in the MIB are 96 defined using the mechanisms defined in the SMI. 98 This memo specifies a MIB module that is compliant to the SMIv2. A 99 MIB conforming to the SMIv1 can be produced through the appropriate 100 translations. The resulting translated MIB must be semantically 101 equivalent, except where objects or events are omitted because no 102 translation is possible (use of Counter64). Some machine readable 103 information in SMIv2 will be converted into textual descriptions in 104 SMIv1 during the translation process. However, this loss of machine 105 readable information is not considered to change the semantics of the 106 MIB. 108 Chisholm & Perkins Standards Track [Page 3]� 109 2. Entity State 111 The goal in adding state objects to the Entity MIB was to define a 112 useful subset of the possible state attributes that could be tracked 113 for a given entity that both fit into the existing IETF model, as 114 well as leveraged existing well-deployed models. The entStateTable 115 contains state objects that are a subset of the popular ISO/OSI 116 states that are also defined in ITU's X.731 specification. Objects 117 are defined to capture administrative, operational and usage states. 118 In addition there are further state objects defined to provide 119 additional information for these three basic states. 121 Administrative state indicates permission to use or prohibition 122 against using the entity and is imposed through the management 123 services. The administrative state defined for an entity is 124 independent of administrative states in its containment hierarchy. 125 This means that administratively locking an entity does not 126 automatically lock its children in the containment hierarchy. 128 Operational state indicates whether or not the entity is physically 129 installed and working. The operational state defined for an entity 130 is indirectly dependent on the operational state of the entities in 131 which it is contained. If its parent entities in its containment 132 hierarchy are disabled, and therefore totally inoperable, then it is 133 unlikely that the given entity will be operable. 135 Usage state indicates whether or not the entity is in use at a 136 specific instance, and if so, whether or not it currently has spare 137 capacity to serve additional users. 139 The terms state and status are used interchangeably in this memo. 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC 2119. 145 2.1 State Relationships 147 The following section outlines all of the combinations of the three 148 basic states -administrative, operational and usage - and briefly 149 describes what each of these combinations of states means. It also 150 compare this combination of states to that of the ifAdminStatus and 151 ifOperStatus objects of the Interfaces Group MIB [RFC2863] to both 152 provide insight to those familiar with these status objects as well 153 as to clarify the relationship between entities and interfaces, as 154 indicated by entAliasMappingIdentifier. 156 Chisholm & Perkins Standards Track [Page 4]� 157 2.1.1 Admin State Locked, Operational State Disabled and Usage State Idle 159 The entity is totally inoperable, it is not servicing any users and 160 it is also administratively prohibited from use. To make it 161 available for use, both management permission and some corrective 162 action are necessary. This is similar to an ifAdminStatus of down 163 and ifOperStatus of down. 165 2.1.2 Admin State Locked, Operational State Enabled and Usage State Idle 167 The entity is partially or fully operable, it is not servicing any 168 users but is administratively prohibited from use. To make it 169 available for use, only management permission is required. This is 170 similar to an ifAdminStatus of down and ifOperStatus of down.� 172 2.1.3 Admin State Shutting Down, Operational State Enabled and Usage State 173 Active 175 The entity is partially or fully operable and in use, but usage is 176 administratively limited to current instances of use. For an 177 additional user to gain access, management permission is required. 178 Otherwise, when all current users have terminated their use of the 179 resource, the managed object will automatically transit to the 180 locked, enabled, and idle state. This is similar to the situation 181 described in [RFC2863] where ifAdminStatus transitions to down, but 182 the ifOperStatus's transition does not occur immediately, but rather 183 after a small time lag to complete certain operations before going 184 "down".� 186 2.1.4 Admin State Shutting Down, Operational State Enabled and Usage State 187 Busy 189 The entity is partially or fully operable and in use, but usage is 190 administratively limited to current instances of use. In addition, 191 it has no spare capacity to provide for additional users. For an 192 additional user to gain access, besides waiting for an existing user 193 to terminate, management permission is also required. Otherwise, 194 when all current users have terminated their use of the resource, 196 the managed object will automatically transit to the locked, 197 enabled, idle state. This is similar to the situation described in 198 [RFC2863] where ifAdminStatus transitions to down, but the 199 ifOperStatus's transition does not occur immediately, but rather 200 after a small time lag to complete certain operations before going 201 "down". 203 2.1.5 Admin State Unlocked, Operational State Enabled and Usage State Idle 205 The entity is partially or fully operable, it is not actually in use 206 and is not administratively prohibited from use. This is similar to 207 an ifAdminStatus of up and ifOperStatus of up if the interface is 208 able to pass packets. If the interface is found to be operable, but 209 the interface is waiting for other, external, events to occur 210 before it can transmit or receive packets, then this is similar to 212 Chisholm & Perkins Standards Track [Page 5]� 213 an ifAdminStatus of up and a ifOperStatus of dormant. 215 2.1.6 Admin State Unlocked, Operational State Enabled and Usage State Active 217 The entity is partially or fully operable, it is currently in use 218 and is not 220 administratively prohibited from use. It has sufficient spare 221 capacity to provide for additional users. This is similar to an 222 ifAdminStatus of up and ifOperStatus of up.� 224 2.1.7 Admin State Unlocked, Operational State Enabled and Usage State Busy 226 The entity is partially or fully operable, it is currently in use 227 and it is not administratively prohibited from use. Currently it has 228 no spare capacity to provide for additional users. For an additional 229 user to gain access, it is necessary to wait for an existing user to 230 terminate or for some capacity increase to occur. This is similar 231 to an ifAdminStatus of up and ifOperStatus of up. 233 2.1.8 Admin State Unlocked, Operational State Disabled and Usage State Idle 235 The entity is totally inoperable, it is servicing no users but it is 236 not administratively prohibited from use. To make it available for 237 use, some corrective action is required. This is similar to an 238 ifAdminStatus of up and ifOperStatus of down. If the cause of the 239 interface being down is because of a lower layer being down, then 240 this is similar to an ifAdminStatus of up and an ifOperStatus of 241 lowerLayerDown. 243 2.2 Physical Classes and States 245 2.2.1 Chassis 247 A value of unlocked for entStateAdmin means that this system is on. 248 A value of shuttingDown for entStateAdmin means that this system is 249 in the process of shutting down. A value of enabled for entStateOper 250 indicates that basic functions of this system are functioning. A 251 value of disabled for entStateOper indicates a problem with basic 252 functions on the system. 254 A value of hotStandby for enStateStandby indicates that the entire 255 system contained within this chassis is running as a hot standby for 256 another complete system, possibly contained within the same stack. A 257 value of coldStandby for enStateStandby indicates that the entire 258 system contained within this chassis is running as a cold standby 259 for another complete system, possibly contained within the same 260 stack. A value of providingService for enStateStandby indicates that 261 the entire system contained within this chassis is currently 262 providing service. 264 If this chassis is not contained in within a stack, the alarm counts 266 Chisholm & Perkins Standards Track [Page 6]� 267 indicated by entStateAlarm will be those alarms that are against the 268 general system, as appose sub-components within the containment 269 hierarchy. 271 2.2.2 BackPlane 273 A value of unlocked for entStateAdmin means that the backplane is 274 not administratively prevented from aggregating and forwarding 275 network traffic. A value of shutting down for entStateAdmin means 276 that the backplane will finish aggregating and forwarding the 277 network traffic is currently handling, but then transition to be 278 administratively locked. A value of locked for entStateAdmin means 279 that backplane is administratively prohibited from aggregating and 280 forwarding any network traffic. A value of enabled for entStateOper 281 means that the backplane is partially or fully capable of 282 aggregating and forwarding network traffic. A value of disabled for 283 entStateOper means that the backplane is unable to aggregate and 284 forward any network traffic. 286 A value of hotStandby for enStateStandby indicates that the 287 backplane is running as a hot standby for another backplane within 288 this system. A value of coldStandby for enStateStandby indicates 289 that the backplane is running as a cold standby for another 290 backplane, possibly within this system. A value of providingService 291 for enStateStandby indicates that the backplane is currently 292 providing service. Looking at the entStateAlarm gives a convenient 293 way to see if there are any alarms currently active against this 294 backplane. 296 2.2.3 Container 298 A value of unlocked for entStateAdmin means it is administratively 299 possible to insert things into this container. A value of 300 shuttingDown for entStateAdmin could be used to reflect that 301 inserting objects into this container is administratively 302 prohibited. This value could also be used for systems that do not 303 support hot insertion of components. 305 The container physical class could be used to indicate, among other 306 things, chassis slots or daughter-card holders. If the container is 307 empty, for example it has no modules in its slots, then 308 entStateUsage would have a value of idle. If the container is 309 partially used, for example it has modules in some but now all of 310 its slots, then entStateUsage would have a value of busy. If the 311 container is full, for example it has no empty slots, then 312 entStateUsage would have a value of busy. 314 If it is not possible to raise alarms against this chassis, the 315 entStateAlarm will have no alarms set. It may not make sense for the 316 entStateOper to have values other than enabled. 318 Chisholm & Perkins Standards Track [Page 7]� 319 2.2.4 PowerSupply 321 If this power supply is the currently providing power to the system, 322 then entStateStandby would have a value of providing service. If 323 this power supply is serving as a backup to a primary power supply, 324 then entStateStandby would have a value of hotstandby. 326 A value of locked for entStateAdmin means that the power supply has 327 been turned off. This only makes sense in the situation where there 328 is a backup power supply. A value of unlocked for entStateAdmin 329 means that the power supply is turned on. A value of enabled for 330 entStateOper means that the power supply is operational. A value of 331 disabled for entStateOper means that the power supply is not 332 functioning. A value of idle for entStateUsage means that the power 333 supply is providing no power to the system. A value of busy for 334 entStateUsage means that the power supply is providing power to the 335 system. Looking at the entStateAlarm gives a convenient way to see 336 if there are any alarms currently active against this power supply. 338 2.2.5 Fan 340 If this fan is serving as a backup to a primary fan, then 341 entStateStandby would have a value of hotstandby. If this fan is the 342 currently providing service to the system, then entStateStandby 343 would have a value of providing service. A value of idle for 344 entStateUsage would indicate that the fan was not actually running. 345 A value of busy for entStateUsage would indicate that the fan was 346 running. 348 Looking at the entStateAdmin and entStateOper provide useful 349 information to determine why a fan is not running. A value of locked 350 for entStateAdmin means that the fan is not running because it has 351 been administratively disabled. A value of disabled for the 352 entOperStatus indicates that the fan itself is not operational. A 353 value of enabled for the entOperStatus indicates that the fan is 354 working in theory and that cause of it not operator may lie 355 elsewhere. Looking at the entStateAlarm gives a convenient way to 356 see if there are any alarms currently active against this fan. 358 2.2.6 Sensor 360 A value of unlocked for entStateAdmin indicates that the sensor is 361 not administratively prohibited from sensing. A value of shutting 362 down for entStateAdmin indicates that the sensor will complete its 363 current readings and then shut down. A value of locked for 364 entStateAdmin indicates that the sensor is administratively 365 prohibited from sensing. A value of enabled for entStateOper 366 indicates that the sensor is functioning properly. A value of 367 disable for entStateOper indicates that the sensor is totally 368 inoperable. 370 Looking at the entStateStandby indicates whether this sensor is 372 Chisholm & Perkins Standards Track [Page 8]� 373 currently providing service or acting as a backup for another 374 sensor. Looking at the entStateAlarm gives a convenient way to see 375 if there are any alarms currently active against this sensor. 377 2.2.7 Module 379 For modules that support the functionality of being administratively 380 disabled, entStateAdmin object indicates whether the module is 381 administratively locked (disabled) or unlocked (enabled). Modules 382 that do not support disabling will always have a value of unlocked 383 for entStateAdmin. A value of enabled for entStateOper indicates 384 that this module is partially or fully operational. A value of 385 disabled for entStateOper indicates that this module is totally 386 inoperable. A value of idle for entStateUsage indicates that this 387 module is currently not performing any functions. A value of active 388 entStateUsage indicates that this module is currently performing 389 functions, but capable of performing more. A value of busy for 390 entStateUsage indicates that the module is functioning at full 391 capacity and unable to perform further functions at this current 392 time. 394 Looking at the entStateStandby indicates whether this module is 395 currently providing service or acting as a backup for another 396 module. Looking at the entStateAlarm gives a convenient way to see 397 if there are any alarms currently active against this module. 399 2.2.8 Port 401 A value of enabled for entStateAdmin means the port is not 402 administratively prohibited from passing network traffic. A value of 403 shutting down for entStateAdmin indicates that the port will pass 404 its current traffic and then transition to the locked state. A value 405 of locked for entStateAdmin indicates that the port is 406 administratively prohibited from passing network traffic. A value of 407 enabled for entStateOper means that the port is partially or fully 408 capable of forwarding network traffic. A value of disabled for 409 entStateOper means that the port is totally unable to forward 410 network traffic. A value of idle for entStateUsage indicates that 411 the port is not currently in use. A value of busy for entStateUsage 412 indicates that the port is in use. 414 Looking at the entStateStandby indicates whether this port is 415 currently providing service or acting as a backup for another port. 416 Looking at the entStateAlarm gives a convenient way to see if there 417 are any alarms currently active against this port. 419 2.2.9 Stack 421 A value of unlocked for entStateAdmin means that this system is on. 422 A value of shuttingDown for entStateAdmin means that this system is 423 in the process of shutting down. A value of enabled for entStateOper 424 indicates that basic functions of this system are functioning. A 426 Chisholm & Perkins Standards Track [Page 9]� 427 value of disabled for entStateOper indicates a problem with basic 428 functions on the system. 430 A value of hotStandby for enStateStandby indicates that the entire 431 system contained within this stack is running as a hot standby for 432 another complete system, possibly contained within the same parent 433 stack. A value of coldStandby for enStateStandby indicates that the 434 entire system contained within this stack is running as a cold 435 standby for another complete system, possibly contained within the 436 same parent stack. A value of providingService for enStateStandby 437 indicates that the entire system contained within this chassis is 438 currently providing service. 440 If this stack is not contained in within a parent stack, the alarm 441 counts indicated by entStateAlarm will be those alarms that are 442 against the general system, as appose sub-components within the 443 containment hierarchy. 445 2.3 Relation to Alarm MIB 447 The entStateAlarm object indicates whether or not there are any 448 active alarms against this entity. If there are active alarms, then 449 the alarmActiveTable should be searched for alarmActiveResourceId 450 that match this entPhysicalIndex. 452 3. Definitions 454 ENTITY-STATE-MIB DEFINITIONS ::= BEGIN 456 IMPORTS 457 MODULE-IDENTITY, mib-2 458 FROM SNMPv2-SMI 459 TEXTUAL-CONVENTION 460 FROM SNMPv2-TC 461 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 462 FROM SNMPv2-CONF 463 entPhysicalIndex 464 FROM ENTITY-MIB; 466 entityStateMIB MODULE-IDENTITY 467 LAST-UPDATED "200301310000Z" 468 ORGANIZATION "IETF Entity MIB Working Group" 469 CONTACT-INFO 470 " Sharon Chisholm 471 Nortel Networks 472 PO Box 3511 Station C 473 Ottawa, Ont. K1Y 4H7 474 Canada 475 schishol@nortelnetworks.com 477 David T. Perkins 479 Chisholm & Perkins Standards Track [Page 10]� 480 dperkins@dperkins.com 481 " 482 DESCRIPTION 483 "This MIB defines a state extension to the entity MIB " 484 REVISION "200301310000Z" 485 DESCRIPTION 486 "Initial version, published as RFC XXXX." 487 ::= { mib-2 XX } 489 -- Textual conventions 491 AdminState ::= TEXTUAL-CONVENTION 492 STATUS current 493 DESCRIPTION 494 " Represents the various possible administrative states 495 (ITU-T X.731). 497 A value of locked means the resource is administratively 498 prohibited from use. A value of shuttingDown means that 499 usage is administratively limited to current instances of 500 use. A value of unlocked means the resource is not 501 administratively prohibited from use." 502 SYNTAX INTEGER 503 { 504 locked(1), 505 shuttingDown(2), 506 unlocked(3) 507 } 509 OperState ::= TEXTUAL-CONVENTION 510 STATUS current 511 DESCRIPTION 512 " Represents the possible values of operational states 513 (ITU-T X.731). 515 A value of disabled means the resource is totally 516 inoperable. A value of enabled means the resource 517 is partially or fully operable." 518 SYNTAX INTEGER 519 { 520 disabled(1), 521 enabled(2) 522 } 524 UsageState ::= TEXTUAL-CONVENTION 525 STATUS current 526 DESCRIPTION 527 " Represents the possible values of usage states 528 (ITU-T X.731). 530 Chisholm & Perkins Standards Track [Page 11]� 531 A value of idle means the resource is servicing no users. 532 A value of active means the resource is currently in use 533 and it has sufficient spare capacity to provide for 534 additional users. A value of busy means the resource is 535 currently in use, but it currently has no spare capacity 536 to provide for additional users." 537 SYNTAX INTEGER 538 { 539 idle(1), 540 active(2), 541 busy(3) 542 } 544 AlarmStatus ::= TEXTUAL-CONVENTION 545 STATUS current 546 DESCRIPTION 547 " Represents the possible values of alarm status 548 (ITU-T X.731). 550 When no values of this attribute are set, then none of the 551 status conditions described below are present. When the 552 value of under repair is set, the resource is currently 553 being repaired. 555 When the value of critical is set, one or more critical 556 alarms are active against the resource. When the value of 557 major is set, one or more major alarms are active against 558 the resource. When the value of minor is set, one or more 559 minor alarms are active against the resource. 561 When the value of alarm outstanding is set, one or more 562 alarms is active against the resource. The fault may or may 563 not be disabling. " 564 SYNTAX BITS 565 { 566 underRepair(0), 567 critical(1), 568 major(2), 569 minor(3), 570 alarmOutstanding(4), 571 warning (5), -- Not defined in X.731 572 indeterminate (6) -- Not defined in X.731 573 } 575 StandbyStatus ::= TEXTUAL-CONVENTION 576 STATUS current 577 DESCRIPTION 578 " Represents the possible values of standby status 579 (IU-T X.731). 581 Chisholm & Perkins Standards Track [Page 12]� 582 A value of hotStandby means the resource is not providing 583 service, but is will be immediately able to take over the 584 role of the resource to be backed-up, without the need for 585 initialization activity, and will contain the same 586 information as the resource to be backed up. A value of 587 coldStandy means that the resource is to back-up another 588 resource, but will not be immediately able to take over 589 the role of a resource to be backed up, and will require 590 some initialization activity. A value of providingService 591 means the resource is providing service. 592 " 594 SYNTAX INTEGER 595 { 596 hotStandby(1), 597 coldStandby(2), 598 providingService(3) 599 } 601 -- Entity State Objects 603 entStateObjects OBJECT IDENTIFIER ::= { entityStateMIB 1 } 605 entStateTable OBJECT-TYPE 606 SYNTAX SEQUENCE OF EntStateEntry 607 MAX-ACCESS not-accessible 608 STATUS current 609 DESCRIPTION 610 "A table of information about state/status of entities. 611 " 612 ::= { entStateObjects 1 } 614 entStateEntry OBJECT-TYPE 615 SYNTAX EntStateEntry 616 MAX-ACCESS not-accessible 617 STATUS current 618 DESCRIPTION "State information about this entity." 619 INDEX { entPhysicalIndex } 620 ::= { entStateTable 1 } 622 EntStateEntry ::= SEQUENCE { 623 entStateAdmin AdminState, 624 entStateOper OperState, 625 entStateUsage UsageState, 626 entStateAlarm AlarmStatus, 627 entStateStandby StandbyStatus 628 } 630 entStateAdmin OBJECT-TYPE 631 SYNTAX AdminState 632 MAX-ACCESS read-write 634 Chisholm & Perkins Standards Track [Page 13]� 635 STATUS current 636 DESCRIPTION 637 "The administrative state for this entity." 638 ::= { entStateEntry 1 } 640 entStateOper OBJECT-TYPE 641 SYNTAX OperState 642 MAX-ACCESS read-only 643 STATUS current 644 DESCRIPTION 645 "The operational state for this entity." 646 ::= { entStateEntry 2 } 648 entStateUsage OBJECT-TYPE 649 SYNTAX UsageState 650 MAX-ACCESS read-only 651 STATUS current 652 DESCRIPTION 653 "The usage state for this entity." 654 ::= { entStateEntry 3 } 656 entStateAlarm OBJECT-TYPE 657 SYNTAX AlarmStatus 658 MAX-ACCESS read-only 659 STATUS current 660 DESCRIPTION 661 "The alarm state for this entity. It does not include 662 the severity of alarms raised on child components." 663 ::= { entStateEntry 4 } 665 entStateStandby OBJECT-TYPE 666 SYNTAX StandbyStatus 667 MAX-ACCESS read-only 668 STATUS current 669 DESCRIPTION 670 �� "The standby status for this entity." 671 ::= { entStateEntry 5 } 673 -- Notifications 675 entStateTraps OBJECT IDENTIFIER ::= { entityStateMIB 2 } 676 entStateTrapPrefix OBJECT IDENTIFIER ::= { entStateTraps 0 } 678 entStateOperEnabled NOTIFICATION-TYPE 679 OBJECTS { entStateAdmin, 680 entStateAlarm 681 } 682 STATUS current 683 DESCRIPTION 684 "The entity is operational. The entity this notification 685 refers can be identified by extracting the 686 entPhysicalIndex from one of the variable bindings." 688 Chisholm & Perkins Standards Track [Page 14]� 689 ::= { entStateTrapPrefix 1 } 691 entStateOperDisabled NOTIFICATION-TYPE 692 OBJECTS { entStateAdmin, 693 entStateAlarm } 694 STATUS current 695 DESCRIPTION 696 "The entity is not operational. The entity this 697 notification 698 refers can be identified by extracting the 699 entPhysicalIndex from one of the variable bindings." 700 ::= { entStateTrapPrefix 2 } 702 -- Conformance and Compliance 704 entStateConformance OBJECT IDENTIFIER ::= { entityStateMIB 3 } 706 entStateCompliances OBJECT IDENTIFIER 707 ::= { entStateConformance 1 } 709 entStateCompliance MODULE-COMPLIANCE 710 STATUS current 711 DESCRIPTION 712 "The compliance statement for systems supporting 713 the Entity State MIB." 714 MODULE -- this module 715 MANDATORY-GROUPS { 716 entStateGroup 717 } 718 OBJECT entStateAdmin 719 MIN-ACCESS read-only 720 DESCRIPTION 721 "Write access is not required." 722 ::= { entStateCompliances 1 } 724 entStateGroups OBJECT IDENTIFIER ::= { entStateConformance 2 } 726 entStateGroup OBJECT-GROUP 727 OBJECTS { 728 entStateAdmin, 729 entStateOper, 730 entStateUsage, 731 entStateAlarm, 732 entStateStandby 733 } 734 STATUS current 735 DESCRIPTION 736 "Standard Entity State group." 737 ::= { entStateGroups 1} 739 entStateNotificationGroup NOTIFICATION-GROUP 740 NOTIFICATIONS { 742 Chisholm & Perkins Standards Track [Page 15]� 743 entStateOperEnabled, 744 entStateOperDisabled 745 } 746 STATUS current 747 DESCRIPTION 748 "Standard Entity State Notification group." 749 ::= { entStateGroups 2} 751 END 752 � 753 4. Security Considerations 755 There is one management objects defined in this MIB that has a 756 MAX-ACCESS clause of read-write. Such objects may be considered 757 sensitive or vulnerable in some network environments. The support 758 for SET operations in a non-secure environment without proper 759 protection can have a negative effect on network operations. 761 The following object is defined with a MAX-ACCESS clause of 762 read-write: entStateAdmin. 764 SNMPv1 by itself is not a secure environment. Even if the network 765 itself is secure (for example by using IPSec), even then, there is 766 no control as to who on the secure network is allowed to access and 767 GET/SET (read/change/create/delete) the objects in this MIB. 769 It is recommended that the implementers consider the security 770 features as provided by the SNMPv3 framework. Specifically, the use 771 of the User-based Security Model RFC 2574 [RFC2574] and the 772 View-based Access Control Model RFC 2575 [RFC2575] is recommended. 774 It is then a customer/user responsibility to ensure that the SNMP 775 entity giving access to an instance of this MIB, is properly 776 configured to give access to the objects only to those principals 777 (users) that have legitimate rights to indeed GET or SET 778 (change/create/delete) them. 780 5. Authors' Addresses 782 Sharon Chisholm 783 Nortel Networks 784 PO Box 3511, Station C 785 Ottawa, Ontario, K1Y 4H7 786 Canada 787 Email: schishol@nortelnetworks.com 789 David T. Perkins 790 Email: dperkins@dperkins.com 792 Chisholm & Perkins Standards Track [Page 16]� 793 6. Acknowledgments 795 This document is a product of the Entity MIB Working Group. 797 7. References 799 [ALARM-MIB] Chisholm, S., Romascanu, D., "Alarm MIB", 800 draft-ietf-disman-alarm-mib-09.txt, September 2002 802 [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification 803 of Management Information for TCP/IP-based Internets", STD 804 16, RFC 1155, May 1990. 806 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 807 "Simple Network Management Protocol", STD 15, RFC 1157, 808 May 1990. 810 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", 811 STD 16, RFC 1212, March 1991. 813 [RFC1215] M. Rose, "A Convention for Defining Traps for use with the 814 SNMP", RFC 1215, March 1991. 816 [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 817 "Introduction to Community-based SNMPv2", RFC 1901, 818 January 1996. 820 [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 821 "Protocol Operations for Version 2 of the Simple Network 822 Management Protocol (SNMPv2)", RFC 1905, January 1996. 824 [RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 825 "Transport Mappings for Version 2 of the Simple Network 826 Management Protocol (SNMPv2)", RFC 1906, January 1996. 828 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 829 Requirement Levels", BCP 14, RFC 2119, March 1997. 831 [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, 832 "Introduction to Version 3 of the Internet-standard 833 Network Management Framework", RFC 2570, April 1999. 835 [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An 836 Architecture for Describing SNMP Management Frameworks", 837 RFC 2571, April 41999. 839 Chisholm & Perkins Standards Track [Page 17]� 841 [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, 842 "Message Processing and Dispatching for the Simple 843 Network Management Protocol (SNMP)", RFC 2572, April 844 1999. 846 [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 847 Applications", RFC 2573, April 1999. 849 [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model 850 (USM) for version 3 of the Simple Network Management 851 Protocol (SNMPv3)", RFC 2574, April 1999. 853 [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 854 Access Control Model (VACM) for the Simple Network 855 Management Protocol (SNMP)", RFC 2575, April 1999. 857 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 858 Rose, M., and S. Waldbusser, "Structure of Management 859 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 860 1999. 862 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 863 Rose, M., and S. Waldbusser, "Textual Conventions for 864 SMIv2", STD 58, RFC 2579, April 1999. 866 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 867 Rose, M., and S. Waldbusser, "Conformance Statements for 868 SMIv2", STD 58, RFC 2580, April 1999. 870 [X.731] ITU Recommendation X.731, "Information Technology - Open 871 Systems Interconnection - System Management: State 872 Management Function", 1992 874 8. Full Copyright Statement 876 Copyright (C) The Internet Society (2003). All Rights Reserved. 878 This document and translations of it may be copied and furnished to 879 others, and derivative works that comment on or otherwise explain it 880 or assist in its implementation may be prepared, copied, published 881 and distributed, in whole or in part, without restriction of any kind, 882 provided that the above copyright notice and this paragraph are 883 included on all such copies and derivative works. However, this 884 document itself may not be modified in any way, such as by removing 885 the copyright notice or references to the Internet Society or other 886 Internet organizations, except as needed for the purpose of 887 developing Internet standards in which case the procedures for 888 copyrights defined in the Internet Standards process must be followed, 889 or as required to translate it into languages other than English. 891 The limited permissions granted above are perpetual and will not be 892 revoked by the Internet Society or its successors or assigns. 894 Chisholm & Perkins Standards Track [Page 18]� 895 This document and the information contained herein is provided on an 896 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 897 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 898 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 899 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 900 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 902 Chisholm & Perkins Standards Track [Page 19]�