idnits 2.17.1 draft-ietf-ifmib-testmib-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 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 217 instances of too long lines in the document, the longest one being 22 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [7], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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? '6' on line 685 looks like a reference -- Missing reference section? '1' on line 655 looks like a reference -- Missing reference section? '2' on line 661 looks like a reference -- Missing reference section? '3' on line 666 looks like a reference -- Missing reference section? '4' on line 671 looks like a reference -- Missing reference section? '5' on line 678 looks like a reference -- Missing reference section? '7' on line 689 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Definitions of Managed Objects for 2 System and Interface Testing 4 June, 1997 6 8 Maria Greene 9 Ascom Nexion 10 greene@nexen.com 12 Keith McCloghrie 13 Cisco Systems 14 kzm@cisco.com 16 Kaj Tesink 17 Bell Communications Research 18 kaj@cc.bellcore.com 20 Status of this Memo 22 This document is an Internet-Draft. Internet-Drafts are working 23 documents of the Internet Engineering Task Force (IETF), its Areas, 24 and its Working Groups. Note that other groups may also distribute 25 working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as a "work in progress". 32 To learn the current status of any Internet-Draft, please check the 33 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 34 Directories on ds.internic.net (US East Coast), nic.nordu.net 35 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 36 Rim). 38 Abstract 40 This memo defines an experimental portion of the Management 41 Information Base (MIB) for use with network management protocols in 42 the Internet community. In particular, it describes objects used for 43 testing systems and interfaces. This memo replaces the objects 44 originally defined in the ifTestGroup of RFC1573, the IF-MIB [6], 45 which have been deprecated. 47 This memo specifies a MIB module in a manner that is both compliant 48 to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 49 definitions. 51 This memo does not specify a standard for the Internet community. 53 1. The SNMP Network Management Framework 55 The SNMP Network Management Framework presently consists of three 56 major components. They are: 58 o the SMI, described in RFC 1902 [1] - the mechanisms used for 59 describing and naming objects for the purpose of management. 61 o the MIB-II, STD 17, RFC 1213 [2] - the core set of managed 62 objects for the Internet suite of protocols. 64 o the protocol, RFC 1157 [3] and/or RFC 1905 [4], - the protocol 65 for accessing managed objects. 67 The Framework permits new objects to be defined for the purpose of 68 experimentation and evaluation. 70 1.1. Object Definitions 72 Managed objects are accessed via a virtual information store, termed 73 the Management Information Base or MIB. Objects in the MIB are 74 defined using the subset of Abstract Syntax Notation One (ASN.1) 75 defined in the SMI. In particular, each object type is named by an 76 OBJECT IDENTIFIER, an administratively assigned name. The object 77 type together with an object instance serves to uniquely identify a 78 specific instantiation of the object. For human convenience, we 79 often use a textual string, termed the descriptor, to also refer to 80 the object type. 82 2. Experience with the Interfaces Test Group 84 The ifTestGroup of objects defined in RFC1573 has not been used 85 widely. Some cited problems were: 87 o Few standard tests had been defined to date. 89 o Some well known tests had already been written on a media- 90 specific basis, e.g., DS1 loopback. 92 o The ifTestGroup allowed for interface testing only. 94 o A logging capability was missing. 96 As a result, the ifTestGroup and associated ifTestTable have been 97 deprecated. However, since renewed interest was expressed in a 98 generic testing capability, specifically in the development of MIBs 99 for managing Asynchronous Transfer Mode interfaces, a set of 100 requirements have been defined that form the basis for the design of 101 the generic Test MIB defined in this memo. 103 3. Requirements for a Generic Test MIB 105 This section describes the requirements that have been identified for 106 a generic test MIB. 108 3.1. Test Identification 110 The system defined in RFC1573 to identify tests relies on OBJECT 111 IDENTIFIERs. This system is flexible in that it allows additional 112 tests to be defined over time and autonomously by vendors, removing 113 the need to register test types in a single place. This mechanism for 114 test identification has been retained. 116 3.2. Test Targets 118 With the advent of an increasing number of non-interface related MIB 119 modules it is desirable to define a test capability that allows 120 testing of interfaces and non-interface physical entities. The 121 following possibilities were considered: 123 a) Separate test capabilities for interface tests and other tests. 125 b) The use of a single test capability where the test target would 126 be defined within the test table. 128 This memo uses the latter approach and uses an object with the syntax 129 RowPointer to identify test targets. (Initially, the use of the 130 Entity MIB was considered for identification of test targets, but 131 this was abandoned because this would require support of the Entity 132 MIB for testing purposes.) 134 Tests are listed in the testTable. The entries in the testTable are 135 distinguished through the value of a simple integer called testIndex. 137 3.3. Logging Results 139 A logging capability of test results serves to store the test results 140 for some period of time. Two mechanisms were considered: 142 1) Separate the test capability and the log. 144 2) Combine the test capability and the log in a single table. 146 Note that searching criteria on the log relate to this choice as 147 well. 149 The log length is necessarily limited. The following choices were 150 considered: 152 1) Age the entries. 154 2) Limit by the number of entries. 156 3) A system that allows either 1) or 2). 158 This MIB module chooses a system where the test and logging 159 capability have been combined in a single table (testTable). The log 160 length is limited by a read-write object (testTableMaxSize). 162 This MIB module also defines a notification, testComplete, which 163 contains the same information as the log entry. Therefore, an agent 164 with limited resources can limit the maximum size of the log to a 165 very few number of entries and rely on a management application to 166 receive and log the testComplete notifications. 168 3.4. Log Searching 170 Efficient searching in a log is a key to its effectiveness. The 171 following possibilities were considered: 173 a) Sort on age of the entries. 175 b) Sort on test type. 177 c) Sort on combinations of the above. 179 This MIB module chooses for the index testIndex, which is an integer 180 identifier for an invocation of a test. To obtain a new testIndex a 181 manager retrieves the value of testIndexNext. Each time this object 182 is read the next lower available value is provided. This addresses 183 the requests that are expected to be most common: 185 o What is the result of test (testIndex)? 187 o What are the results of the last n tests? 189 Since the testIndex has been defined as decreasing, this approach 190 will order log entries by time, newest to oldest. The possibility of 191 testId wrapping is minimized by having it restart at its maximum 192 value and when the agent restarts. When a manager is interested in a 193 specific test, a specific get-request may be issued. When a manager 194 is interested in the latest n tests for the system, getnext/bulk 195 starting from (testIndex) provides the approximate answer. 197 3.5. Determining Agent Test Capabilities 199 A testCapabilitiesTable has been defined to list the tests that can 200 be performed through this agent. 202 4. Definitions 204 TEST-MIB DEFINITIONS ::= BEGIN 206 IMPORTS 207 MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, 208 experimental, NOTIFICATION-TYPE, mib-2 209 FROM SNMPv2-SMI 210 AutonomousType, RowPointer, TimeStamp, RowStatus 211 FROM SNMPv2-TC 212 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 213 FROM SNMPv2-CONF 214 OwnerString 215 FROM IF-MIB 216 ; 218 testMIB MODULE-IDENTITY 219 LAST-UPDATED "9706031200Z" 220 ORGANIZATION "IETF IFMIB Working Group" 221 CONTACT-INFO 222 "Keith McCloghrie 223 Postal: Cisco Systems 224 170 West Tasman Drive 225 San Jose, CA 95134 226 US 227 Tel: +1 408 526 5260 228 E-mail: kzm@cisco.com 230 Kaj Tesink 231 Postal: Bell Communications Research 232 331 Newman Springs Road 233 Red Bank, NJ 07701 234 US 235 Tel: +1 908 758 5254 236 E-mail: kaj@cc.bellcore.com 238 Maria Greene 239 Postal: Ascom Nexion 240 289 Great Road 241 Acton, MA 01720 242 US 243 Tel: +1 508 266 4570 244 E-mail: greene@nexen.com" 245 DESCRIPTION 246 "This MIB module provides a generic test 247 capability." 248 -- ******** NOTE TO THE RFC EDITOR ************** 249 -- In case this module is put on the standards track 250 -- replace the following: 251 -- "::= {experimental XX}" with 252 -- "::= { mib-2 YY }" 253 ::= { experimental XX } 255 testMIBObjects OBJECT IDENTIFIER ::= { testMIB 1 } 257 testIndexNext OBJECT-TYPE 258 SYNTAX INTEGER (0..2147483647) 259 MAX-ACCESS read-only 260 STATUS current 261 DESCRIPTION 262 "This object contains an appropriate value to 263 be used for testIndex when creating 264 entries in the testTable. The value 265 0 indicates that no unassigned entries are 266 available. To obtain the testIndex 267 value for a new entry, the manager issues a 268 management protocol retrieval operation to obtain 269 the current value of this object. After each 270 retrieval, the agent should modify the value to 271 the next lower unassigned index. If the agent is 272 restarted this object shall be set to its highest value." 273 ::= { testMIBObjects 1 } 275 -- The Test Table 277 testTable OBJECT-TYPE 278 SYNTAX SEQUENCE OF TestEntry 279 MAX-ACCESS not-accessible 280 STATUS current 281 DESCRIPTION 282 "This table is used to initiate tests. An entry 283 in this table corresponds to an instance of a test. 284 A test is invoked by creating a row with the 285 appropriate test attributes and using testRowStatus 286 to start a test. 287 After invoking a test, 288 the object testResult can be read to determine the 289 outcome. If an agent can not perform the test, 290 testResult is set accordingly. The testCode can 291 be used to provide further test-specific or entity- 292 specific (or even enterprise-specific) information 293 concerning the outcome of the test. Only one test can 294 be in progress on each entity at any one time. If one 295 test is in progress when another test is invoked, the 296 second test is rejected. Some agents may reject a test 297 when a prior test is active on another entity. 299 Before starting a test, a manager-station must first 300 obtain 'ownership' of the entry in the testTable for 301 the entity to be tested. This is accomplished by 302 retrieving the value of testIndexNext. This value 303 entitles the manager to create a row in the testTable 304 with the value of testIndex being equal to the 305 retrieved value of testIndexNext. 307 Once ownership is obtained, the test parameters can be 308 setup, and then the test is initiated by activating the 309 row through testRowStatus. The agent sets the value 310 of testResult to 'inProgress'. 311 On completion of the test, the agent sets testResult 312 and testCode in accordance with the test results and 313 sets the testCompletionTime. 315 If testRowStatus is not set to active within an 316 abnormally long period 317 of time after ownership is obtained, the agent should 318 time-out the manager, and reset the value of the 319 testRowStatus object back to 'destroy'. It is suggested 320 that this time-out period be 5 minutes. 322 In general, a management station must not retransmit a 323 request to invoke a test for which it does not receive a 324 response; instead, it properly inspects an agent's MIB 325 to determine if the invocation was successful. Only if 326 the invocation was unsuccessful, is the invocation 327 request retransmitted. 329 Some tests may require the entity to be taken off- line 330 in order to execute them, or may even require the agent 331 to reboot after completion of the test. In these 332 circumstances, communication with the management station 333 invoking the test may be lost until after completion of 334 the test. An agent is not required to support such 335 tests. However, if such tests are supported, then the 336 agent should make every effort to transmit a response to 337 the request which invoked the test prior to losing 338 communication. When the agent is restored to normal 339 service, the results of the test are properly made 340 available in the appropriate objects. Note that this 341 requires that the testIndex value assigned to an entity 342 must be unchanged even if the test causes a reboot. An 343 agent must reject any test for which it cannot, perhaps 344 due to resource constraints, make available at least the 345 minimum amount of information after that test 346 completes." 347 ::= { testMIBObjects 2 } 349 testEntry OBJECT-TYPE 350 SYNTAX TestEntry 351 MAX-ACCESS not-accessible 352 STATUS current 353 DESCRIPTION 354 "An entry containing objects for invoking a test." 355 INDEX { testIndex } 356 ::= { testTable 1 } 358 TestEntry ::= 359 SEQUENCE { 360 testIndex Unsigned32, 361 testTarget RowPointer, 362 testMoreInfo OCTET STRING, 363 testType AutonomousType, 364 testCompletionTime TimeStamp, 365 testResult INTEGER, 366 testCode OBJECT IDENTIFIER, 367 testOwner OwnerString, 368 testRowStatus RowStatus } 370 testIndex OBJECT-TYPE 371 SYNTAX Unsigned32 372 MAX-ACCESS not-accessible 374 STATUS current 375 DESCRIPTION 376 "The index of this table." 377 ::= { testEntry 1 } 379 testTarget OBJECT-TYPE 380 SYNTAX RowPointer 381 MAX-ACCESS read-create 382 STATUS current 383 DESCRIPTION 384 "The target of the test. An example of a test target is 385 an instance of an interface, identified by the OID 386 'ifIndex.17'." 388 DEFVAL { { 0 0 } } 389 ::= { testEntry 2 } 391 testMoreInfo OBJECT-TYPE 392 SYNTAX OCTET STRING 393 MAX-ACCESS read-create 394 STATUS current 395 DESCRIPTION 396 "Additional information for the test." 397 DEFVAL { "" } 398 ::= { testEntry 3 } 400 testType OBJECT-TYPE 401 SYNTAX AutonomousType 402 MAX-ACCESS read-create 403 STATUS current 404 DESCRIPTION 405 "The identifier that specifies the test. 406 OBJECT IDENTIFIER values assigned to tests 407 are defined elsewhere, in association with 408 specific types of entity. 409 However, this document assigns a value for a full- 410 duplex loopback test, and defines the special meanings 411 of the subject identifier: 413 noTest OBJECT IDENTIFIER ::= { 0 0 } 415 When the value noTest is written to this object, no 416 action is taken. " 417 DEFVAL { { 0 0 } } 418 ::= { testEntry 4 } 420 testCompletionTime OBJECT-TYPE 421 SYNTAX TimeStamp 422 MAX-ACCESS read-only 423 STATUS current 424 DESCRIPTION 425 "The value of sysUpTime when the test completed." 426 ::= { testEntry 5 } 428 testResult OBJECT-TYPE 429 SYNTAX INTEGER { 430 none(1), -- no test yet requested 431 success(2), 432 inProgress(3), 433 notSupported(4), 434 unAbleToRun(5), -- due to state of system 435 aborted(6), 436 failed(7) 437 } 438 MAX-ACCESS read-only 439 STATUS current 440 DESCRIPTION 441 "This object contains the result of the most recently 442 requested test, or the value 'none(1)' if no test 443 has been started yet." 444 DEFVAL { none } 445 ::= { testEntry 6 } 447 testCode OBJECT-TYPE 448 SYNTAX OBJECT IDENTIFIER 449 MAX-ACCESS read-only 450 STATUS current 451 DESCRIPTION 452 "This object contains a code which contains more specific 453 information on the test result, for example an error-code 454 after a failed test or a result value such as round trip 455 time for a 'ping' test. Error codes and other values this 456 object may take are specific to the type of entity and/or 457 test. The value may have the semantics of AutonomousType, 458 InstancePointer, RowPointer or VariablePointer textual 459 conventions as defined in RFC 1903. The identifier: 461 testCodeNone OBJECT IDENTIFIER ::= { 0 0 } 463 is defined for use if no additional result code is 465 available." 466 DEFVAL { { 0 0 } } 467 ::= { testEntry 7 } 469 testOwner OBJECT-TYPE 470 SYNTAX OwnerString 471 MAX-ACCESS read-create 472 STATUS current 473 DESCRIPTION 474 "The manager which currently has the 'ownership' 475 required to invoke a test on this entity." 476 ::= { testEntry 8 } 478 testRowStatus OBJECT-TYPE 479 SYNTAX RowStatus 480 MAX-ACCESS read-create 481 STATUS current 482 DESCRIPTION 483 "The status of the test: 484 - When the manager activates the row the test 485 is started. 486 - When the test is completed the row will remain 487 active or may be destroyed by the manager. 488 - Details of ongoing or just completed tests are 489 reported in testResult and testCode. 490 - A manager may abort ongoing tests or remove 491 completed test information by setting the 492 row status to notInService or destroy." 493 DEFVAL { active } 494 ::= { testEntry 9 } 496 -- Table size 498 testTableMaxSize OBJECT-TYPE 499 SYNTAX Unsigned32 (10..4294967295) 500 MAX-ACCESS read-write 501 STATUS current 502 DESCRIPTION 503 "The maximum number entries in the testTable. When the 504 table reaches this size the oldest entries will be discarded 505 when new entries are added. The table is flushed when the 506 agent is reset." 507 ::= { testMIBObjects 3 } 509 -- Test Capabilities Table 511 testCapabilitiesTable OBJECT-TYPE 512 SYNTAX SEQUENCE OF TestCapabilitiesEntry 513 MAX-ACCESS not-accessible 514 STATUS current 515 DESCRIPTION 516 "This table contains the test that this entity 517 is able to invoke." 518 ::= { testMIBObjects 4 } 520 testCapabilitiesEntry OBJECT-TYPE 521 SYNTAX TestCapabilitiesEntry 522 MAX-ACCESS not-accessible 523 STATUS current 524 DESCRIPTION 525 "Each entry in this table represents a test." 526 INDEX { testCapabilitiesIndex } 527 ::= { testCapabilitiesTable 1 } 529 TestCapabilitiesEntry ::= 530 SEQUENCE { 531 testCapabilitiesIndex Unsigned32, 532 testCapabilitiesType AutonomousType 533 } 535 testCapabilitiesIndex OBJECT-TYPE 536 SYNTAX Unsigned32 537 MAX-ACCESS not-accessible 538 STATUS current 539 DESCRIPTION 540 "An integer index that uniquely identifies the entry." 541 ::= { testCapabilitiesEntry 1 } 543 testCapabilitiesType OBJECT-TYPE 544 SYNTAX AutonomousType 545 MAX-ACCESS read-only 546 STATUS current 547 DESCRIPTION 548 "The type of test that can be invoked." 549 ::= { testCapabilitiesEntry 2 } 551 -- Notifications 553 testMIBNotifications OBJECT IDENTIFIER ::= { testMIB 0 } 555 testComplete NOTIFICATION-TYPE 556 OBJECTS { 557 testIndex, 558 testTarget, 559 testMoreInfo, 560 testType, 561 testResult, 562 testCode, 563 testOwner } 564 STATUS current 565 DESCRIPTION 566 "A testComplete trap signifies that a test has completed for 567 a particular entity. If the testCode has the semantics of 568 a VariablePointer, the variable it points at will also be 569 included in the objects list." 570 ::= { testMIBNotifications 1 } 572 -- Conformance Information 573 testMIBConformance OBJECT IDENTIFIER ::= { testMIB 3 } 575 testMIBGroups OBJECT IDENTIFIER 576 ::= { testMIBConformance 1 } 578 testMIBCompliances OBJECT IDENTIFIER 579 ::= { testMIBConformance 2 } 581 -- Compliance Statements 583 testMIBCompliance MODULE-COMPLIANCE 584 STATUS current 585 DESCRIPTION 586 "The compliance statement for SNMP agents which support generic 587 testing capabilities." 589 MODULE -- this module 591 MANDATORY-GROUPS { testMIBGroup, testNotificationGroup } 593 OBJECT testMaxSize 594 MIN-ACCESS read-only 595 DESCRIPTION 596 "Write access is not required." 598 ::= { testMIBCompliances 1 } 600 -- Units of Conformance 602 testMIBGroup OBJECT-GROUP 603 OBJECTS { 604 testIndexNext, 605 testTarget, 606 testMoreInfo, 607 testType, 608 testCompletionTime, 609 testResult, 610 testCode, 611 testOwner, 612 testRowStatus, 613 testTableMaxSize, 614 testCapabilitiesType 615 } 616 STATUS current 617 DESCRIPTION 618 "A collection of objects providing a generic 619 test capability." 620 ::= { testMIBGroups 1 } 622 testNotificationGroup NOTIFICATION-GROUP 623 NOTIFICATIONS { 624 testComplete 625 } 626 STATUS current 627 DESCRIPTION 628 "The notifications used to indicate test completion." 629 ::= { testMIBGroups 2 } 631 END 633 5. Acknowledgments 635 This document is a product of the IETF's Interfaces MIB Working 637 Group. 639 The original ifTestTable was the work of Keith McCloghrie (Cisco) and 640 Frank Kastenholz (FTP Software) and has been used in this further 641 evolution. 643 The authors would like to acknowledge the following individuals for 644 their input on requirements: 646 James Watt (Newbridge) 647 Dave Fowler (Newbridge) 648 Steven Buchko (Newbridge) 649 Milt Rosslinsky (ACC) 650 Dawn Xie (Lucent) 651 Chris Martin (Netedge) 653 6. References 655 [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 656 S. Waldbusser, "Structure of Management Information for Version 2 657 of the Simple Network Management Protocol (SNMPv2)", RFC1902, SNMP 658 Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 659 International Network Services, January 1996. 661 [2] McCloghrie, K., and M. Rose, Editors, "Management Information Base 662 for Network Management of TCP/IP-based internets: MIB-II", STD 17, 663 RFC 1213, Hughes LAN Systems, Performance Systems International, 664 March 1991. 666 [3] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 667 Management Protocol", RFC 1157, SNMP Research, Performance Systems 668 International, Performance Systems International, MIT Laboratory 669 for Computer Science, May 1990. 671 [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 673 S. Waldbusser, "Protocol Operations for Version 2 of the Simple 674 Network Management Protocol (SNMPv2)", RFC1905, SNMP Research,Inc., 675 Cisco Systems, Inc., Dover Beach Consulting, Inc., International 676 Network Services, January 1996. 678 [5] McCloghrie, K., and A. Bierman, Editors, "Entity MIB", RFC2037, 679 Cisco Systems, January 1996. 681 [6] Kastenholz, F., "Definitions of Managed Objects for the Ethernet- 682 like Interface Types using SMIv2", RFC1650, FTP Software, Inc, 683 August 1994. 685 [6] McCloghrie, K., Kastenholz, F., "Evolution of the Interfaces Group 686 of MIB-II", RFC1573, (should be updated to new IF-MIB RFC#) Cisco 687 Systems, Inc., FTP Software, January 1994. 689 [7] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 690 S. Waldbusser, "Textual Conventions for Version 2 of the Simple 691 Network Management Protocol (SNMPv2)", RFC1903, SNMP Research,Inc., 692 Cisco Systems, Inc., Dover Beach Consulting, Inc., International 693 Network Services, January 1996. 695 7. Security Considerations 697 Security issues are not discussed in this memo. 699 8. Authors' Addresses 701 Maria Greene 702 Ascom Nexion 703 289 Great Road 704 Acton, MA 01720-4739 705 Phone: (508) 266-4570 706 EMail: greene@nexen.com 708 Keith McCloghrie 709 Cisco Systems 710 170 West Tasman Drive 711 San Jose, CA 95134 712 Phone: (408) 526-5260 713 E-mail: kzm@cisco.com 715 Kaj Tesink 716 Bell Communications Research 717 Room 1A-427 718 331 Newman Springs Road 719 P.O. Box 7020 720 Red Bank, NJ 07701-7020 721 Phone: (908) 758-5254 722 EMail: kaj@cc.bellcore.com 724 Table of Contents 726 1 The SNMP Network Management Framework ........................ 2 727 1.1 Object Definitions ......................................... 2 728 2 Experience with the Interfaces Test Group .................... 3 729 3 Requirements for a Generic Test MIB .......................... 3 730 3.1 Test Identification ........................................ 3 731 3.2 Test Targets ............................................... 4 732 3.3 Logging Results ............................................ 5 733 3.4 Log Searching .............................................. 5 734 3.5 Determining Agent Test Capabilities ........................ 6 735 4 Definitions .................................................. 7 736 5 Acknowledgments .............................................. 16 737 6 References ................................................... 17 739 7 Security Considerations ...................................... 18 740 8 Authors' Addresses ........................................... 18