idnits 2.17.1 draft-ietf-disman-conditionmib-10.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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == Unrecognized Status in 'Category: Internet Draft', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 (September 25, 2003) is 7520 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'RFCzzzz' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITUALARMTC' Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group H.K. Lam 2 Document: draft-ietf-disman-conditionmib-10.txt Lucent Technologies 3 Expiration: March 25, 2004 A. Huynh 4 Category: Internet Draft Cetus Networks 5 D. Perkins 6 SNMPinfo 7 September 25, 2003 9 Alarm Reporting Control MIB 11 draft-ietf-disman-conditionmib-10.txt 13 Status of this Memo 15 This document is an Internet-Draft and is subject to 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 Abstract 40 This memo defines a portion of the Management Information Base (MIB) 41 for use with network management protocols in TCP/IP-based internets. 42 In particular, it defines objects for controlling the reporting of 43 alarm conditions. 45 Table of Contents 47 1 Introduction ............................................... xx 48 2 The Internet-Standard Management Framework .................. xx 50 Alarm Reporting Control MIB July 2003 52 3 Conventions ................................................ xx 53 4 ARC MIB Overview ............................................ xx 54 4.1 Relationship between ARC mode and Alarm Reporting ...... xx 55 5 ARC MIB Object Definitions .................................. xx 56 6 Security Considerations ..................................... xx 57 7 Acknowledgments.............................................. xx 58 8 References .................................................. xx 59 9 Author's Address ............................................ xx 60 10 Intellectual Property ....................................... xx 61 11 Full Copyright Statement .................................... xx 63 1. Introduction 65 The scope of this MIB is targeted for network operators responsible 66 for managing the operations of network resources. This document 67 defines an alarm reporting control (ARC) MIB module, which provides 68 a mechanism for a manager to suppress or defer the reporting of alarm 69 conditions based on the resource ID and alarm condition type. 71 2. The Internet-Standard Management Framework 73 For a detailed overview of the documents that describe the current 74 Internet-Standard Management Framework, please refer to section 7 of 75 RFC 3410 [RFC3410]. 77 Managed objects are accessed via a virtual information store, termed 78 the Management Information Base or MIB. MIB objects are generally 79 accessed through the Simple Network Management Protocol (SNMP). 80 Objects in the MIB are defined using the mechanisms defined in the 81 Structure of Management Information (SMI). This memo specifies a MIB 82 module that is compliant to the SMIv2, which is described in STD 58, 83 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 84 [RFC2580]. 86 3. Conventions 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [RFC2119]. 92 4. ARC MIB Overview 94 There is a need to provide a mechanism for controlling the reporting 95 of alarm conditions of resources in a network device. For example, 96 (a) inhibiting the reporting of alarm conditions of a resource until 98 Alarm Reporting Control MIB July 2003 100 the resource is problem-free, (b) inhibiting the reporting of alarm 101 conditions of a resource for a specified time period, or 102 (c) inhibiting the reporting of alarm conditions of a resource 103 indefinitely until explicitly allowed by the managing system at a 104 later time. 106 The alarm reporting control (ARC) feature provides an automatic 107 in-service provisioning capability. It allows sufficient time for 108 service setup, customer testing, and other maintenance activities in 109 an "alarm-free" state. Once a resource is "problem-free", 110 alarm reporting can be automatically or manually turned on 111 (i.e., allowed). 113 By putting a network resource in ARC mode, (i.e., in nalm, nalmTI, 114 nalmQI, or nalmQICD states, as described in the MIB), the technicians 115 and managing systems will not be flooded with unnecessary work items 116 during operations activities such as service provisioning and 117 network setup/teardown. This will reduce maintenance costs and 118 improve the operation and maintenance of these systems. 119 Putting a network resource in ARC mode shall not affect the 120 availability of active alarm condition information for potential 121 retrieval. 123 ITU-T Recommendation M.3100 Amendment 3 [M.3100 Amd3] provides the 124 business requirements, analysis, and design of the Alarm Reporting 125 Control feature. 127 This document defines the MIB objects to support a subset of 128 the ARC functions described in M.3100 Amd3. In particular, it 129 defines a table that can be used to specify the ARC settings for 130 the resources in a system. 132 The ARC MIB module defined in this document provides a way to control 133 the reporting of alarm conditions. A set of applicable alarm 134 conditions is defined in ITU-T Recommendation M.3100 [M.3100] and is 135 named "probable causes". These probable causes (alarm conditions) 136 have been included in the IANAItuProbableCause TC, which is defined 137 in the IANA-ITU-ALARM-TC MIB module [RFCzzzz]. The IANA-ITU-ALARM-TC 138 MIB module is maintained in the IANA web-site [ITUALARMTC]. 139 [RFCzzzz]. 140 -- RFC Ed.: replace zzzz with the actual RFC number of the Alarm MIB 141 -- document and remove this notice. 143 The ARC MIB module defines an IANAItuProbableCauseOrZero TC which 144 can take any value of IANAItuProbableCause or 0. 145 The ARC MIB module further uses IANAItuProbableCauseOrZero to define 146 the ARC settings for the managed resource in the network elements. 147 Specification of objects for defining and storing alarms, including 149 Alarm Reporting Control MIB July 2003 151 active and history alarms, standing and transient alarms, and alarm 152 notifications are out of the scope of this document. 154 4.1 Relationship between ARC mode and alarm reporting 156 When the ARC MIB module is used in a managed system, the following 157 rules apply: 159 For alarm condition raised prior to entering ARC mode, reporting 160 of alarm raised and alarm cleared will be sent as usual. 162 For alarm condition raised after entering ARC mode and also 163 cleared before exiting ARC mode, no reporting of alarm raised will 164 be sent and no reporting of alarm cleared will be sent. 166 For alarm condition raised after entering ARC mode and not cleared 167 when exiting ARC mode, the reporting of alarm raised will be 168 deferred until the moment of exiting ARC mode. The reporting of 169 alarm cleared will be sent as usual (i.e., at the time of alarm 170 cleared). 172 Further details of the ARC function can be found in M.3100 Amd3 173 [M.3100 Amd3]. 175 5. ARC MIB Object Definition 177 ARC-MIB DEFINITIONS ::= BEGIN 179 IMPORTS 180 MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, mib-2 181 FROM SNMPv2-SMI -- RFC2578 182 TEXTUAL-CONVENTION, RowStatus, StorageType 183 FROM SNMPv2-TC -- RFC2579 184 MODULE-COMPLIANCE, OBJECT-GROUP 185 FROM SNMPv2-CONF -- RFC2580 186 ResourceId 187 FROM ALARM-MIB; -- RFCzzzz 189 arcMibModule MODULE-IDENTITY 190 LAST-UPDATED "200309250000Z" 191 ORGANIZATION "IETF Distributed Management Working Group" 192 CONTACT-INFO 193 "WG EMail: disman@ietf.org 194 Subscribe: disman-request@ietf.org 195 http://www.ietf.org/html.charters/disman-charter.html 197 Alarm Reporting Control MIB July 2003 199 Chair: Randy Presuhn 200 E-mail: randy_presuhn@mindspring.com 202 Editor: Hing-Kam Lam 203 Lucent Technologies, 4C-616 204 101 Crawfords Corner Road 205 Holmdel, NJ 07733 206 USA 207 Tel: +1 732 949 8338 208 E-mail: hklam@lucent.com" 210 DESCRIPTION 211 "The MIB module describes the objects for controlling a resource 212 in reporting alarm conditions that it detects. 214 Copyright (C) The Internet Society (2003). This version 215 of this MIB module is part of RFC xxxx; see the RFC 216 itself for full legal notices." 217 -- RFC Ed.: replace xxxx with actual RFC number & remove this note 218 REVISION "200309250000Z" 219 DESCRIPTION 220 "Initial version, published as RFC xxxx." 221 -- RFC Ed.: replace xxxx with actual RFC number & remove this note 222 ::={ mib-2 yy } -- to be assigned by IANA 223 -- RFC Ed.: replace yy with IANA-assigned number & remove this note 225 ------------------ 226 -- TEXTUAL-CONVENTION 227 ------------------ 229 IANAItuProbableCauseOrZero ::= TEXTUAL-CONVENTION 230 STATUS current 231 DESCRIPTION 232 "This TC can take any value of IANAItuProbableCause or 0. 233 IANAItuProbableCause is defined in the IANA-ITU-ALARM-TC 234 module, which is maintained at the IANA web site and 235 published in the Alarm MIB document (see RFC zzzz)." 236 REFERENCE 237 "IANA-ITU-ALARM-TC MIB module as maintained at the IANA web site. 238 The initial module was also published in RFC zzzz." 239 -- RFC Ed.: replace zzzz with the RFC number of the Alarm MIB document. 240 -- 241 SYNTAX INTEGER (0..2147483647) 243 Alarm Reporting Control MIB July 2003 245 ------------------ 246 -- MIB Objects 247 ------------------ 249 arcTimeIntervals OBJECT IDENTIFIER ::= { arcMibModule 1 } 250 arcObjects OBJECT IDENTIFIER ::= { arcMibModule 2 } 252 arcTITimeInterval OBJECT-TYPE 253 SYNTAX Unsigned32 254 UNITS "seconds" 255 MAX-ACCESS read-write 256 STATUS current 257 DESCRIPTION 258 "This variable indicates the time interval used for the nalmTI 259 state, in units of second. It is a pre-defined length of time 260 in which the resource will stay in the nalmTI state before 261 transition into the alm state. 263 Instances of this object SHOULD persist across agent restarts." 264 ::= { arcTimeIntervals 1 } 266 arcCDTimeInterval OBJECT-TYPE 267 SYNTAX Unsigned32 268 UNITS "seconds" 269 MAX-ACCESS read-write 270 STATUS current 271 DESCRIPTION 272 "This variable indicates the time interval used for the nalmQICD 273 state, in units of second. It is a pre-defined length of time 274 in which the resource will stay in the nalmQICD state before 275 transition into the alm state after it is problem-free. 277 Instances of this object SHOULD persist across agent restarts." 278 ::= { arcTimeIntervals 2 } 280 arcTable OBJECT-TYPE 281 SYNTAX SEQUENCE OF ArcEntry 282 MAX-ACCESS not-accessible 283 STATUS current 284 DESCRIPTION 285 "A table of Alarm Reporting Control (ARC) settings on the system. 287 Alarm Reporting Control is a feature that provides an automatic 288 in-service provisioning capability. Alarm reporting is turned 289 off on a per-resource basis for a selective set of potential 290 alarm conditions to allow sufficient time for customer testing 291 and other maintenance activities in an 'alarm free' state. 292 Once a resource is ready for service, alarm reporting is 293 automatically or manually turned on. 295 Alarm Reporting Control MIB July 2003 297 Defined in M.3100 Amendment 3 [M.3100 Amd3], there are five 298 ARC states: alm, nalm, nalmQI, nalmQICD and nalmTI. 300 alm: Alarm reporting is turned on (i.e., is allowed). 301 nalm: Alarm reporting is turned off (i.e., not allowed). 302 nalmQI: nalm - Qualified Inhibit. Alarm reporting is 303 turned off until the managed entity is qualified 304 problem-free for a specified persistence interval. 305 nalmQICD: nalmQI - Count down. This is a substate of nalmQI 306 and performs the persistence timing countdown 307 function when the managed entity is qualified 308 problem-free. 309 nalmTI: nalm - Timed Inhibit. Alarm reporting is turned 310 off for a specified time interval. 312 alm may transition to nalm, nalmQI or nalmTI by management request. 314 nalm may transition to alm, nalmQI or nalmTI by management request. 316 nalmQI may transition to nalm or alm by management request. 318 nalmQI may transition to alm automatically 319 if qualified problem-free (if nalmQICD is not supported) or 320 if the CD timer expired (if nalmQICD is supported) 322 nalmTI may transition to alm or nalm by management request. 324 nalmTI may transition to alm automatically if the TI timer expired. 326 Further details of ARC state transitions are defined in Figure 3 327 of M.3100 Amd3 [M.3100 Amd3]." 328 REFERENCE 329 "ITU Recommendation M.3100 Amendment 3, 'Generic Network 330 Information Model', January 2001." 331 ::= { arcObjects 1 } 333 arcEntry OBJECT-TYPE 334 SYNTAX ArcEntry 335 MAX-ACCESS not-accessible 336 STATUS current 337 DESCRIPTION 338 "A conceptual row that contains information about an ARC setting 339 of a resource in the system. 341 Implementation need to be aware that if the total size of 342 arcIndex and arcNotificationId exceeds 114 sub-IDs, then OIDs 343 of column instances in this table will have more than 128 344 sub-IDs and cannot be access using SNMPv1, SNMPv2c, or snmpv3." 346 Alarm Reporting Control MIB July 2003 348 INDEX { arcIndex, arcAlarmType, arcNotificationId } 349 ::= { arcTable 1 } 351 ArcEntry ::= 352 SEQUENCE { 353 arcIndex ResourceId, 354 arcAlarmType IANAItuProbableCauseOrZero, 355 arcNotificationId OBJECT IDENTIFIER, 356 arcState INTEGER, 357 arcNalmTimeRemaining Unsigned32, 358 arcRowStatus RowStatus, 359 arcStorageType StorageType 360 } 362 arcIndex OBJECT-TYPE 363 SYNTAX ResourceId 364 MAX-ACCESS not-accessible 365 STATUS current 366 DESCRIPTION 367 "This object uniquely identifies a resource, which is under the 368 arcState's control for the associated arcAlarmType. 370 For example, if the resource is an interface, this object will 371 point to an instance of interface, e.g., ifIndex.1." 372 ::= { arcEntry 1 } 374 arcAlarmType OBJECT-TYPE 375 SYNTAX IANAItuProbableCauseOrZero 376 MAX-ACCESS not-accessible 377 STATUS current 378 DESCRIPTION 379 "This object identifies the alarm condition type controlled by the 380 arcState. It specifies the value 0 or a value of 381 IANAItuProbableCause that is applicable to the resource. 382 IANAItuProbableCause is defined in the IANA-ITU-ALARM-TC 383 module in the Alarm MIB document. 385 The value of zero (0) implies any probable causes that are 386 applicable to the resource. Usually, the applicable probable 387 causes of a resource are specified in the resource-specific mib." 388 ::= { arcEntry 2 } 390 arcNotificationId OBJECT-TYPE 391 SYNTAX OBJECT IDENTIFIER 392 MAX-ACCESS not-accessible 393 STATUS current 394 DESCRIPTION 395 "This object identifies the type of notification to be suppressed. 396 The notification type identified should be the one normally used 398 Alarm Reporting Control MIB July 2003 400 by the resource for reporting its alarms. When the value of 0.0 is 401 specified for this object, it implies all applicable notification 402 types." 403 ::= { arcEntry 3 } 405 arcState OBJECT-TYPE 406 SYNTAX INTEGER { 407 nalm (1), 408 nalmQI (2), 409 nalmTI (3), 410 nalmQICD (4) 411 } 412 MAX-ACCESS read-create 413 STATUS current 414 DESCRIPTION 415 "This object controls the alarm reporting of a resource. A manager 416 can set the arcState to either nalm, nalmQI, or nalmTI. 418 nalm: Alarm reporting is turned off. 419 nalmTI: Alarm reporting is turned off for a time interval. 420 (TI - Time Inhibit). 421 nalmQI: Alarm reporting is turned off for a specified 422 alarm type until the resource is qualified 423 problem-free for an optional time interval. 424 Problem-free means that the condition corresponding 425 to the specified alarm type does not exist 426 (i.e., cleared). 427 (QI - Qualified Inhibit). 428 nalmQICD: This is a substate of nalmQI and performs the 429 persistence timing count down function after the 430 resource is qualified problem-free. 431 (CD - Count Down). 433 According to the requirements in M.3100 Amd3, a resource 434 supporting the ARC feature shall support the alm state and at 435 least one of the nalm, nalmTI, and nalmQI states. nalmQICD 436 is an optional substate of nalmQI. 438 Note that the state alm (alarm reporting is allowed) is not listed 439 in the enumeration of the value of this object. However, this 440 state is implicitly supported by the mib. 441 Once a resource enters the normal reporting mode (i.e., in the alm 442 state) for the specified alarm type, the corresponding 443 row will be automatically deleted from the arc table. 444 Also the manual setting of arcState to alm can be achieved through 445 setting the RowStatus object to 'destroy'. 447 The nalamQICD state is a transitional state from nalmQI to alm. It 448 is optional depending on the resource type and the implementation 449 of the the resource. If it is supported, before the state 451 Alarm Reporting Control MIB July 2003 453 transitions from nalmQI to alm, a count down period is activated 454 for a duration set by the object arcNalmCDTimeInterval. When the 455 time is up, the arcState transitions to alm." 456 ::= { arcEntry 4 } 458 arcNalmTimeRemaining OBJECT-TYPE 459 SYNTAX Unsigned32 460 UNITS "seconds" 461 MAX-ACCESS read-create 462 STATUS current 463 DESCRIPTION 464 "This variable indicates the time remaining in the nalmTI state 465 or the nalmQICD state, in units of second. 467 At the moment the resource enters the nalmTI state, this variable 468 will have the initial value equal to the value of 469 arcNalmTITimeInterval and then starts decrementing as time goes by. 471 Similarly at the moment the resource enters the nalmQICD state, 472 this variable will have the initial value equal to the value of 473 arcNalmCDTimeInterval and then starts decrementing as time goes by. 475 This variable is read-create and thus will allow the manager to 476 write (extend or shorten), as needed, the remaining time when the 477 resource is in the nalmTI or nalmQICD state. 479 If this variable is supported and the resource is currently not in 480 the nalmTI nor nalmQICD state, the value of this variable shall 481 equal to zero." 482 ::= { arcEntry 5 } 484 arcRowStatus OBJECT-TYPE 485 SYNTAX RowStatus 486 MAX-ACCESS read-create 487 STATUS current 488 DESCRIPTION 489 "This columnar object is used for creating and deleting a conceptual 490 row of the arcTable. It is used to create and delete an arc 491 setting. 493 Setting RowStatus to createAndGo or createAndWait implies creating 494 a new ARC setting for the specified resource and alarm type. 495 Setting RowStatus to destroy implies removing the ARC setting and 496 thus has the effect of resuming normal reporting behaviour of the 497 resource for the alarm type. 499 Only the objects arcState, arcNalmTimeRemaining, and arcRowStatus 500 can be updated when a row is active. All the objects, except 501 arcNalmTimeRemaining, must be set before the row can be activated." 502 ::= { arcEntry 6 } 504 Alarm Reporting Control MIB July 2003 506 arcStorageType OBJECT-TYPE 507 SYNTAX StorageType 508 MAX-ACCESS read-create 509 STATUS current 510 DESCRIPTION 511 "The storage type for this conceptual row. 512 Conceptual rows having the value 'permanent' must 513 allow write-access at a minimum to arcState. 514 Note that arcState must allow change by management request. 515 Therefore, no row can be created with 'readOnly'. 516 If a set operation tries to set the value to 'readOnly', 517 then an 'inconsistentValue' error must be returned." 518 DEFVAL { nonVolatile } 519 ::= { arcEntry 7} 521 -------------------------- 522 -- conformance information 523 -------------------------- 525 arcConformance OBJECT IDENTIFIER ::= { arcMibModule 3 } 527 arcCompliances OBJECT IDENTIFIER ::= { arcConformance 1 } 529 arcCompliance MODULE-COMPLIANCE 530 STATUS current 531 DESCRIPTION 532 "The compliance statement for systems supporting 533 the ARC MIB module." 535 MODULE -- this module 536 MANDATORY-GROUPS { 537 arcSettingGroup 538 } 540 OBJECT arcStorageType 541 WRITE-SYNTAX StorageType { 542 volatile(2), 543 nonVolatile(3), 544 permanent(4) 545 } 546 DESCRIPTION 547 "Support for value 'other' is not required. 548 The arcState object must allow change by management 549 request. Therefore, no row can be created with 550 'readOnly'." 552 GROUP arcTIGroup 553 DESCRIPTION 554 "This group is REQUIRED for ARC settings 556 Alarm Reporting Control MIB July 2003 558 that provide the Time Inhibit (TI) function." 560 GROUP arcQICDGroup 561 DESCRIPTION 562 "This group is REQUIRED for ARC settings 563 that provide the Quality Inhibit (QI) Count Down (CD) 564 function." 566 ::= { arcCompliances 1 } 568 arcGroups OBJECT IDENTIFIER ::= { arcConformance 2 } 570 arcSettingGroup OBJECT-GROUP 571 OBJECTS { 572 arcState, 573 arcRowStatus, 574 arcStorageType 575 } 576 STATUS current 577 DESCRIPTION 578 "A collection of objects applicable to 579 basic ARC setting." 580 ::= { arcGroups 1} 582 arcTIGroup OBJECT-GROUP 583 OBJECTS { 584 arcTITimeInterval, 585 arcNalmTimeRemaining 586 } 587 STATUS current 588 DESCRIPTION 589 "A collection of objects applicable to 590 ARC setting that support the Time Inhibit (TI) 591 function." 592 ::= { arcGroups 2} 594 arcQICDGroup OBJECT-GROUP 595 OBJECTS { 596 arcCDTimeInterval, 597 arcNalmTimeRemaining 598 } 599 STATUS current 600 DESCRIPTION 601 "A collection of objects applicable to 602 ARC setting that support the Quality Inhibit (QI) 603 Count Down (CD) function." 604 ::= { arcGroups 3} 606 END 608 Alarm Reporting Control MIB July 2003 610 6. Security Considerations 612 There are a number of management objects defined in this MIB module 613 with a MAX-ACCESS clause of read-write and/or read-create. Such 614 objects may be considered sensitive or vulnerable in some network 615 environments. The support for SET operations in a non-secure 616 environment without proper protection can have a negative effect on 617 network operations. These are the tables and objects and their 618 sensitivity/vulnerability: 620 arcTITimeInterval, 621 arcCDTimeInterval, 622 arcState, 623 arcNalmTimeRemaining, 624 arcRowStatus, 625 arcStorageType. 627 Setting these objects may have disruptive effects on network 628 operation that range from omission of alarm notifications 629 to flooding of unwanted alarm notifications from the netowrk. 631 Some of the readable objects in this MIB module (i.e., objects with a 632 MAX-ACCESS other than not-accessible) may be considered sensitive or 633 vulnerable in some network environments. It is thus important to 634 control even GET and/or NOTIFY access to these objects and possibly 635 to even encrypt the values of these objects when sending them over 636 the network via SNMP. These are the tables and objects and their 637 sensitivity/vulnerability: 639 arcTITimeInterval, 640 arcCDTimeInterval, 641 arcState, 642 arcNalmTimeRemaining, 643 arcRowStatus, 644 arcStorageType. 646 Reading these objects will provide information about the setting 647 which affects alarm notification generation. 649 SNMP versions prior to SNMPv3 did not include adequate security. 650 Even if the network itself is secure (for example by using IPSec), 651 even then, there is no control as to who on the secure network 652 is allowed to access and GET/SET (read/change/create/delete) the 653 objects in this MIB module. 655 It is RECOMMENDED that implementers consider the security features 656 as provided by the SNMPv3 framework (see [RFC3410], section 8), 657 including full support for the SNMPv3 cryptographic mechanisms 658 (for authentication and privacy). 660 Alarm Reporting Control MIB July 2003 662 Further, deployment of SNMP versions prior to SNMPv3 is NOT 663 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 664 enable cryptographic security. It is then a customer/operator 665 responsibility to ensure that the SNMP entity giving access to 666 an instance of this MIB module is properly configured to give 667 access to the objects only to those principals (users) that have 668 legitimate rights to indeed GET or SET (change/create/delete) them. 670 7. Acknowledgements 671 The authors wish to thank Brian Teer and Sharon Chisholm for 672 reviewing and commenting on the draft of this document. 674 8. References 676 8.1 Normative References 678 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 679 Requirements Levels", BCP 14, RFC 2119, March 1997. 681 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 682 Rose, M., and S. Waldbusser, "Structure of Management 683 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 684 1999. 686 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 687 Rose, M., and S. Waldbusser, "Textual Conventions for 688 SMIv2", STD 58, RFC 2579, April 1999. 690 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 691 Rose, M., and S. Waldbusser, "Conformance Statements for 692 SMIv2", STD 58, RFC 2580, April 1999. 694 [RFCzzzz] Chisholm, S. and D. Romascanu, "Alarm MIB", RFC zzzz, 695 mmm 2003. 696 -- RFC Ed.: replace zzzz with the RFC number of the Alarm MIB document, 697 -- replace mmm with the actual month, and remove this notice. 699 [ITUALARMTC] http://www.iana.org/assignments/ianaitualarmtc-mib 701 [M.3100] ITU Recommendation M.3100, "Generic Network Information 702 Model", July 1995. 704 [M.3100 Amd3] 705 ITU Recommendation M.3100 Amendment 3, "Generic Network 706 Information Model", January 2001. 708 8.2 Informative References 710 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 711 "Introduction and Applicability Statements for Internet- 713 Alarm Reporting Control MIB July 2003 715 Standard Management Framework", RFC 3410, December 2002. 717 9. Authors' Addresses 719 Hing-Kam Lam 720 Lucent Technologies 721 101 Crawfords Corner Road, Room 4C-616 722 Holmdel, NJ 07733 723 USA 724 Phone: +1 732-949-8338 725 EMail: hklam@lucent.com 727 An-ni Huynh 728 Cetus Networks 729 USA 731 EMail: a_n_huynh@yahoo.com 733 David T. Perkins 734 SNMPinfo 735 3600 Benton Street, #24 736 Santa Clara, CA 95051 737 USA 738 Phone: +1 408-394-8702 739 EMail: dperkins@dsperkins.com 741 10. Intellectual Property 743 The IETF takes no position regarding the validity or scope of any 744 intellectual property or other rights that might be claimed to 745 pertain to the implementation or use of the technology described in 746 this document or the extent to which any license under such rights 747 might or might not be available; neither does it represent that it 748 has made any effort to identify any such rights. Information on the 749 IETF's procedures with respect to rights in standards-track and 750 standards-related documentation can be found in BCP-11. Copies of 751 claims of rights made available for publication and any assurances of 752 licenses to be made available, or the result of an attempt made to 753 obtain a general license or permission for the use of such 754 proprietary rights by implementers or users of this specification can 755 be obtained from the IETF Secretariat. 757 The IETF invites any interested party to bring to its attention any 758 copyrights, patents or patent applications, or other proprietary 759 rights which may cover technology that may be required to practice 760 this standard. Please address the information to the IETF Executive 761 Director. 763 Alarm Reporting Control MIB July 2003 765 11. Full Copyright Statement 767 Copyright (C) The Internet Society (2003). All Rights Reserved. 769 This document and translations of it may be copied and furnished to 770 others, and derivative works that comment on or otherwise explain it 771 or assist in its implementation may be prepared, copied, published 772 and distributed, in whole or in part, without restriction of any 773 kind, provided that the above copyright notice and this paragraph are 774 included on all such copies and derivative works. However, this 775 document itself may not be modified in any way, such as by removing 776 the copyright notice or references to the Internet Society or other 777 Internet organizations, except as needed for the purpose of 778 developing Internet standards in which case the procedures for 779 copyrights defined in the Internet Standards process must be 780 followed, or as required to translate it into languages other than 781 English. 783 The limited permissions granted above are perpetual and will not be 784 revoked by the Internet Society or its successors or assigns. 786 This document and the information contained herein is provided on an 787 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 788 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 789 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 790 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 791 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.