idnits 2.17.1 draft-ietf-ifmib-testmib-05.txt: ** The Abstract section seems to be numbered 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 ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2. Abstract' ) ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 9. Security Considerations' ) ** 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 an Authors' Addresses Section. ** There are 33 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([15], [2], [3], [16], [17], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (April 7, 1999) is 9150 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 section? '16' on line 816 looks like a reference -- Missing reference section? '1' on line 730 looks like a reference -- Missing reference section? '2' on line 735 looks like a reference -- Missing reference section? '3' on line 740 looks like a reference -- Missing reference section? '4' on line 744 looks like a reference -- Missing reference section? '5' on line 748 looks like a reference -- Missing reference section? '6' on line 755 looks like a reference -- Missing reference section? '7' on line 762 looks like a reference -- Missing reference section? '8' on line 769 looks like a reference -- Missing reference section? '9' on line 775 looks like a reference -- Missing reference section? '10' on line 781 looks like a reference -- Missing reference section? '11' on line 788 looks like a reference -- Missing reference section? '12' on line 853 looks like a reference -- Missing reference section? '13' on line 799 looks like a reference -- Missing reference section? '14' on line 806 looks like a reference -- Missing reference section? '15' on line 854 looks like a reference -- Missing reference section? '17' on line 820 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT System/Interface Test MIB April 7, 1999 3 Definitions of Managed Objects for 4 System and Interface Testing 6 April 7, 1999 8 Internet-Draft 10 Maria Greene 11 Xedia Corp. 12 maria@xedia.com 14 Keith McCloghrie 15 Cisco Systems 16 kzm@cisco.com 18 Kaj Tesink 19 Telcordia Technologies 20 kaj@research.telcordia.com 22 1. Status of this Memo 24 This document is an Internet-Draft and is in full conformance 25 with all provisions of Section 10 of RFC2026. 27 Internet-Drafts are working documents of the Internet 28 Engineering Task Force (IETF), its areas, and its working 29 groups. Note that other groups may also distribute working 30 documents as Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other 34 documents at any time. It is inappropriate to use Internet- 35 Drafts as reference material or to cite them other than as 36 "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be accessed 42 at http://www.ietf.org/shadow.html. 44 Copyright (C) The Internet Society (1998). All Rights 45 Reserved. 47 2. Abstract 49 This memo defines an portion of the Management Information 50 Base (MIB) for use with network management protocols in the 51 Internet community. In particular, it describes objects used 52 for testing systems and interfaces. This memo defines the 53 following: 55 0 A general mechanism to initiate tests 57 0 A capability to provide and store test results 59 0 A capability to inventory the tests that are supported by 60 an agent 62 This memo does not specify individual tests. Such tests are 63 subject of separate system- or media-specific specifications. 65 This memo replaces the objects defined in the ifTestGroup of 66 RFC2233[16] which have been deprecated. 68 3. The SNMP Network Management Framework 70 The SNMP Management Framework presently consists of five major 71 components: 73 0 An overall architecture, described in RFC 2271 [1]. 75 0 Mechanisms for describing and naming objects and events 76 for the purpose of management. The first version of this 77 Structure of Management Information (SMI) is called SMIv1 78 and described in RFC 1155 [2], RFC 1212 [3] and RFC 1215 79 [4]. The second version, called SMIv2, is described in 80 RFC 1902 [5], RFC 1903 [6] and RFC 1904 [7]. 82 0 Message protocols for transferring management 83 information. The first version of the SNMP message 84 protocol is called SNMPv1 and described in RFC 1157 [8]. 85 A second version of the SNMP message protocol, which is 86 not an Internet standards track protocol, is called 87 SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. 88 The third version of the message protocol is called 89 SNMPv3 and described in RFC 1906 [10], RFC 2272 [11] and 90 RFC 2274 [12]. 92 0 Protocol operations for accessing management information. 93 The first set of protocol operations and associated PDU 94 formats is described in RFC 1157 [8]. A second set of 95 protocol operations and associated PDU formats is 96 described in RFC 1905 [13]. 98 0 A set of fundamental applications described in RFC 2273 99 [14] and the view-based access control mechanism 100 described in RFC 2275 [15]. 102 Managed objects are accessed via a virtual information store, 103 termed the Management Information Base or MIB. Objects in the 104 MIB are defined using the mechanisms defined in the SMI. 106 This memo specifies a MIB module that is compliant to the 107 SMIv2. A MIB conforming to the SMIv1 can be produced through 108 the appropriate translations. The resulting translated MIB 109 must be semantically equivalent, except where objects or 110 events are omitted because no translation is possible (e.g., 111 use of Counter64). Some machine readable information in SMIv2 112 will be converted into textual descriptions in SMIv1 during 113 the translation process. However, this loss of machine 114 readable information is not considered to change the semantics 115 of the MIB. 117 4. Experience with the Interfaces Test Group 119 The ifTestGroup of objects defined in RFC2233 has not been 120 used widely. Some cited problems were: 122 0 Few standard tests had been defined to date. 124 0 Some well known tests had already been written on a 125 media-specific basis, e.g., DS1 loopback. The 126 ifTestGroup allowed for interface testing only. 128 0 A logging capability was missing. 130 As a result, the ifTestGroup and associated ifTestTable have 131 been deprecated. However, since renewed interest was expressed 132 in a generic testing capability, specifically in the 133 development of MIBs for managing Asynchronous Transfer Mode 134 interfaces, a set of requirements have been defined that form 135 the basis for the design of the generic Test MIB defined in 136 this memo. 138 5. Requirements for a Generic Test MIB 140 This section describes the requirements that have been 141 identified for a generic test MIB. 143 5.1. Test Identification 145 The system defined in RFC2233 to identify tests relies on 146 OBJECT IDENTIFIERs. This system is flexible in that it allows 147 additional tests to be defined over time and autonomously by 148 vendors, removing the need to register test types in a single 149 place. This mechanism for test identification has been 150 retained. 152 5.2. Test Targets 154 With the advent of an increasing number of non-interface 155 related MIB modules it is desirable to define a test 156 capability that allows testing of interfaces and non-interface 157 physical entities. The following possibilities were 158 considered: 160 a) Separate test capabilities for interface tests and other 161 tests. 163 b) The use of a single test capability where the test target 164 would be defined within the test table. 166 This memo uses the latter approach and uses an object with the 167 syntax RowPointer to identify test targets. (Initially, the 168 use of the Entity MIB[17] was considered for identification of 169 test targets, but this was abandoned because this would 170 require support of the Entity MIB for testing purposes.) 172 Tests are listed in the testTable. The entries in the 173 testTable are distinguished through the value of a simple 174 integer called testIndex. 176 5.3. Logging Results 178 A logging capability of test results serves to store the test 179 results for some period of time. Two mechanisms were 180 considered: 182 1) Separate the test capability and the log. 184 2) Combine the test capability and the log in a single 185 table. 187 The log length is necessarily limited. The following choices 188 were considered: 190 1) Age the entries. 192 2) Limit by the number of entries. 194 3) A system that allows either 1) or 2). 196 For efficiency reasons this MIB module chooses a system where 197 the test and logging capability have been combined in a single 198 table (testTable). The log length is limited by a read-write 199 object (testTableMaxSize). 201 This MIB module also defines a notification, testComplete, 202 which contains the same information as the log entry. 203 Therefore, an agent with limited resources can limit the 204 maximum size of the log to a very few number of entries and 205 rely on a management application to receive and log the 206 testComplete notifications. 208 5.4. Log Searching 210 Efficient searching in a log is a key to its effectiveness. 211 The following possibilities were considered: 213 a) Sort on age of the entries. 215 b) Sort on test type. 217 c) Sort on combinations of the above. 219 This MIB module chooses for the index testIndex, which is an 220 integer identifier for an invocation of a test. To obtain a 221 new testIndex a manager retrieves the value of testIndexNext. 222 Each time this object is read the next lower available value 223 is provided. This addresses the requests that are expected to 224 be most common: 226 0 What is the result of test (testIndex)? 228 0 What are the results of the last n tests? 230 Since the testIndex has been defined as decreasing, this 231 approach will order log entries by time, newest to oldest. The 232 possibility of testId wrapping is minimized by having it 233 restart at its maximum value and when the agent restarts. When 234 a manager is interested in a specific test, a specific get- 235 request may be issued. When a manager is interested in the 236 latest n tests for the system, getnext/bulk starting from 237 (testIndex) provides the approximate answer. 239 5.5. Determining Agent Test Capabilities 241 A testCapabilityTable has been defined to list the tests that 242 can be performed through this agent. 244 6. Definitions 246 TEST-MIB DEFINITIONS ::= BEGIN 248 IMPORTS 249 MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, 250 zeroDotZero, NOTIFICATION-TYPE, mib-2 251 FROM SNMPv2-SMI 252 AutonomousType, RowPointer, TimeStamp, RowStatus 253 FROM SNMPv2-TC 254 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 255 FROM SNMPv2-CONF 256 OwnerString 257 FROM IF-MIB 258 ; 260 testMIB MODULE-IDENTITY 261 LAST-UPDATED "9904071200Z" 262 ORGANIZATION "IETF IFMIB Working Group" 263 CONTACT-INFO 264 "Maria Greene 265 Postal: Xedia Corp. 266 119 Russell St. 267 Littleton, MA 01460 268 USA 269 Tel: +1 978 897 1828 270 E-mail: maria@xedia.com 272 Keith McCloghrie 273 Postal: Cisco Systems 274 170 West Tasman Drive 275 San Jose, CA 95134 276 USA 277 Tel: +1 408 526 5260 278 E-mail: kzm@cisco.com 280 Kaj Tesink 281 Postal: Telcordia Technologies 282 331 Newman Springs Road 283 Red Bank, NJ 07701 284 USA 285 Tel: +1 732 758 5254 286 E-mail: kaj@research.telcordia.com" 287 DESCRIPTION 288 "This MIB module provides a generic test 289 capability." 290 ::= { mib-2 YY } 292 -- ******** NOTE TO THE RFC EDITOR AND IANA ********* 293 -- * In case this module is put on the standards track 294 -- * assign a suitable value to YY by IANA 295 -- * and remove this notice from the MIB 297 testMIBObjects OBJECT IDENTIFIER ::= { testMIB 1 } 299 testIndexNext OBJECT-TYPE 300 SYNTAX Unsigned32 301 MAX-ACCESS read-only 302 STATUS current 303 DESCRIPTION 304 "This object contains an appropriate value to 305 be used for testIndex when creating 306 entries in the testTable. The object is used in 307 order to minimize collisions caused by multiple 308 managers. 309 The value 0 indicates that no unassigned entries 310 are available. To obtain the testIndex 311 value for a new entry, the manager issues a 312 management protocol retrieval operation to obtain 313 the current value of this object. After each 314 retrieval, the agent should modify the value to 315 the next lower unassigned index. If the agent is 316 restarted this object shall be set to its highest 317 value. 318 The agent does not require that retrieved values 319 are actually used in subsequent tests or that 320 they are used in the order of their retrieval. 321 Note that GETNEXT or GETBULK requests for this 322 object will also decrease the value, and so it 323 is quite possible that (large) gaps will occur." 324 ::= { testMIBObjects 1 } 326 -- The Test Table 328 testTable OBJECT-TYPE 329 SYNTAX SEQUENCE OF TestEntry 330 MAX-ACCESS not-accessible 331 STATUS current 332 DESCRIPTION 333 "This table is used to initiate tests and to log 334 test results. 335 An entry in this table corresponds to an instance 336 of a test. A test is invoked by creating a row with 337 the appropriate test attributes and using 338 testRowStatus to start a test. After invoking a test, 339 the object testResult can be read to determine the 340 outcome. If an agent can not perform the test, 341 testResult is set accordingly. The testCode can 342 be used to provide further test-specific or entity- 343 specific (or even enterprise-specific) information 344 concerning the outcome of the test. Only one test 345 can be in progress on each entity at any one time. 346 If one test is in progress when another test is 347 invoked, the second test is rejected (for an 348 SNMPv2 SET operation an inconsistentValue error 349 is returned). Some agents may reject a test when 350 a prior test is active on another entity. 352 Before starting a test, a manager-station must first 353 obtain 'ownership' of the entry in the testTable for 354 the entity to be tested. This is accomplished by 355 retrieving the value of testIndexNext. This value 356 entitles the manager to create a row in the 357 testTable with the value of testIndex being equal to 358 the retrieved value of testIndexNext and testOwner 359 set to the appropriate value for the manager. 361 Once 'ownership' is obtained, the testOwner and test 362 parameters can be setup, by creating a row with the 363 reserved testIndex and appropriate test parameter 364 settings. Then the test is initiated by setting the 365 testRowStatus to 'active'. The agent sets the value of 366 testResult to 'inProgress'. 367 On completion of the test, the agent sets testResult 368 and testCode in accordance with the test results and 369 sets the testResultTimeStamp. 371 In general, a management station must not retransmit a 372 request to invoke a test for which it does not receive a 373 response; instead, it properly inspects an agent's MIB 374 to determine if the invocation was successful. Only if 375 the invocation was unsuccessful, is the invocation 376 request retransmitted. 378 Some tests may require the entity to be taken off- line 379 in order to execute them, or may even require the agent 380 to reboot after completion of the test. In these 381 circumstances, communication with the management station 382 invoking the test may be lost until after completion of 383 the test. An agent is not required to support such 384 tests. However, if such tests are supported, then the 385 agent should make every effort to transmit a response to 386 the request which invoked the test prior to losing 387 communication. When the agent is restored to normal 388 service, the results of the test are properly made 389 available in the appropriate objects. Note that this 390 requires that the testIndex value assigned to an entity 391 must be unchanged even if the test causes a reboot. An 392 agent must reject any test for which it cannot, perhaps 393 due to resource constraints, make available at least the 394 minimum amount of information after that test 395 completes. 397 Managers are responsible for removing rows that are no 398 longer in use. 399 The table is flushed when the agent is reset." 400 ::= { testMIBObjects 2 } 402 testEntry OBJECT-TYPE 403 SYNTAX TestEntry 404 MAX-ACCESS not-accessible 405 STATUS current 406 DESCRIPTION 407 "An entry containing objects for invoking a test and 408 reporting test results." 409 INDEX { testIndex } 410 ::= { testTable 1 } 412 TestEntry ::= 413 SEQUENCE { 414 testIndex Unsigned32, 415 testTarget RowPointer, 416 testType AutonomousType, 417 testMoreInfo OCTET STRING, 418 testResultTimeStamp TimeStamp, 419 testResult INTEGER, 420 testCode OBJECT IDENTIFIER, 421 testOwner OwnerString, 422 testRowStatus RowStatus } 424 testIndex OBJECT-TYPE 425 SYNTAX Unsigned32 (1..4294967295) 426 MAX-ACCESS not-accessible 427 STATUS current 428 DESCRIPTION 429 "The index of this table." 430 ::= { testEntry 1 } 432 testTarget OBJECT-TYPE 433 SYNTAX RowPointer 434 MAX-ACCESS read-create 435 STATUS current 436 DESCRIPTION 437 "The target of the test. An example of a test target 438 is an instance of an interface, identified by the 439 OID 'ifIndex.17'. 440 When the value zeroDotZero is written to this object, 441 no action is taken. " 442 DEFVAL { zeroDotZero } 443 ::= { testEntry 2 } 445 testType OBJECT-TYPE 446 SYNTAX AutonomousType 447 MAX-ACCESS read-create 448 STATUS current 449 DESCRIPTION 450 "The identifier that specifies the test. 451 OBJECT IDENTIFIER values assigned to tests 452 are defined elsewhere, in association with 453 specific types of entity. 454 When the value 'zeroDotZero' is written to this 455 object, no action is taken. 456 Additional information for this test may be 457 specified in testMoreInfo. The value of 458 testType must be one of those listed in the 459 testCapabilityTable." 460 DEFVAL { zeroDotZero } 461 ::= { testEntry 3 } 463 testMoreInfo OBJECT-TYPE 464 SYNTAX OCTET STRING 465 MAX-ACCESS read-create 466 STATUS current 467 DESCRIPTION 468 "Additional test-specific information." 469 DEFVAL { "" } 470 ::= { testEntry 4 } 472 testResultTimeStamp OBJECT-TYPE 473 SYNTAX TimeStamp 474 MAX-ACCESS read-only 475 STATUS current 476 DESCRIPTION 477 "The value of sysUpTime when a testResult has 478 been reached. 479 When a test is 'inProgress' the value of 480 testResultTimeStamp shall be 0." 481 ::= { testEntry 5 } 483 testResult OBJECT-TYPE 484 SYNTAX INTEGER { 485 none(1), -- no test yet requested 486 success(2), 487 inProgress(3), -- transient state 488 notSupported(4),-- not in testCapabilityTable 489 unAbleToRun(5), -- due to state of system 490 aborted(6), -- by manager action 491 failed(7) 492 } 493 MAX-ACCESS read-only 494 STATUS current 495 DESCRIPTION 496 "This object contains the result of the most recently 497 requested test, or the value 'none' if no test 498 has been started yet." 499 DEFVAL { none } 500 ::= { testEntry 6 } 502 testCode OBJECT-TYPE 503 SYNTAX OBJECT IDENTIFIER 504 MAX-ACCESS read-only 505 STATUS current 506 DESCRIPTION 507 "This object contains a code which contains more specific 508 information on the test result, for example an error-code 509 after a failed test or a result value such as round trip 510 time for a 'ping' test. Error codes and other values this 511 object may take are specific to the type of entity and/or 512 test. The value may have the semantics of AutonomousType, 513 RowPointer or VariablePointer textual conventions as 514 defined in RFC 1903. The identifier: 516 testCodeNone OBJECT IDENTIFIER ::= zeroDotZero 518 is defined for use if no additional result code is 519 available." 520 ::= { testEntry 7 } 522 testOwner OBJECT-TYPE 523 SYNTAX OwnerString 524 MAX-ACCESS read-create 525 STATUS current 526 DESCRIPTION 527 "The manager which currently has the 'ownership' 528 required to invoke a test on this entity, e.g., 529 the manager station's transport address, 530 management station name (e.g., domain name), 531 network management personnel's name, location, 532 or phone number." 533 REFERENCE 534 "McCloghrie, K., Kastenholz, F., The Interfaces 535 Group MIB using SMIv2, RFC2233, Cisco Systems, 536 Inc., FTP Software, November 1997." 537 ::= { testEntry 8 } 539 testRowStatus OBJECT-TYPE 540 SYNTAX RowStatus 541 MAX-ACCESS read-create 542 STATUS current 543 DESCRIPTION 544 "The row status of the test information. 545 A row must be active before tests can be 546 activiated. Deactivating a row will abort any 547 ongoing test associated with that row. 548 Manipulation of the test: 549 - When all test parameters (testTarget, testType, 550 testMoreInfo and testOwner) have been properly 551 set the test is started by setting testRowStatus 552 to 'active'. This causes the testResult 553 to assume the value 'inProgress' until some other 554 value of testResult is reached. 556 - If the manager sets testRowStatus to 'active' 557 while the test is inProgress then this action 558 will not affect the ongoing test. 559 - Details of ongoing or completed tests are 560 reported in testResult and testCode. 561 - After test completion the test may be repeated 562 by first setting testRowStatus to 'notInService', 563 manipulating the test parameters as necessary, and 564 setting the testRowStatus to 'active' again. 565 - A manager may abort ongoing tests or remove 566 completed test information by setting the 567 testRowStatus to 'notInService' or 'destroy'." 568 DEFVAL { createAndWait } 569 ::= { testEntry 9 } 571 -- Table size 573 testTableMaxSize OBJECT-TYPE 574 SYNTAX Unsigned32 (10..4294967295) 575 MAX-ACCESS read-write 576 STATUS current 577 DESCRIPTION 578 "The maximum number entries in the testTable. 579 Removal of old entries is the responsibility of 580 the manager. 581 The table is flushed when the agent is reset." 582 ::= { testMIBObjects 3 } 584 -- Test Capability Table 586 testCapabilityTable OBJECT-TYPE 587 SYNTAX SEQUENCE OF TestCapabilityEntry 588 MAX-ACCESS not-accessible 589 STATUS current 590 DESCRIPTION 591 "This table contains test types (potential 592 values for the testType object) that are 593 supported by this agent." 594 ::= { testMIBObjects 4 } 596 testCapabilityEntry OBJECT-TYPE 597 SYNTAX TestCapabilityEntry 598 MAX-ACCESS not-accessible 599 STATUS current 600 DESCRIPTION 601 "Each entry in this table represents a test type." 602 INDEX { testCapabilityIndex } 603 ::= { testCapabilityTable 1 } 605 TestCapabilityEntry ::= 606 SEQUENCE { 607 testCapabilityIndex Unsigned32, 608 testCapabilityType AutonomousType 609 } 611 testCapabilityIndex OBJECT-TYPE 612 SYNTAX Unsigned32 613 MAX-ACCESS not-accessible 614 STATUS current 615 DESCRIPTION 616 "An integer index that uniquely identifies the entry." 617 ::= { testCapabilityEntry 1 } 619 testCapabilityType OBJECT-TYPE 620 SYNTAX AutonomousType 621 MAX-ACCESS read-only 622 STATUS current 623 DESCRIPTION 624 "The type of test that can be invoked." 625 ::= { testCapabilityEntry 2 } 627 -- Notifications 629 testMIBNotifications OBJECT IDENTIFIER ::= { testMIB 0 } 631 testComplete NOTIFICATION-TYPE 632 OBJECTS { 633 testTarget, 634 testType, 635 testMoreInfo, 636 testResult, 637 testCode, 638 testOwner } 639 STATUS current 640 DESCRIPTION 641 "A testComplete trap signifies that a test has completed for 642 a particular entity. If the testCode has the semantics of 643 a VariablePointer, the variable it points at will also be 644 included in the objects list." 645 ::= { testMIBNotifications 1 } 647 -- Conformance Information 649 testMIBConformance OBJECT IDENTIFIER ::= { testMIB 3 } 651 testMIBGroups OBJECT IDENTIFIER 652 ::= { testMIBConformance 1 } 654 testMIBCompliances OBJECT IDENTIFIER 655 ::= { testMIBConformance 2 } 657 -- Compliance Statements 659 testMIBCompliance MODULE-COMPLIANCE 660 STATUS current 661 DESCRIPTION 662 "The compliance statement for SNMP agents which support 663 generic testing capabilities." 665 MODULE -- this module 667 MANDATORY-GROUPS { testMIBGroup, testNotificationGroup } 669 OBJECT testTableMaxSize 670 MIN-ACCESS read-only 671 DESCRIPTION 672 "Write access is not required." 674 ::= { testMIBCompliances 1 } 676 -- Units of Conformance 678 testMIBGroup OBJECT-GROUP 679 OBJECTS { 680 testIndexNext, 681 testTarget, 682 testType, 683 testMoreInfo, 684 testResultTimeStamp, 685 testResult, 686 testCode, 687 testOwner, 688 testRowStatus, 689 testTableMaxSize, 690 testCapabilityType 691 } 692 STATUS current 693 DESCRIPTION 694 "A collection of objects providing a generic 695 test capability." 696 ::= { testMIBGroups 1 } 698 testNotificationGroup NOTIFICATION-GROUP 699 NOTIFICATIONS { 700 testComplete 701 } 702 STATUS current 703 DESCRIPTION 704 "The notifications used to indicate test completion." 705 ::= { testMIBGroups 2 } 707 END 708 7. Acknowledgments 710 This document is a product of the IETF's Interfaces MIB 711 Working Group. 713 The original ifTestTable was the work of Keith McCloghrie 714 (Cisco) and Frank Kastenholz (FTP Software) and has been used 715 in this further evolution. 717 The authors would like to acknowledge the following 718 individuals for their input on requirements: 720 James Watt (Newbridge) 721 Dave Fowler (Newbridge) 722 Steven Buchko (Newbridge) 723 Milt Rosslinsky (ACC) 724 Dawn Xie (Lucent) 725 Chris Martin (Netedge) 726 Harmen van der Linde (Bellcore) 728 8. References 730 [1] Harrington, D., Presuhn, R., and B. Wijnen, "An 731 Architecture for Describing SNMP Management Frameworks", 732 RFC 2271, Cabletron Systems, Inc., BMC Software, Inc., 733 IBM T. J. Watson Research, January 1998 735 [2] Rose, M., and K. McCloghrie, "Structure and 736 Identification of Management Information for TCP/IP-based 737 Internets", RFC 1155, Performance Systems International, 738 Hughes LAN Systems, May 1990 740 [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", 741 RFC 1212, Performance Systems International, Hughes LAN 742 Systems, March 1991 744 [4] M. Rose, "A Convention for Defining Traps for use with 745 the SNMP", RFC 1215, Performance Systems International, 746 March 1991 748 [5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., 749 and S. Waldbusser, "Structure of Management Information 750 for Version 2 of the Simple Network Management Protocol 751 (SNMPv2)", RFC 1902, SNMP Research,Inc., Cisco Systems, 752 Inc., Dover Beach Consulting, Inc., International Network 753 Services, January 1996. 755 [6] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., 756 and S. Waldbusser, "Textual Conventions for Version 2 of 757 the Simple Network Management Protocol (SNMPv2)", RFC 758 1903, SNMP Research, Inc., Cisco Systems, Inc., Dover 759 Beach Consulting, Inc., International Network Services, 760 January 1996. 762 [7] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., 763 and S. Waldbusser, "Conformance Statements for Version 2 764 of the Simple Network Management Protocol (SNMPv2)", RFC 765 1904, SNMP Research, Inc., Cisco Systems, Inc., Dover 766 Beach Consulting, Inc., International Network Services, 767 January 1996. 769 [8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 770 "Simple Network Management Protocol", RFC 1157, SNMP 771 Research, Performance Systems International, Performance 772 Systems International, MIT Laboratory for Computer 773 Science, May 1990. 775 [9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., 776 and S. Waldbusser, "Introduction to Community-based 777 SNMPv2", RFC 1901, SNMP Research, Inc., Cisco Systems, 778 Inc., Dover Beach Consulting, Inc., International Network 779 Services, January 1996. 781 [10] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., 782 and S. Waldbusser, "Transport Mappings for Version 2 of 783 the Simple Network Management Protocol (SNMPv2)", RFC 784 1906, SNMP Research, Inc., Cisco Systems, Inc., Dover 785 Beach Consulting, Inc., International Network Services, 786 January 1996. 788 [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, 789 "Message Processing and Dispatching for the Simple 790 Network Management Protocol (SNMP)", RFC 2272, SNMP 791 Research, Inc., Cabletron Systems, Inc., BMC Software, 792 Inc., IBM T. J. Watson Research, January 1998. 794 [12] Blumenthal, U., and B. Wijnen, "User-based Security Model 795 (USM) for version 3 of the Simple Network Management 796 Protocol (SNMPv3)", RFC 2274, IBM T. J. Watson Research, 797 January 1998. 799 [13] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., 800 and S. Waldbusser, "Protocol Operations for Version 2 of 801 the Simple Network Management Protocol (SNMPv2)", RFC 802 1905, SNMP Research, Inc., Cisco Systems, Inc., Dover 803 Beach Consulting, Inc., International Network Services, 804 January 1996. 806 [14] Levi, D., Meyer, P., and B. Stewart, SNMPv3 807 Applications", RFC 2273, SNMP Research, Inc., Secure 808 Computing Corporation, Cisco Systems, January 1998. 810 [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 811 Access Control Model (VACM) for the Simple Network 812 Management Protocol (SNMP)", RFC 2275, IBM T. J. Watson 813 Research, BMC Software, Inc., Cisco Systems, Inc., 814 January 1998. 816 [16] McCloghrie, K., Kastenholz, F., " The Interfaces Group 817 MIB using SMIv2", RFC2233, Cisco Systems, Inc., FTP 818 Software, November 1997. 820 [17] McCloghrie, K., and A. Bierman, Editors, "Entity MIB", 821 RFC2037, Cisco Systems, January 1996. 823 9. Security Considerations 825 There are a number of management objects defined in this MIB 826 that have a MAX-ACCESS clause of read-write and/or read- 827 create. Such objects may be considered sensitive or 828 vulnerable in some network environments. The support for SET 829 operations in a non-secure environment without proper 830 protection can have a negative effect on network operations. 832 The managed objects in this MIB contain sensitive information 833 since, collectively, they allow the invocation of tests on the 834 managed device. These tests may have consequences such as 835 configuration changes, service interruptions, etc. Security 836 considerations for individual tests are discussed in the 837 documents defining such tests. 839 It is thus important to control even GET access to these 840 objects and possibly to even encrypt the values of these 841 object when sending them over the network via SNMP. Not all 842 versions of SNMP provide features for such a secure 843 environment. 845 SNMPv1 by itself is not a secure environment. Even if the 846 network itself is secure (for example by using IPSec), even 847 then, there is no control as to who on the secure network is 848 allowed to access and GET/SET (read/change/create/delete) the 849 objects in this MIB. 851 It is recommended that the implementers consider the security 852 features as provided by the SNMPv3 framework. Specifically, 853 the use of the User-based Security Model RFC 2274 [12] and the 854 View-based Access Control Model RFC 2275 [15] is recommended. 856 It is then a customer/user responsibility to ensure that the 857 SNMP entity giving access to an instance of this MIB, is 858 properly configured to give access to the objects only to 859 those principals (users) that have legitimate rights to indeed 860 GET or SET (change/create/delete) them. 862 10. Authors' Addresses 864 Maria Greene 865 Xedia Corp. 866 19 Russell St. 867 Littleton, MA 01460 868 USA 869 Phone: (978) 897-1828 870 Email: maria@xedia.com 872 Keith McCloghrie 873 Cisco Systems 874 170 West Tasman Drive 875 San Jose, CA 95134 876 Phone: (408) 526-5260 877 Email: kzm@cisco.com 879 Kaj Tesink 880 Telcordia Technologies 881 331 Newman Springs Road 882 P.O. Box 7020 883 Red Bank, NJ 07701-7020 884 Phone: (732) 758-5254 885 Email: kaj@research.telcordia.com 887 11. RFC Editor and IANA Considerations 889 Prior to publication of this memo as an RFC, the RFC Editor 890 and IANA are requested to make a suitable OBJECT IDENTIFIER 891 assignment for YY below and update the following in the MIB: 893 ::= { mib-2 YY } 895 -- ******** NOTE TO THE RFC EDITOR AND IANA ********* 896 -- * In case this module is put on the standards track 897 -- * assign a suitable value to YY by IANA 898 -- * and remove this notice from the MIB 900 12. Intellectual Property 902 The IETF takes no position regarding the validity or scope of 903 any intellectual property or other rights that might be 904 claimed to pertain to the implementation or use of the 905 technology described in this document or the extent to which 906 any license under such rights might or might not be available; 907 neither does it represent that it has made any effort to 908 identify any such rights. Information on the IETF's 909 procedures with respect to rights in standards-track and 910 standards-related documentation can be found in BCP-11. 911 Copies of claims of rights made available for publication and 912 any assurances of licenses to be made available, or the result 913 of an attempt made to obtain a general license or permission 914 for the use of such proprietary rights by implementors or 915 users of this specification can be obtained from the IETF 916 Secretariat. 918 The IETF invites any interested party to bring to its 919 attention any copyrights, patents or patent applications, or 920 other proprietary rights which may cover technology that may 921 be required to practice this standard. Please address the 922 information to the IETF Executive Director. 924 13. Full Copyright Statement 926 Copyright (C) The Internet Society (1998). All Rights 927 Reserved. 929 This document and translations of it may be copied and 930 furnished to others, and derivative works that comment on or 931 otherwise explain it or assist in its implementation may be 932 prepared, copied, published and distributed, in whole or in 933 part, without restriction of any kind, provided that the above 934 copyright notice and this paragraph are included on all such 935 copies and derivative works. However, this document itself 936 may not be modified in any way, such as by removing the 937 copyright notice or references to the Internet Society or 938 other Internet organizations, except as needed for the purpose 939 of developing Internet standards in which case the procedures 940 for copyrights defined in the Internet Standards process must 941 be followed, or as required to translate it into languages 942 other than English. 944 The limited permissions granted above are perpetual and will 945 not be revoked by the Internet Society or its successors or 946 assigns. 948 This document and the information contained herein is provided 949 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 950 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 951 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 952 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 953 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 954 PARTICULAR PURPOSE." 955 Table of Contents 957 1 Status of this Memo ................................... 1 958 2 Abstract .............................................. 2 959 3 The SNMP Network Management Framework ................. 3 960 4 Experience with the Interfaces Test Group ............. 5 961 5 Requirements for a Generic Test MIB ................... 5 962 5.1 Test Identification ................................. 5 963 5.2 Test Targets ........................................ 6 964 5.3 Logging Results ..................................... 6 965 5.4 Log Searching ....................................... 7 966 5.5 Determining Agent Test Capabilities ................. 8 967 6 Definitions ........................................... 9 968 7 Acknowledgments ....................................... 20 969 8 References ............................................ 21 970 9 Security Considerations ............................... 24 971 10 Authors' Addresses ................................... 25 972 11 RFC Editor and IANA Considerations ................... 25 973 12 Intellectual Property ................................ 26 974 13 Full Copyright Statement ............................. 27