idnits 2.17.1 draft-ietf-ifmib-testmib-04.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. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 (December 1, 1998) is 9277 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 814 looks like a reference -- Missing reference section? '1' on line 728 looks like a reference -- Missing reference section? '2' on line 733 looks like a reference -- Missing reference section? '3' on line 738 looks like a reference -- Missing reference section? '4' on line 742 looks like a reference -- Missing reference section? '5' on line 746 looks like a reference -- Missing reference section? '6' on line 753 looks like a reference -- Missing reference section? '7' on line 760 looks like a reference -- Missing reference section? '8' on line 767 looks like a reference -- Missing reference section? '9' on line 773 looks like a reference -- Missing reference section? '10' on line 779 looks like a reference -- Missing reference section? '11' on line 786 looks like a reference -- Missing reference section? '12' on line 851 looks like a reference -- Missing reference section? '13' on line 797 looks like a reference -- Missing reference section? '14' on line 804 looks like a reference -- Missing reference section? '15' on line 852 looks like a reference -- Missing reference section? '17' on line 818 looks like a reference Summary: 15 errors (**), 0 flaws (~~), 2 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT System/Interface Test MIB December 1, 1998 4 Definitions of Managed Objects for 5 System and Interface Testing 7 December 1, 1998 9 11 Maria Greene 12 Xedia Corp. 13 maria@xedia.com 15 Keith McCloghrie 16 Cisco Systems 17 kzm@cisco.com 19 Kaj Tesink 20 Bellcore 21 kaj@bellcore.com 23 1. Status of this Memo 25 This document is an Internet-Draft. Internet-Drafts are 26 working documents of the Internet Engineering Task Force 27 (IETF), its areas, and its working groups. Note that other 28 groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other 33 documents at any time. It is inappropriate to use Internet- 34 Drafts as reference material or to cite them other than as 35 ``work in progress.'' 37 To learn the current status of any Internet-Draft, please 38 check the ``1id-abstracts.txt'' listing contained in the 39 Internet- Drafts Shadow Directories on ftp.ietf.org (US East 40 Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), 41 or munnari.oz.au (Pacific Rim). 43 Copyright Notice 45 Copyright (C) The Internet Society (1998). All Rights 46 Reserved. 48 2. Abstract 50 This memo defines an portion of the Management Information 51 Base (MIB) for use with network management protocols in the 52 Internet community. In particular, it describes objects used 53 for testing systems and interfaces. This memo defines the 54 following: 56 0 A general mechanism to initiate tests 58 0 A capability to provide and store test results 60 0 A capability to inventory the tests that are supported by 61 an agent 63 This memo does not specify individual tests. Such tests are 64 subject of separate system- or media-specific specifications. 66 This memo replaces the objects defined in the ifTestGroup of 67 RFC2233[16] which have been deprecated. 69 3. The SNMP Network Management Framework 71 The SNMP Management Framework presently consists of five major 72 components: 74 0 An overall architecture, described in RFC 2271 [1]. 76 0 Mechanisms for describing and naming objects and events 77 for the purpose of management. The first version of this 78 Structure of Management Information (SMI) is called SMIv1 79 and described in RFC 1155 [2], RFC 1212 [3] and RFC 1215 80 [4]. The second version, called SMIv2, is described in 81 RFC 1902 [5], RFC 1903 [6] and RFC 1904 [7]. 83 0 Message protocols for transferring management 84 information. The first version of the SNMP message 85 protocol is called SNMPv1 and described in RFC 1157 [8]. 86 A second version of the SNMP message protocol, which is 87 not an Internet standards track protocol, is called 88 SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. 89 The third version of the message protocol is called 90 SNMPv3 and described in RFC 1906 [10], RFC 2272 [11] and 91 RFC 2274 [12]. 93 0 Protocol operations for accessing management information. 94 The first set of protocol operations and associated PDU 95 formats is described in RFC 1157 [8]. A second set of 96 protocol operations and associated PDU formats is 97 described in RFC 1905 [13]. 99 0 A set of fundamental applications described in RFC 2273 100 [14] and the view-based access control mechanism 101 described in RFC 2275 [15]. 103 Managed objects are accessed via a virtual information store, 104 termed the Management Information Base or MIB. Objects in the 105 MIB are defined using the mechanisms defined in the SMI. 107 This memo specifies a MIB module that is compliant to the 108 SMIv2. A MIB conforming to the SMIv1 can be produced through 109 the appropriate translations. The resulting translated MIB 110 must be semantically equivalent, except where objects or 111 events are omitted because no translation is possible (e.g., 112 use of Counter64). Some machine readable information in SMIv2 113 will be converted into textual descriptions in SMIv1 during 114 the translation process. However, this loss of machine 115 readable information is not considered to change the semantics 116 of the MIB. 118 4. Experience with the Interfaces Test Group 120 The ifTestGroup of objects defined in RFC2233 has not been 121 used widely. Some cited problems were: 123 0 Few standard tests had been defined to date. 125 0 Some well known tests had already been written on a 126 media-specific basis, e.g., DS1 loopback. The 127 ifTestGroup allowed for interface testing only. 129 0 A logging capability was missing. 131 As a result, the ifTestGroup and associated ifTestTable have 132 been deprecated. However, since renewed interest was expressed 133 in a generic testing capability, specifically in the 134 development of MIBs for managing Asynchronous Transfer Mode 135 interfaces, a set of requirements have been defined that form 136 the basis for the design of the generic Test MIB defined in 137 this memo. 139 5. Requirements for a Generic Test MIB 141 This section describes the requirements that have been 142 identified for a generic test MIB. 144 5.1. Test Identification 146 The system defined in RFC2233 to identify tests relies on 147 OBJECT IDENTIFIERs. This system is flexible in that it allows 148 additional tests to be defined over time and autonomously by 149 vendors, removing the need to register test types in a single 150 place. This mechanism for test identification has been 151 retained. 153 5.2. Test Targets 155 With the advent of an increasing number of non-interface 156 related MIB modules it is desirable to define a test 157 capability that allows testing of interfaces and non-interface 158 physical entities. The following possibilities were 159 considered: 161 a) Separate test capabilities for interface tests and other 162 tests. 164 b) The use of a single test capability where the test target 165 would be defined within the test table. 167 This memo uses the latter approach and uses an object with the 168 syntax RowPointer to identify test targets. (Initially, the 169 use of the Entity MIB[17] was considered for identification of 170 test targets, but this was abandoned because this would 171 require support of the Entity MIB for testing purposes.) 173 Tests are listed in the testTable. The entries in the 174 testTable are distinguished through the value of a simple 175 integer called testIndex. 177 5.3. Logging Results 179 A logging capability of test results serves to store the test 180 results for some period of time. Two mechanisms were 181 considered: 183 1) Separate the test capability and the log. 185 2) Combine the test capability and the log in a single 186 table. 188 The log length is necessarily limited. The following choices 189 were considered: 191 1) Age the entries. 193 2) Limit by the number of entries. 195 3) A system that allows either 1) or 2). 197 For efficiency reasons this MIB module chooses a system where 198 the test and logging capability have been combined in a single 199 table (testTable). The log length is limited by a read-write 200 object (testTableMaxSize). 202 This MIB module also defines a notification, testComplete, 203 which contains the same information as the log entry. 204 Therefore, an agent with limited resources can limit the 205 maximum size of the log to a very few number of entries and 206 rely on a management application to receive and log the 207 testComplete notifications. 209 5.4. Log Searching 211 Efficient searching in a log is a key to its effectiveness. 212 The following possibilities were considered: 214 a) Sort on age of the entries. 216 b) Sort on test type. 218 c) Sort on combinations of the above. 220 This MIB module chooses for the index testIndex, which is an 221 integer identifier for an invocation of a test. To obtain a 222 new testIndex a manager retrieves the value of testIndexNext. 223 Each time this object is read the next lower available value 224 is provided. This addresses the requests that are expected to 225 be most common: 227 0 What is the result of test (testIndex)? 229 0 What are the results of the last n tests? 231 Since the testIndex has been defined as decreasing, this 232 approach will order log entries by time, newest to oldest. The 233 possibility of testId wrapping is minimized by having it 234 restart at its maximum value and when the agent restarts. When 235 a manager is interested in a specific test, a specific get- 236 request may be issued. When a manager is interested in the 237 latest n tests for the system, getnext/bulk starting from 238 (testIndex) provides the approximate answer. 240 5.5. Determining Agent Test Capabilities 242 A testCapabilityTable has been defined to list the tests that 243 can be performed through this agent. 245 6. Definitions 247 TEST-MIB DEFINITIONS ::= BEGIN 249 IMPORTS 250 MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, 251 zeroDotZero, NOTIFICATION-TYPE, mib-2, experimental 252 FROM SNMPv2-SMI 253 AutonomousType, RowPointer, TimeStamp, RowStatus 254 FROM SNMPv2-TC 255 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 256 FROM SNMPv2-CONF 257 OwnerString 258 FROM IF-MIB 259 ; 261 testMIB MODULE-IDENTITY 262 LAST-UPDATED "9812011200Z" 263 ORGANIZATION "IETF IFMIB Working Group" 264 CONTACT-INFO 265 "Maria Greene 266 Postal: Xedia Corp. 267 119 Russell St. 268 Littleton, MA 01460 269 USA 270 Tel: +1 978 897 1828 271 E-mail: maria@xedia.com 273 Keith McCloghrie 274 Postal: Cisco Systems 275 170 West Tasman Drive 276 San Jose, CA 95134 277 USA 278 Tel: +1 408 526 5260 279 E-mail: kzm@cisco.com 281 Kaj Tesink 282 Postal: Bell Communications Research 283 331 Newman Springs Road 284 Red Bank, NJ 07701 285 USA 286 Tel: +1 732 758 5254 287 E-mail: kaj@bellcore.com" 288 DESCRIPTION 289 "This MIB module provides a generic test 290 capability." 291 -- ******** NOTE TO THE RFC EDITOR AND IANA ********* 292 -- In case this module is put on the standards track 293 -- replace the following: 294 -- "::= {experimental XX}" with 295 -- "::= { mib-2 YY }" 296 -- and assign a suitable value to YY by IANA 297 -- and remove experimental from the IMPORTS clause 298 ::= { experimental XX } 300 testMIBObjects OBJECT IDENTIFIER ::= { testMIB 1 } 302 testIndexNext OBJECT-TYPE 303 SYNTAX Unsigned32 304 MAX-ACCESS read-only 305 STATUS current 306 DESCRIPTION 307 "This object contains an appropriate value to 308 be used for testIndex when creating 309 entries in the testTable. The object is used in 310 order to minimize collisions caused by multiple 311 managers. 312 The value 0 indicates that no unassigned entries 313 are available. To obtain the testIndex 314 value for a new entry, the manager issues a 315 management protocol retrieval operation to obtain 316 the current value of this object. After each 317 retrieval, the agent should modify the value to 318 the next lower unassigned index. If the agent is 319 restarted this object shall be set to its highest 320 value. 321 The agent does not require that retrieved values 322 are actually used in subsequent tests or that 323 they are used in the order of their retrieval." 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. Some agents 348 may reject a test when a prior test is active on 349 another entity. 351 Before starting a test, a manager-station must first 352 obtain 'ownership' of the entry in the testTable for 353 the entity to be tested. This is accomplished by 354 retrieving the value of testIndexNext. This value 355 entitles the manager to create a row in the 356 testTable with the value of testIndex being equal to 357 the retrieved value of testIndexNext and testOwner 358 set to the appropriate value for the manager. 360 Once 'ownership' is obtained, the testOwner and test 361 parameters can be setup, by creating a row with the 362 reserved testIndex and appropriate test parameter 363 settings. Then the test is initiated by setting the 364 testRowStatus to 'active'. The agent sets the value of 365 testResult to 'inProgress'. 366 On completion of the test, the agent sets testResult 367 and testCode in accordance with the test results and 368 sets the testResultTimeStamp. 370 In general, a management station must not retransmit a 371 request to invoke a test for which it does not receive a 372 response; instead, it properly inspects an agent's MIB 373 to determine if the invocation was successful. Only if 374 the invocation was unsuccessful, is the invocation 375 request retransmitted. 377 Some tests may require the entity to be taken off- line 378 in order to execute them, or may even require the agent 379 to reboot after completion of the test. In these 380 circumstances, communication with the management station 381 invoking the test may be lost until after completion of 382 the test. An agent is not required to support such 383 tests. However, if such tests are supported, then the 384 agent should make every effort to transmit a response to 385 the request which invoked the test prior to losing 386 communication. When the agent is restored to normal 387 service, the results of the test are properly made 388 available in the appropriate objects. Note that this 389 requires that the testIndex value assigned to an entity 390 must be unchanged even if the test causes a reboot. An 391 agent must reject any test for which it cannot, perhaps 392 due to resource constraints, make available at least the 393 minimum amount of information after that test 394 completes. 396 Managers are responsible for removing rows that are no 397 longer in use." 398 ::= { testMIBObjects 2 } 400 testEntry OBJECT-TYPE 401 SYNTAX TestEntry 402 MAX-ACCESS not-accessible 403 STATUS current 404 DESCRIPTION 405 "An entry containing objects for invoking a test and 406 reporting test results." 407 INDEX { testIndex } 408 ::= { testTable 1 } 410 TestEntry ::= 411 SEQUENCE { 412 testIndex Unsigned32, 413 testTarget RowPointer, 414 testType AutonomousType, 415 testMoreInfo OCTET STRING, 416 testResultTimeStamp TimeStamp, 417 testResult INTEGER, 418 testCode OBJECT IDENTIFIER, 419 testOwner OwnerString, 420 testRowStatus RowStatus } 422 testIndex OBJECT-TYPE 423 SYNTAX Unsigned32 (1..4294967295) 424 MAX-ACCESS not-accessible 425 STATUS current 426 DESCRIPTION 427 "The index of this table." 428 ::= { testEntry 1 } 430 testTarget OBJECT-TYPE 431 SYNTAX RowPointer 432 MAX-ACCES read-create 433 STATUS current 434 DESCRIPTION 435 "The target of the test. An example of a test target 436 is an instance of an interface, identified by the 437 OID 'ifIndex.17'. 438 When the value zeroDotZero is written to this object, 439 no action is taken. " 440 DEFVAL { zeroDotZero } 441 ::= { testEntry 2 } 443 testType OBJECT-TYPE 444 SYNTAX AutonomousType 445 MAX-ACCESS read-create 446 STATUS current 447 DESCRIPTION 448 "The identifier that specifies the test. 449 OBJECT IDENTIFIER values assigned to tests 450 are defined elsewhere, in association with 451 specific types of entity. 452 When the value 'zeroDotZero' is written to this 453 object, no action is taken. 454 Additional information for this test may be 455 specified in testMoreInfo. The value of 456 testType must be one of those listed in the 457 testCapabilityTable." 458 DEFVAL { zeroDotZero } 459 ::= { testEntry 3 } 461 testMoreInfo OBJECT-TYPE 462 SYNTAX OCTET STRING 463 MAX-ACCESS read-create 464 STATUS current 465 DESCRIPTION 466 "Additional test-specific information." 468 DEFVAL { "" } 469 ::= { testEntry 4 } 471 testResultTimeStamp OBJECT-TYPE 472 SYNTAX TimeStamp 473 MAX-ACCESS read-only 474 STATUS current 475 DESCRIPTION 476 "The value of sysUpTime when a testResult has 477 been reached. 478 When a test is 'inProgress' the value of 479 testResultTimeStamp shall be 0." 480 ::= { testEntry 5 } 482 testResult OBJECT-TYPE 483 SYNTAX INTEGER { 484 none(1), -- no test yet requested 485 success(2), 486 inProgress(3), -- transient state 487 notSupported(4),-- not in testCapabilityTable 488 unAbleToRun(5), -- due to state of system 489 aborted(6), -- by manager action 490 failed(7) 491 } 492 MAX-ACCESS read-only 493 STATUS current 494 DESCRIPTION 495 "This object contains the result of the most recently 496 requested test, or the value 'none' if no test 497 has been started yet." 498 ::= { testEntry 6 } 500 testCode OBJECT-TYPE 501 SYNTAX OBJECT IDENTIFIER 502 MAX-ACCESS read-only 503 STATUS current 504 DESCRIPTION 505 "This object contains a code which contains more specific 506 information on the test result, for example an error-code 507 after a failed test or a result value such as round trip 508 time for a 'ping' test. Error codes and other values this 509 object may take are specific to the type of entity and/or 510 test. The value may have the semantics of AutonomousType, 511 RowPointer or VariablePointer textual conventions as 512 defined in RFC 1903. The identifier: 514 testCodeNone OBJECT IDENTIFIER ::= zeroDotZero 516 is defined for use if no additional result code is 517 available." 518 ::= { testEntry 7 } 520 testOwner OBJECT-TYPE 521 SYNTAX OwnerString 522 MAX-ACCESS read-create 523 STATUS current 524 DESCRIPTION 525 "The manager which currently has the 'ownership' 526 required to invoke a test on this entity, e.g., 527 the manager station's transport address, 528 management station name (e.g., domain name), 529 network management personnel's name, location, 530 or phone number." 531 REFERENCE 532 "McCloghrie, K., Kastenholz, F., The Interfaces 533 Group MIB using SMIv2, RFC2233, Cisco Systems, 534 Inc., FTP Software, November 1997." 535 ::= { testEntry 8 } 537 testRowStatus OBJECT-TYPE 538 SYNTAX RowStatus 539 MAX-ACCESS read-create 540 STATUS current 541 DESCRIPTION 542 "The row status of the test information. 543 A row must be active before tests can be 544 activiated. Deactivating a row will abort any 545 ongoing test associated with that row. 546 Manipulation of the test: 547 - When all test parameters (testTarget, testType, 548 testMoreInfo and testOwner) have been properly 549 set the test is started by setting testRowStatus 550 to 'active'. This causes the testResult 551 to assume the value 'inProgress' until some other 552 value of testResult is reached. 553 - If the manager sets testRowStatus to 'active' 554 while the test is inProgress then this action 555 will not affect the ongoing test. 556 - Details of ongoing or completed tests are 557 reported in testResult and testCode. 559 - After test completion the test may be repeated 560 by first setting testRowStatus to 'notInService', 561 manipulating the test parameters as necessary, and 562 setting the testRowStatus to 'active' again. 563 - A manager may abort ongoing tests or remove 564 completed test information by setting the 565 testRowStatus to 'notInService' or 'destroy'." 566 DEFVAL { createAndWait } 567 ::= { testEntry 9 } 569 -- Table size 571 testTableMaxSize OBJECT-TYPE 572 SYNTAX Unsigned32 (10..4294967295) 573 MAX-ACCESS read-write 574 STATUS current 575 DESCRIPTION 576 "The maximum number entries in the testTable. 577 Removal of old entries is the responsibility of 578 the manager. 579 The table is flushed when the agent is reset." 580 ::= { testMIBObjects 3 } 582 -- Test Capability Table 584 testCapabilityTable OBJECT-TYPE 585 SYNTAX SEQUENCE OF TestCapabilityEntry 586 MAX-ACCESS not-accessible 587 STATUS current 588 DESCRIPTION 589 "This table contains test types (potential 590 values for the testType object) that are 591 supported by this agent." 592 ::= { testMIBObjects 4 } 594 testCapabilityEntry OBJECT-TYPE 595 SYNTAX TestCapabilityEntry 596 MAX-ACCESS not-accessible 597 STATUS current 598 DESCRIPTION 599 "Each entry in this table represents a test type." 600 INDEX { testCapabilityIndex } 601 ::= { testCapabilityTable 1 } 603 TestCapabilityEntry ::= 604 SEQUENCE { 605 testCapabilityIndex Unsigned32, 606 testCapabilityType AutonomousType 607 } 609 testCapabilityIndex OBJECT-TYPE 610 SYNTAX Unsigned32 611 MAX-ACCESS not-accessible 612 STATUS current 613 DESCRIPTION 614 "An integer index that uniquely identifies the entry." 615 ::= { testCapabilityEntry 1 } 617 testCapabilityType OBJECT-TYPE 618 SYNTAX AutonomousType 619 MAX-ACCESS read-only 620 STATUS current 621 DESCRIPTION 622 "The type of test that can be invoked." 623 ::= { testCapabilityEntry 2 } 625 -- Notifications 627 testMIBNotifications OBJECT IDENTIFIER ::= { testMIB 0 } 629 testComplete NOTIFICATION-TYPE 630 OBJECTS { 631 testTarget, 632 testType, 633 testMoreInfo, 634 testResult, 635 testCode, 636 testOwner } 637 STATUS current 638 DESCRIPTION 639 "A testComplete trap signifies that a test has completed for 640 a particular entity. If the testCode has the semantics of 641 a VariablePointer, the variable it points at will also be 642 included in the objects list." 643 ::= { testMIBNotifications 1 } 645 -- Conformance Information 647 testMIBConformance OBJECT IDENTIFIER ::= { testMIB 3 } 649 testMIBGroups OBJECT IDENTIFIER 650 ::= { testMIBConformance 1 } 652 testMIBCompliances OBJECT IDENTIFIER 653 ::= { testMIBConformance 2 } 655 -- Compliance Statements 657 testMIBCompliance MODULE-COMPLIANCE 658 STATUS current 659 DESCRIPTION 660 "The compliance statement for SNMP agents which support 661 generic testing capabilities." 663 MODULE -- this module 665 MANDATORY-GROUPS { testMIBGroup, testNotificationGroup } 667 OBJECT testTableMaxSize 668 MIN-ACCESS read-only 669 DESCRIPTION 670 "Write access is not required." 672 ::= { testMIBCompliances 1 } 674 -- Units of Conformance 676 testMIBGroup OBJECT-GROUP 677 OBJECTS { 678 testIndexNext, 679 testTarget, 680 testType, 681 testMoreInfo, 682 testResultTimeStamp, 683 testResult, 684 testCode, 685 testOwner, 686 testRowStatus, 687 testTableMaxSize, 688 testCapabilityType 689 } 690 STATUS current 691 DESCRIPTION 692 "A collection of objects providing a generic 693 test capability." 694 ::= { testMIBGroups 1 } 696 testNotificationGroup NOTIFICATION-GROUP 697 NOTIFICATIONS { 698 testComplete 699 } 700 STATUS current 701 DESCRIPTION 702 "The notifications used to indicate test completion." 703 ::= { testMIBGroups 2 } 705 END 706 7. Acknowledgments 708 This document is a product of the IETF's Interfaces MIB 709 Working Group. 711 The original ifTestTable was the work of Keith McCloghrie 712 (Cisco) and Frank Kastenholz (FTP Software) and has been used 713 in this further evolution. 715 The authors would like to acknowledge the following 716 individuals for their input on requirements: 718 James Watt (Newbridge) 719 Dave Fowler (Newbridge) 720 Steven Buchko (Newbridge) 721 Milt Rosslinsky (ACC) 722 Dawn Xie (Lucent) 723 Chris Martin (Netedge) 724 Harmen van der Linde (Bellcore) 726 8. References 728 [1] Harrington, D., Presuhn, R., and B. Wijnen, "An 729 Architecture for Describing SNMP Management Frameworks", 730 RFC 2271, Cabletron Systems, Inc., BMC Software, Inc., 731 IBM T. J. Watson Research, January 1998 733 [2] Rose, M., and K. McCloghrie, "Structure and 734 Identification of Management Information for TCP/IP-based 735 Internets", RFC 1155, Performance Systems International, 736 Hughes LAN Systems, May 1990 738 [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", 739 RFC 1212, Performance Systems International, Hughes LAN 740 Systems, March 1991 742 [4] M. Rose, "A Convention for Defining Traps for use with 743 the SNMP", RFC 1215, Performance Systems International, 744 March 1991 746 [5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., 747 and S. Waldbusser, "Structure of Management Information 748 for Version 2 of the Simple Network Management Protocol 749 (SNMPv2)", RFC 1902, SNMP Research,Inc., Cisco Systems, 750 Inc., Dover Beach Consulting, Inc., International Network 751 Services, January 1996. 753 [6] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., 754 and S. Waldbusser, "Textual Conventions for Version 2 of 755 the Simple Network Management Protocol (SNMPv2)", RFC 756 1903, SNMP Research, Inc., Cisco Systems, Inc., Dover 757 Beach Consulting, Inc., International Network Services, 758 January 1996. 760 [7] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., 761 and S. Waldbusser, "Conformance Statements for Version 2 762 of the Simple Network Management Protocol (SNMPv2)", RFC 763 1904, SNMP Research, Inc., Cisco Systems, Inc., Dover 764 Beach Consulting, Inc., International Network Services, 765 January 1996. 767 [8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 768 "Simple Network Management Protocol", RFC 1157, SNMP 769 Research, Performance Systems International, Performance 770 Systems International, MIT Laboratory for Computer 771 Science, May 1990. 773 [9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., 774 and S. Waldbusser, "Introduction to Community-based 775 SNMPv2", RFC 1901, SNMP Research, Inc., Cisco Systems, 776 Inc., Dover Beach Consulting, Inc., International Network 777 Services, January 1996. 779 [10] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., 780 and S. Waldbusser, "Transport Mappings for Version 2 of 781 the Simple Network Management Protocol (SNMPv2)", RFC 782 1906, SNMP Research, Inc., Cisco Systems, Inc., Dover 783 Beach Consulting, Inc., International Network Services, 784 January 1996. 786 [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, 787 "Message Processing and Dispatching for the Simple 788 Network Management Protocol (SNMP)", RFC 2272, SNMP 789 Research, Inc., Cabletron Systems, Inc., BMC Software, 790 Inc., IBM T. J. Watson Research, January 1998. 792 [12] Blumenthal, U., and B. Wijnen, "User-based Security Model 793 (USM) for version 3 of the Simple Network Management 794 Protocol (SNMPv3)", RFC 2274, IBM T. J. Watson Research, 795 January 1998. 797 [13] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., 798 and S. Waldbusser, "Protocol Operations for Version 2 of 799 the Simple Network Management Protocol (SNMPv2)", RFC 800 1905, SNMP Research, Inc., Cisco Systems, Inc., Dover 801 Beach Consulting, Inc., International Network Services, 802 January 1996. 804 [14] Levi, D., Meyer, P., and B. Stewart, SNMPv3 805 Applications", RFC 2273, SNMP Research, Inc., Secure 806 Computing Corporation, Cisco Systems, January 1998. 808 [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 809 Access Control Model (VACM) for the Simple Network 810 Management Protocol (SNMP)", RFC 2275, IBM T. J. Watson 811 Research, BMC Software, Inc., Cisco Systems, Inc., 812 January 1998. 814 [16] McCloghrie, K., Kastenholz, F., " The Interfaces Group 815 MIB using SMIv2", RFC2233, Cisco Systems, Inc., FTP 816 Software, November 1997. 818 [17] McCloghrie, K., and A. Bierman, Editors, "Entity MIB", 819 RFC2037, Cisco Systems, January 1996. 821 9. Security Considerations 823 There are a number of management objects defined in this MIB 824 that have a MAX-ACCESS clause of read-write and/or read- 825 create. Such objects may be considered sensitive or 826 vulnerable in some network environments. The support for SET 827 operations in a non-secure environment without proper 828 protection can have a negative effect on network operations. 830 The managed objects in this MIB contain sensitive information 831 since, collectively, they allow the invocation of tests on the 832 managed device. These tests may have consequences such as 833 configuration changes, service interruptions, etc. Security 834 considerations for individual tests are discussed in the 835 documents defining such tests. 837 It is thus important to control even GET access to these 838 objects and possibly to even encrypt the values of these 839 object when sending them over the network via SNMP. Not all 840 versions of SNMP provide features for such a secure 841 environment. 843 SNMPv1 by itself is not a secure environment. Even if the 844 network itself is secure (for example by using IPSec), even 845 then, there is no control as to who on the secure network is 846 allowed to access and GET/SET (read/change/create/delete) the 847 objects in this MIB. 849 It is recommended that the implementers consider the security 850 features as provided by the SNMPv3 framework. Specifically, 851 the use of the User-based Security Model RFC 2274 [12] and the 852 View-based Access Control Model RFC 2275 [15] is recommended. 854 It is then a customer/user responsibility to ensure that the 855 SNMP entity giving access to an instance of this MIB, is 856 properly configured to give access to the objects only to 857 those principals (users) that have legitimate rights to indeed 858 GET or SET (change/create/delete) them. 860 10. Authors' Addresses 862 Maria Greene 863 Xedia Corp. 864 19 Russell St. 865 Littleton, MA 01460 866 USA 867 Phone: (978) 897-1828 868 EMail: maria@xedia.com 870 Keith McCloghrie 871 Cisco Systems 872 170 West Tasman Drive 873 San Jose, CA 95134 874 Phone: (408) 526-5260 875 E-mail: kzm@cisco.com 877 Kaj Tesink 878 Bell Communications Research 879 331 Newman Springs Road 880 P.O. Box 7020 881 Red Bank, NJ 07701-7020 882 Phone: (732) 758-5254 883 EMail: kaj@bellcore.com 885 11. RFC Editor and IANA Considerations 887 Prior to publication of this memo as an RFC, the RFC Editor 888 and IANA are requested to make a suitable OBJECT IDENTIFIER 889 assignment and remove the following in the MIB: 891 -- ******** NOTE TO THE RFC EDITOR AND IANA ********* 892 -- In case this module is put on the standards track 893 -- replace the following: 894 -- "::= {experimental XX}" with 895 -- "::= { mib-2 YY }" 896 -- and assign a suitable value to YY by IANA 897 -- and remove experimental from the IMPORTS clause 899 12. Full Copyright Statement 901 Copyright (C) The Internet Society (1998). All Rights 902 Reserved. 904 This document and translations of it may be copied and 905 furnished to others, and derivative works that comment on or 906 otherwise explain it or assist in its implementation may be 907 prepared, copied, published and distributed, in whole or in 908 part, without restriction of any kind, provided that the above 909 copyright notice and this paragraph are included on all such 910 copies and derivative works. However, this document itself 911 may not be modified in any way, such as by removing the 912 copyright notice or references to the Internet Society or 913 other Internet organizations, except as needed for the purpose 914 of developing Internet standards in which case the procedures 915 for copyrights defined in the Internet Standards process must 916 be followed, or as required to translate it into languages 917 other than English. 919 The limited permissions granted above are perpetual and will 920 not be revoked by the Internet Society or its successors or 921 assigns. 923 This document and the information contained herein is provided 924 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 925 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 926 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 927 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 928 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 929 PARTICULAR PURPOSE." 930 Table of Contents 932 1 Status of this Memo ................................... 1 933 2 Abstract .............................................. 2 934 3 The SNMP Network Management Framework ................. 3 935 4 Experience with the Interfaces Test Group ............. 5 936 5 Requirements for a Generic Test MIB ................... 5 937 5.1 Test Identification ................................. 5 938 5.2 Test Targets ........................................ 6 939 5.3 Logging Results ..................................... 6 940 5.4 Log Searching ....................................... 7 941 5.5 Determining Agent Test Capabilities ................. 8 942 6 Definitions ........................................... 9 943 7 Acknowledgments ....................................... 20 944 8 References ............................................ 21 945 9 Security Considerations ............................... 24 946 10 Authors' Addresses ................................... 25 947 11 RFC Editor and IANA Considerations ................... 25 948 12 Full Copyright Statement ............................. 26