idnits 2.17.1 draft-ietf-ifmib-testmib-06.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 == 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: ' 7. 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 ([RFC2573], [RFC1906], [RFC1155], [RFC2233], [RFC2574], [RFC2575], [RFC1157], [RFC2580], [RFC2578], [RFC1212], [RFC2579], [RFC1901], [RFC1215], [RFC2037], [RFC2570], [RFC2571], [RFC1905], [RFC2572]), 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 (November 28, 1999) is 8916 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? 'RFC2233' on line 793 looks like a reference -- Missing reference section? 'RFC2571' on line 797 looks like a reference -- Missing reference section? 'RFC1155' on line 801 looks like a reference -- Missing reference section? 'RFC1212' on line 806 looks like a reference -- Missing reference section? 'RFC1215' on line 809 looks like a reference -- Missing reference section? 'RFC2578' on line 812 looks like a reference -- Missing reference section? 'RFC2579' on line 817 looks like a reference -- Missing reference section? 'RFC2580' on line 822 looks like a reference -- Missing reference section? 'RFC1157' on line 827 looks like a reference -- Missing reference section? 'RFC1901' on line 831 looks like a reference -- Missing reference section? 'RFC1906' on line 835 looks like a reference -- Missing reference section? 'RFC2572' on line 840 looks like a reference -- Missing reference section? 'RFC2574' on line 845 looks like a reference -- Missing reference section? 'RFC1905' on line 850 looks like a reference -- Missing reference section? 'RFC2573' on line 855 looks like a reference -- Missing reference section? 'RFC2575' on line 858 looks like a reference -- Missing reference section? 'RFC2570' on line 863 looks like a reference -- Missing reference section? 'RFC2037' on line 868 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT System/Interface Test MIB November 28, 1999 3 Definitions of Managed Objects for 4 System and Interface Testing 6 November 28, 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 (1999). 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[RFC2233] which have been deprecated. 68 3. The SNMP Management Framework 70 The SNMP Management Framework presently consists of five major 71 components: 73 o An overall architecture, described in RFC 2571 74 [RFC2571]. 76 o Mechanisms for describing and naming objects and 77 events for the purpose of management. The first 78 version of this Structure of Management Information 79 (SMI) is called SMIv1 and described in STD 16, RFC 80 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 81 1215 [RFC1215]. The second version, called SMIv2, is 82 described in STD 58, RFC 2578 [RFC2578], RFC 2579 83 [RFC2579] and RFC 2580 [RFC2580]. 85 o Message protocols for transferring management 86 information. The first version of the SNMP message 87 protocol is called SNMPv1 and described in STD 15, RFC 88 1157 [RFC1157]. A second version of the SNMP message 89 protocol, which is not an Internet standards track 90 protocol, is called SNMPv2c and described in RFC 1901 91 [RFC1901] and RFC 1906 [RFC1906]. The third version of 92 the message protocol is called SNMPv3 and described in 93 RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 94 [RFC2574]. 96 o Protocol operations for accessing management 97 information. The first set of protocol operations and 98 associated PDU formats is described in STD 15, RFC 99 1157 [RFC1157]. A second set of protocol operations 100 and associated PDU formats is described in RFC 1905 101 [RFC1905]. 103 o A set of fundamental applications described in RFC 104 2573 [RFC2573] and the view-based access control 105 mechanism described in RFC 2575 [RFC2575]. 107 A more detailed introduction to the current SNMP 108 Management Framework can be found in RFC 2570 109 [RFC2570]. 111 Managed objects are accessed via a virtual information 112 store, termed the Management Information Base or MIB. 114 Objects in the MIB are defined using the mechanisms 115 defined in the SMI. 117 This memo specifies a MIB module that is compliant to 118 the SMIv2. A MIB conforming to the SMIv1 can be 119 produced through the appropriate translations. The 120 resulting translated MIB must be semantically 121 equivalent, except where objects or events are omitted 122 because no translation is possible (use of Counter64). 123 Some machine readable information in SMIv2 will be 124 converted into textual descriptions in SMIv1 during 125 the translation process. However, this loss of machine 126 readable information is not considered to change the 127 semantics of the MIB. 129 4. Experience with the Interfaces Test Group 131 The ifTestGroup of objects defined in RFC2233 has not been 132 used widely. Some cited problems were: 134 0 Few standard tests had been defined to date. 136 0 Some well known tests had already been written on a 137 media-specific basis, e.g., DS1 loopback. The 138 ifTestGroup allowed for interface testing only. 140 0 A logging capability was missing. 142 As a result, the ifTestGroup and associated ifTestTable have 143 been deprecated. However, since renewed interest was expressed 144 in a generic testing capability, specifically in the 145 development of MIBs for managing Asynchronous Transfer Mode 146 interfaces, a set of requirements have been defined that form 147 the basis for the design of the generic Test MIB defined in 148 this memo. 150 5. Requirements for a Generic Test MIB 152 This section describes the requirements that have been 153 identified for a generic test MIB. 155 5.1. Test Identification 157 The system defined in RFC2233 to identify tests relies on 158 OBJECT IDENTIFIERs. This system is flexible in that it allows 159 additional tests to be defined over time and autonomously by 160 vendors, removing the need to register test types in a single 161 place. This mechanism for test identification has been 162 retained. 164 5.2. Test Targets 166 With the advent of an increasing number of non-interface 167 related MIB modules it is desirable to define a test 168 capability that allows testing of interfaces and non-interface 169 physical entities. The following possibilities were 170 considered: 172 a) Separate test capabilities for interface tests and other 173 tests. 175 b) The use of a single test capability where the test target 176 would be defined within the test table. 178 This memo uses the latter approach and uses an object with the 179 syntax RowPointer to identify test targets. (Initially, the 180 use of the Entity MIB[RFC2037] was considered for 181 identification of test targets, but this was abandoned because 182 this would require support of the Entity MIB for testing 183 purposes.) 185 Tests are listed in the testTable. The entries in the 186 testTable are distinguished through the value of a simple 187 integer called testIndex. 189 5.3. Logging Results 191 A logging capability of test results serves to store the test 192 results for some period of time. Two mechanisms were 193 considered: 195 1) Separate the test capability and the log. 197 2) Combine the test capability and the log in a single 198 table. 200 The log length is necessarily limited. The following choices 201 were considered: 203 1) Age the entries. 205 2) Limit by the number of entries. 207 3) A system that allows either 1) or 2). 209 For efficiency reasons this MIB module chooses a system where 210 the test and logging capability have been combined in a single 211 table (testTable). The log length is limited by a read-write 212 object (testTableMaxSize). 214 This MIB module also defines a notification, testComplete, 215 which contains the same information as the log entry. 216 Therefore, an agent with limited resources can limit the 217 maximum size of the log to a very few number of entries and 218 rely on a management application to receive and log the 219 testComplete notifications. 221 5.4. Log Searching 223 Efficient searching in a log is a key to its effectiveness. 224 The following possibilities were considered: 226 a) Sort on age of the entries. 228 b) Sort on test type. 230 c) Sort on combinations of the above. 232 This MIB module chooses for the index testIndex, which is an 233 integer identifier for an invocation of a test. To obtain a 234 new testIndex a manager retrieves the value of testIndexNext. 235 Each time this object is read the next lower available value 236 is provided. This addresses the requests that are expected to 237 be most common: 239 0 What is the result of test (testIndex)? 241 0 What are the results of the last n tests? 243 Since the testIndex has been defined as decreasing, this 244 approach will order log entries by time, newest to oldest. The 245 possibility of testId wrapping is minimized by having it 246 restart at its maximum value and when the agent restarts. When 247 a manager is interested in a specific test, a specific get- 248 request may be issued. When a manager is interested in the 249 latest n tests for the system, getnext/bulk starting from 250 (testIndex) provides the approximate answer. 252 5.5. Determining Agent Test Capabilities 254 A testCapabilityTable has been defined to list the tests that 255 can be performed through this agent. 257 6. Definitions 259 TEST-MIB DEFINITIONS ::= BEGIN 261 IMPORTS 262 MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, 263 zeroDotZero, NOTIFICATION-TYPE, mib-2 264 FROM SNMPv2-SMI 265 AutonomousType, RowPointer, TimeStamp, RowStatus 266 FROM SNMPv2-TC 267 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 268 FROM SNMPv2-CONF 269 SnmpAdminString 270 FROM SNMP-FRAMEWORK-MIB 271 ; 273 testMIB MODULE-IDENTITY 274 LAST-UPDATED "9911281200Z" 275 ORGANIZATION "IETF IFMIB Working Group" 276 CONTACT-INFO 277 "Maria Greene 278 Postal: Xedia Corp. 279 119 Russell St. 280 Littleton, MA 01460 281 USA 282 Tel: +1 978 897 1828 283 E-mail: maria@xedia.com 285 Keith McCloghrie 286 Postal: Cisco Systems 287 170 West Tasman Drive 288 San Jose, CA 95134 289 USA 290 Tel: +1 408 526 5260 291 E-mail: kzm@cisco.com 293 Kaj Tesink 294 Postal: Telcordia Technologies 295 331 Newman Springs Road 296 Red Bank, NJ 07701 297 USA 298 Tel: +1 732 758 5254 299 E-mail: kaj@research.telcordia.com" 300 DESCRIPTION 301 "This MIB module provides a generic test 302 capability." 303 REVISION "9911281200Z" 304 DESCRIPTION 305 "Initial version, published as RFCxxxx" 306 ::= { mib-2 YY } 308 -- ******** NOTE TO THE RFC EDITOR AND IANA ********* 309 -- * In case this module is put on the standards track 310 -- * fill out RFCxxxx with the RFC number of this document 311 -- * assign a suitable value to YY by IANA 312 -- * and remove this notice from the MIB 314 testMIBObjects OBJECT IDENTIFIER ::= { testMIB 1 } 316 testIndexNext OBJECT-TYPE 317 SYNTAX Unsigned32 318 MAX-ACCESS read-only 319 STATUS current 320 DESCRIPTION 321 "This object contains an appropriate value to 322 be used for testIndex when creating 323 entries in the testTable. The object is used in 324 order to minimize collisions caused by multiple 325 managers. 326 The value 0 indicates that no unassigned entries 327 are available. To obtain the testIndex 328 value for a new entry, the manager issues a 329 management protocol retrieval operation to obtain 330 the current value of this object. After each 331 retrieval, the agent should modify the value to 332 the next lower unassigned index. If the agent is 333 restarted this object shall be set to its highest 334 value. 335 The agent does not require that retrieved values 336 are actually used in subsequent tests or that 337 they are used in the order of their retrieval. 338 Note that GETNEXT or GETBULK requests for this 339 object will also decrease the value, and so it 340 is quite possible that (large) gaps will occur." 341 ::= { testMIBObjects 1 } 343 -- The Test Table 344 testTable OBJECT-TYPE 345 SYNTAX SEQUENCE OF TestEntry 346 MAX-ACCESS not-accessible 347 STATUS current 348 DESCRIPTION 349 "This table is used to initiate tests and to log 350 test results. 351 An entry in this table corresponds to an instance 352 of a test. A test is invoked by creating a row with 353 the appropriate test attributes and using 354 testRowStatus to start a test. After invoking a test, 355 the object testResult can be read to determine the 356 outcome. If an agent can not perform the test, 357 testResult is set accordingly. The testCode can 358 be used to provide further test-specific or entity- 359 specific (or even enterprise-specific) information 360 concerning the outcome of the test. Only one test 361 can be in progress on each entity at any one time. 362 If one test is in progress when another test is 363 invoked, the second test is rejected (e.g., for an 364 SNMPv2 SET operation an inconsistentValue error 365 is returned). Some agents may reject a test when 366 a prior test is active on another entity. 368 Before starting a test, a manager-station must first 369 obtain 'ownership' of the entry in the testTable for 370 the entity to be tested. This is accomplished by 371 retrieving the value of testIndexNext. This value 372 entitles the manager to create a row in the 373 testTable with the value of testIndex being equal to 374 the retrieved value of testIndexNext and testOwner 375 set to the appropriate value for the manager. 376 A prudent sequence to obtain 'ownership' of a 377 testTable entry and to minimize collisions (e.g., with 378 a manager not following the rules) is as follows: 379 (1) Retrieve testIndexNext; stop if no more values 380 are available 381 (2) Test whether the corresponding testTable entry 382 does exist through a retrieval operation 383 (3) If the entry exists go back to (1), else 384 (4) Once 'ownership' is obtained, the testOwner and 385 test parameters can be setup, by creating a row 386 with the reserved testIndex and appropriate test 387 parameter settings. 388 (5) Then the test is initiated by setting the 389 testRowStatus to 'active'. The agent sets the 390 value of testResult to 'inProgress'. 391 On completion of the test, the agent sets testResult 392 and testCode in accordance with the test results and 393 sets the testResultTimeStamp. 395 In general, a management station must not retransmit a 396 request to invoke a test for which it does not receive a 397 response; instead, it properly inspects an agent's MIB 398 to determine if the invocation was successful. Only if 399 the invocation was unsuccessful, is the invocation 400 request retransmitted. 402 Some tests may require the entity to be taken off- line 403 in order to execute them, or may even require the agent 404 to reboot after completion of the test. In these 405 circumstances, communication with the management station 406 invoking the test may be lost until after completion of 407 the test. An agent is not required to support such 408 tests. However, if such tests are supported, then the 409 agent should make every effort to transmit a response to 410 the request which invoked the test prior to losing 411 communication. When the agent is restored to normal 412 service, the results of the test are properly made 413 available in the appropriate objects. Note that this 414 requires that the testIndex value assigned to an entity 415 must be unchanged even if the test causes a reboot. An 416 agent must reject any test for which it cannot, perhaps 417 due to resource constraints, make available at least the 418 minimum amount of information after that test 419 completes. 421 Managers are responsible for removing rows that are no 422 longer in use. 423 The table is flushed when the agent is reset." 424 ::= { testMIBObjects 2 } 426 testEntry OBJECT-TYPE 427 SYNTAX TestEntry 428 MAX-ACCESS not-accessible 429 STATUS current 430 DESCRIPTION 431 "An entry containing objects for invoking a test and 432 reporting test results." 433 INDEX { testIndex } 434 ::= { testTable 1 } 436 TestEntry ::= 437 SEQUENCE { 438 testIndex Unsigned32, 439 testTarget RowPointer, 440 testType AutonomousType, 441 testMoreInfo OCTET STRING, 442 testResultTimeStamp TimeStamp, 443 testResult INTEGER, 444 testCode OBJECT IDENTIFIER, 445 testOwner SnmpAdminString, 446 testRowStatus RowStatus } 448 testIndex OBJECT-TYPE 449 SYNTAX Unsigned32 (1..4294967295) 450 MAX-ACCESS not-accessible 451 STATUS current 452 DESCRIPTION 453 "The index of this table." 454 ::= { testEntry 1 } 456 testTarget OBJECT-TYPE 457 SYNTAX RowPointer 458 MAX-ACCESS read-create 459 STATUS current 460 DESCRIPTION 461 "The target of the test. An example of a test target 462 is an instance of an interface, identified by the 463 OID 'ifIndex.17'. 464 When the value zeroDotZero is written to this object, 465 no action is taken. " 466 DEFVAL { zeroDotZero } 467 ::= { testEntry 2 } 469 testType OBJECT-TYPE 470 SYNTAX AutonomousType 471 MAX-ACCESS read-create 472 STATUS current 473 DESCRIPTION 474 "The identifier that specifies the test. 475 OBJECT IDENTIFIER values assigned to tests 476 are defined elsewhere, in association with 477 specific types of entity. 478 When the value 'zeroDotZero' is written to this 479 object, no action is taken. 480 Additional information for this test may be 481 specified in testMoreInfo. The value of 482 testType must be one of those listed in the 483 testCapabilityTable." 484 DEFVAL { zeroDotZero } 485 ::= { testEntry 3 } 487 testMoreInfo OBJECT-TYPE 488 SYNTAX OCTET STRING 489 MAX-ACCESS read-create 490 STATUS current 491 DESCRIPTION 492 "Additional test-specific information." 493 DEFVAL { "" } 494 ::= { testEntry 4 } 496 testResultTimeStamp OBJECT-TYPE 497 SYNTAX TimeStamp 498 MAX-ACCESS read-only 499 STATUS current 500 DESCRIPTION 501 "The value of sysUpTime when a testResult has 502 been reached. 503 When a test is 'inProgress' the value of 504 testResultTimeStamp shall be 0." 505 ::= { testEntry 5 } 507 testResult OBJECT-TYPE 508 SYNTAX INTEGER { 509 none(1), -- no test yet requested 510 success(2), 511 inProgress(3), -- transient state 512 notSupported(4),-- not in testCapabilityTable 513 unAbleToRun(5), -- due to state of system 514 aborted(6), -- by manager action 515 failed(7) 516 } 517 MAX-ACCESS read-only 518 STATUS current 519 DESCRIPTION 520 "This object contains the result of the most recently 521 requested test, or the value 'none' if no test 522 has been started yet." 523 DEFVAL { none } 524 ::= { testEntry 6 } 526 testCode OBJECT-TYPE 527 SYNTAX OBJECT IDENTIFIER 528 MAX-ACCESS read-only 529 STATUS current 530 DESCRIPTION 531 "This object contains a code which contains more specific 532 information on the test result, for example an error-code 533 after a failed test or a result value such as round trip 534 time for a 'ping' test. Error codes and other values this 535 object may take are specific to the type of entity and/or 536 test. The value may have the semantics of AutonomousType, 537 RowPointer or VariablePointer textual conventions as 538 defined in RFC 1903. The identifier: 540 testCodeNone OBJECT IDENTIFIER ::= zeroDotZero 542 is defined for use if no additional result code is 543 available." 544 ::= { testEntry 7 } 546 testOwner OBJECT-TYPE 547 SYNTAX SnmpAdminString 548 MAX-ACCESS read-create 549 STATUS current 550 DESCRIPTION 551 "The manager which currently has the 'ownership' 552 required to invoke a test on this entity, e.g., 553 the manager station's transport address, 554 management station name (e.g., domain name), 555 network management personnel's name, location, 556 or phone number." 557 REFERENCE 558 "McCloghrie, K., Kastenholz, F., The Interfaces 559 Group MIB using SMIv2, RFC2233, Cisco Systems, 560 Inc., FTP Software, November 1997." 561 ::= { testEntry 8 } 563 testRowStatus OBJECT-TYPE 564 SYNTAX RowStatus 565 MAX-ACCESS read-create 566 STATUS current 567 DESCRIPTION 568 "The row status of the test information. 569 A row must be active before tests can be 570 activiated. 571 Manipulation of the test: 572 - When all test parameters (testTarget, testType, 573 testMoreInfo and testOwner) have been properly 574 set the test is started by setting testRowStatus 575 to 'active'. This causes the testResult 576 to assume the value 'inProgress' until some other 577 value of testResult is reached. 578 - If the manager sets testRowStatus to 'active' 579 while the test is inProgress then this action 580 will not affect the ongoing test. 581 - Details of ongoing or completed tests are 582 reported in testResult and testCode. 583 - After test completion the test may be repeated 584 by first setting testRowStatus to 'notInService', 585 manipulating the test parameters as necessary, and 586 setting the testRowStatus to 'active' again. 587 - A manager may abort ongoing tests or remove 588 completed test information by setting the 589 testRowStatus to 'notInService' or 'destroy'." 590 DEFVAL { notReady } 591 ::= { testEntry 9 } 593 -- Table size 595 testTableMaxSize OBJECT-TYPE 596 SYNTAX Unsigned32 (10..4294967295) 597 MAX-ACCESS read-write 598 STATUS current 599 DESCRIPTION 600 "The maximum number entries in the testTable. 601 Removal of old entries is the responsibility of 602 the manager. 603 The table is flushed when the agent is reset." 604 ::= { testMIBObjects 3 } 606 -- Test Capability Table 608 testCapabilityTable OBJECT-TYPE 609 SYNTAX SEQUENCE OF TestCapabilityEntry 610 MAX-ACCESS not-accessible 611 STATUS current 612 DESCRIPTION 613 "This table contains test types (potential 614 values for the testType object) that are 615 supported by this agent." 616 ::= { testMIBObjects 4 } 618 testCapabilityEntry OBJECT-TYPE 619 SYNTAX TestCapabilityEntry 620 MAX-ACCESS not-accessible 621 STATUS current 622 DESCRIPTION 623 "Each entry in this table represents a test type." 624 INDEX { testCapabilityIndex } 625 ::= { testCapabilityTable 1 } 627 TestCapabilityEntry ::= 628 SEQUENCE { 629 testCapabilityIndex Unsigned32, 630 testCapabilityType AutonomousType 631 } 633 testCapabilityIndex OBJECT-TYPE 634 SYNTAX Unsigned32 (1..4294967295) 635 MAX-ACCESS not-accessible 636 STATUS current 637 DESCRIPTION 638 "An integer index that uniquely identifies the entry." 639 ::= { testCapabilityEntry 1 } 641 testCapabilityType OBJECT-TYPE 642 SYNTAX AutonomousType 643 MAX-ACCESS read-only 644 STATUS current 645 DESCRIPTION 646 "The type of test that can be invoked." 647 ::= { testCapabilityEntry 2 } 649 -- Notifications 651 testMIBNotifications OBJECT IDENTIFIER ::= { testMIB 0 } 653 testComplete NOTIFICATION-TYPE 654 OBJECTS { 655 testTarget, 656 testType, 657 testMoreInfo, 658 testResult, 659 testCode, 660 testOwner } 661 STATUS current 662 DESCRIPTION 663 "A testComplete trap signifies that a test has completed for 664 a particular entity. If the testCode has the semantics of 665 a VariablePointer, the variable it points at will also be 666 included in the objects list." 667 ::= { testMIBNotifications 1 } 669 -- Conformance Information 671 testMIBConformance OBJECT IDENTIFIER ::= { testMIB 3 } 673 testMIBGroups OBJECT IDENTIFIER 674 ::= { testMIBConformance 1 } 676 testMIBCompliances OBJECT IDENTIFIER 677 ::= { testMIBConformance 2 } 679 -- Compliance Statements 681 testMIBCompliance MODULE-COMPLIANCE 682 STATUS current 683 DESCRIPTION 684 "The compliance statement for SNMP agents which support 685 generic testing capabilities." 687 MODULE -- this module 689 MANDATORY-GROUPS { testMIBGroup, testNotificationGroup } 691 OBJECT testTableMaxSize 692 MIN-ACCESS read-only 693 DESCRIPTION 694 "Write access is not required." 696 ::= { testMIBCompliances 1 } 698 -- Units of Conformance 700 testMIBGroup OBJECT-GROUP 701 OBJECTS { 702 testIndexNext, 703 testTarget, 704 testType, 705 testMoreInfo, 706 testResultTimeStamp, 707 testResult, 708 testCode, 709 testOwner, 710 testRowStatus, 711 testTableMaxSize, 712 testCapabilityType 713 } 714 STATUS current 715 DESCRIPTION 716 "A collection of objects providing a generic 717 test capability." 718 ::= { testMIBGroups 1 } 720 testNotificationGroup NOTIFICATION-GROUP 721 NOTIFICATIONS { 722 testComplete 723 } 724 STATUS current 725 DESCRIPTION 726 "The notifications used to indicate test completion." 727 ::= { testMIBGroups 2 } 729 END 730 7. Security Considerations 732 There are a number of management objects defined in this MIB 733 that have a MAX-ACCESS clause of read-write and/or read- 734 create. Such objects may be considered sensitive or 735 vulnerable in some network environments. The support for SET 736 operations in a non-secure environment without proper 737 protection can have a negative effect on network operations. 739 The managed objects in this MIB contain sensitive information 740 since, collectively, they allow the invocation of tests on the 741 managed device. These tests may have consequences such as 742 configuration changes, service interruptions, etc. Security 743 considerations for individual tests are discussed in the 744 documents defining such tests. 746 It is thus important to control even GET access to these 747 objects and possibly to even encrypt the values of these 748 object when sending them over the network via SNMP. Not all 749 versions of SNMP provide features for such a secure 750 environment. 752 SNMPv1 by itself is not a secure environment. Even if the 753 network itself is secure (for example by using IPSec), even 754 then, there is no control as to who on the secure network is 755 allowed to access and GET/SET (read/change/create/delete) the 756 objects in this MIB. 758 It is recommended that the implementers consider the security 759 features as provided by the SNMPv3 framework. Specifically, 760 the use of the User-based Security Model RFC 2574 [RFC2574] 761 and the View-based Access Control Model RFC 2575 [RFC2575] is 762 recommended. 764 It is then a customer/user responsibility to ensure that the 765 SNMP entity giving access to an instance of this MIB, is 766 properly configured to give access to the objects only to 767 those principals (users) that have legitimate rights to indeed 768 GET or SET (change/create/delete) them. 770 8. Acknowledgments 772 This document is a product of the IETF's Interfaces MIB 773 Working Group. 775 The original ifTestTable was the work of Keith McCloghrie 776 (Cisco) and Frank Kastenholz (FTP Software) and has been used 777 in this further evolution. 779 The authors would like to acknowledge the following 780 individuals for their input on requirements: 782 James Watt (Newbridge) 783 Dave Fowler (Newbridge) 784 Steven Buchko (Newbridge) 785 Milt Rosslinsky (ACC) 786 Dawn Xie (Lucent) 787 Chris Martin (Netedge) 788 Harmen van der Linde (Bellcore) 789 Bert Wijnen (IBM T. J. Watson Research) 791 9. References 793 [RFC2233] McCloghrie, K., Kastenholz, F., " The Interfaces 794 Group MIB using SMIv2", RFC2233, Cisco Systems, 795 Inc., FTP Software, November 1997. 797 [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An 798 Architecture for Describing SNMP Management 799 Frameworks", RFC 2571, April 1999 801 [RFC1155] Rose, M., and K. McCloghrie, "Structure and 802 Identification of Management Information for 803 TCP/IP-based Internets", STD 16, RFC 1155, May 804 1990 806 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB 807 Definitions", STD 16, RFC 1212, March 1991 809 [RFC1215] M. Rose, "A Convention for Defining Traps for use 810 with the SNMP", RFC 1215, March 1991 812 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., 813 Case, J., Rose, M., and S. Waldbusser, "Structure 814 of Management Information Version 2 (SMIv2)", STD 815 58, RFC 2578, April 1999 817 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., 818 Case, J., Rose, M., and S. Waldbusser, "Textual 819 Conventions for SMIv2", STD 58, RFC 2579, April 820 1999 822 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., 823 Case, J., Rose, M., and S. Waldbusser, 824 "Conformance Statements for SMIv2", STD 58, RFC 825 2580, April 1999 827 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. 828 Davin, "Simple Network Management Protocol", STD 829 15, RFC 1157, May 1990. 831 [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. 832 Waldbusser, "Introduction to Community-based 833 SNMPv2", RFC 1901, January 1996. 835 [RFC1906] Case, J., McCloghrie, K., Rose, M., and S. 836 Waldbusser, "Transport Mappings for Version 2 of 837 the Simple Network Management Protocol (SNMPv2)", 838 RFC 1906, January 1996. 840 [RFC2572] Case, J., Harrington D., Presuhn R., and B. 841 Wijnen, "Message Processing and Dispatching for 842 the Simple Network Management Protocol (SNMP)", 843 RFC 2572, April 1999 845 [RFC2574] Blumenthal, U., and B. Wijnen, "User-based 846 Security Model (USM) for version 3 of the Simple 847 Network Management Protocol (SNMPv3)", RFC 2574, 848 April 1999 850 [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. 851 Waldbusser, "Protocol Operations for Version 2 of 852 the Simple Network Management Protocol (SNMPv2)", 853 RFC 1905, January 1996. 855 [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 856 Applications", RFC 2573, April 1999 858 [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, 859 "View-based Access Control Model (VACM) for the 860 Simple Network Management Protocol (SNMP)", RFC 861 2575, April 1999 863 [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, 864 "Introduction to Version 3 of the Internet- 865 standard Network Management Framework", RFC 2570, 866 April 1999 868 [RFC2037] McCloghrie, K., and A. Bierman, Editors, "Entity 869 MIB", RFC2037, Cisco Systems, January 1996. 871 10. Authors' Addresses 873 Maria Greene 874 Xedia Corp. 875 19 Russell St. 876 Littleton, MA 01460 877 USA 878 Phone: (978) 897-1828 879 Email: maria@xedia.com 881 Keith McCloghrie 882 Cisco Systems 883 170 West Tasman Drive 884 San Jose, CA 95134 885 Phone: (408) 526-5260 886 Email: kzm@cisco.com 888 Kaj Tesink 889 Telcordia Technologies 890 331 Newman Springs Road 891 P.O. Box 7020 892 Red Bank, NJ 07701-7020 893 Phone: (732) 758-5254 894 Email: kaj@research.telcordia.com 896 11. RFC Editor and IANA Considerations 898 Prior to publication of this memo as an RFC, the RFC Editor 899 and IANA are requested replace xxxx below with the RFC number 900 of this document, to make a suitable OBJECT IDENTIFIER 901 assignment for YY below and update the following in the MIB: 903 DESCRIPTION 904 "Initial version, published as RFCxxxx" 905 ::= { mib-2 YY } 907 -- ******** NOTE TO THE RFC EDITOR AND IANA ********* 908 -- * In case this module is put on the standards track 909 -- * fill out RFCxxxx with the RFC number of this document 910 -- * assign a suitable value to YY by IANA 911 -- * and remove this notice from the MIB 913 12. Intellectual Property 915 The IETF takes no position regarding the validity or scope of 916 any intellectual property or other rights that might be 917 claimed to pertain to the implementation or use of the 918 technology described in this document or the extent to which 919 any license under such rights might or might not be available; 920 neither does it represent that it has made any effort to 921 identify any such rights. Information on the IETF's 922 procedures with respect to rights in standards-track and 923 standards-related documentation can be found in BCP-11. 924 Copies of claims of rights made available for publication and 925 any assurances of licenses to be made available, or the result 926 of an attempt made to obtain a general license or permission 927 for the use of such proprietary rights by implementors or 928 users of this specification can be obtained from the IETF 929 Secretariat. 931 The IETF invites any interested party to bring to its 932 attention any copyrights, patents or patent applications, or 933 other proprietary rights which may cover technology that may 934 be required to practice this standard. Please address the 935 information to the IETF Executive Director. 937 13. Full Copyright Statement 939 Copyright (C) The Internet Society (1999). All Rights 940 Reserved. 942 This document and translations of it may be copied and 943 furnished to others, and derivative works that comment on or 944 otherwise explain it or assist in its implementation may be 945 prepared, copied, published and distributed, in whole or in 946 part, without restriction of any kind, provided that the above 947 copyright notice and this paragraph are included on all such 948 copies and derivative works. However, this document itself 949 may not be modified in any way, such as by removing the 950 copyright notice or references to the Internet Society or 951 other Internet organizations, except as needed for the purpose 952 of developing Internet standards in which case the procedures 953 for copyrights defined in the Internet Standards process must 954 be followed, or as required to translate it into languages 955 other than English. 957 The limited permissions granted above are perpetual and will 958 not be revoked by the Internet Society or its successors or 959 assigns. 961 This document and the information contained herein is provided 962 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 963 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 964 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 965 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 966 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 967 PARTICULAR PURPOSE." 968 Table of Contents 970 1 Status of this Memo ................................... 1 971 2 Abstract .............................................. 2 972 3 The SNMP Management Framework ......................... 3 973 4 Experience with the Interfaces Test Group ............. 5 974 5 Requirements for a Generic Test MIB ................... 5 975 5.1 Test Identification ................................. 5 976 5.2 Test Targets ........................................ 6 977 5.3 Logging Results ..................................... 6 978 5.4 Log Searching ....................................... 7 979 5.5 Determining Agent Test Capabilities ................. 8 980 6 Definitions ........................................... 9 981 7 Security Considerations ............................... 20 982 8 Acknowledgments ....................................... 21 983 9 References ............................................ 22 984 10 Authors' Addresses ................................... 24 985 11 RFC Editor and IANA Considerations ................... 24 986 12 Intellectual Property ................................ 25 987 13 Full Copyright Statement ............................. 26