INTERNET-DRAFT System/Interface Test MIB November 28, 1999 Definitions of Managed Objects for System and Interface Testing November 28, 1999 Internet-Draft Maria Greene Xedia Corp. maria@xedia.com Keith McCloghrie Cisco Systems kzm@cisco.com Kaj Tesink Telcordia Technologies kaj@research.telcordia.com 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Expires May 28, 2000 [Page 1] INTERNET-DRAFT System/Interface Test MIB November 28, 1999 Copyright (C) The Internet Society (1999). All Rights Reserved. 2. Abstract This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for testing systems and interfaces. This memo defines the following: 0 A general mechanism to initiate tests 0 A capability to provide and store test results 0 A capability to inventory the tests that are supported by an agent This memo does not specify individual tests. Such tests are subject of separate system- or media-specific specifications. This memo replaces the objects defined in the ifTestGroup of RFC2233[RFC2233] which have been deprecated. Expires May 28, 2000 [Page 2] INTERNET-DRAFT System/Interface Test MIB November 28, 1999 3. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Expires May 28, 2000 [Page 3] INTERNET-DRAFT System/Interface Test MIB November 28, 1999 Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. Expires May 28, 2000 [Page 4] INTERNET-DRAFT System/Interface Test MIB November 28, 1999 4. Experience with the Interfaces Test Group The ifTestGroup of objects defined in RFC2233 has not been used widely. Some cited problems were: 0 Few standard tests had been defined to date. 0 Some well known tests had already been written on a media-specific basis, e.g., DS1 loopback. The ifTestGroup allowed for interface testing only. 0 A logging capability was missing. As a result, the ifTestGroup and associated ifTestTable have been deprecated. However, since renewed interest was expressed in a generic testing capability, specifically in the development of MIBs for managing Asynchronous Transfer Mode interfaces, a set of requirements have been defined that form the basis for the design of the generic Test MIB defined in this memo. 5. Requirements for a Generic Test MIB This section describes the requirements that have been identified for a generic test MIB. 5.1. Test Identification The system defined in RFC2233 to identify tests relies on OBJECT IDENTIFIERs. This system is flexible in that it allows additional tests to be defined over time and autonomously by vendors, removing the need to register test types in a single place. This mechanism for test identification has been retained. Expires May 28, 2000 [Page 5] INTERNET-DRAFT System/Interface Test MIB November 28, 1999 5.2. Test Targets With the advent of an increasing number of non-interface related MIB modules it is desirable to define a test capability that allows testing of interfaces and non-interface physical entities. The following possibilities were considered: a) Separate test capabilities for interface tests and other tests. b) The use of a single test capability where the test target would be defined within the test table. This memo uses the latter approach and uses an object with the syntax RowPointer to identify test targets. (Initially, the use of the Entity MIB[RFC2037] was considered for identification of test targets, but this was abandoned because this would require support of the Entity MIB for testing purposes.) Tests are listed in the testTable. The entries in the testTable are distinguished through the value of a simple integer called testIndex. 5.3. Logging Results A logging capability of test results serves to store the test results for some period of time. Two mechanisms were considered: 1) Separate the test capability and the log. 2) Combine the test capability and the log in a single table. The log length is necessarily limited. The following choices were considered: 1) Age the entries. 2) Limit by the number of entries. Expires May 28, 2000 [Page 6] INTERNET-DRAFT System/Interface Test MIB November 28, 1999 3) A system that allows either 1) or 2). For efficiency reasons this MIB module chooses a system where the test and logging capability have been combined in a single table (testTable). The log length is limited by a read-write object (testTableMaxSize). This MIB module also defines a notification, testComplete, which contains the same information as the log entry. Therefore, an agent with limited resources can limit the maximum size of the log to a very few number of entries and rely on a management application to receive and log the testComplete notifications. 5.4. Log Searching Efficient searching in a log is a key to its effectiveness. The following possibilities were considered: a) Sort on age of the entries. b) Sort on test type. c) Sort on combinations of the above. This MIB module chooses for the index testIndex, which is an integer identifier for an invocation of a test. To obtain a new testIndex a manager retrieves the value of testIndexNext. Each time this object is read the next lower available value is provided. This addresses the requests that are expected to be most common: 0 What is the result of test (testIndex)? 0 What are the results of the last n tests? Since the testIndex has been defined as decreasing, this approach will order log entries by time, newest to oldest. The possibility of testId wrapping is minimized by having it restart at its maximum value and when the agent restarts. When a manager is interested in a specific test, a specific get- request may be issued. When a manager is interested in the latest n tests for the system, getnext/bulk starting from (testIndex) provides the approximate answer. Expires May 28, 2000 [Page 7] INTERNET-DRAFT System/Interface Test MIB November 28, 1999 5.5. Determining Agent Test Capabilities A testCapabilityTable has been defined to list the tests that can be performed through this agent. Expires May 28, 2000 [Page 8] INTERNET-DRAFT System/Interface Test MIB November 28, 1999 6. Definitions TEST-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, zeroDotZero, NOTIFICATION-TYPE, mib-2 FROM SNMPv2-SMI AutonomousType, RowPointer, TimeStamp, RowStatus FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF SnmpAdminString FROM SNMP-FRAMEWORK-MIB ; testMIB MODULE-IDENTITY LAST-UPDATED "9911281200Z" ORGANIZATION "IETF IFMIB Working Group" CONTACT-INFO "Maria Greene Postal: Xedia Corp. 119 Russell St. Littleton, MA 01460 USA Tel: +1 978 897 1828 E-mail: maria@xedia.com Keith McCloghrie Postal: Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA Tel: +1 408 526 5260 E-mail: kzm@cisco.com Kaj Tesink Postal: Telcordia Technologies 331 Newman Springs Road Red Bank, NJ 07701 USA Tel: +1 732 758 5254 E-mail: kaj@research.telcordia.com" DESCRIPTION "This MIB module provides a generic test Expires May 28, 2000 [Page 9] INTERNET-DRAFT System/Interface Test MIB November 28, 1999 capability." REVISION "9911281200Z" DESCRIPTION "Initial version, published as RFCxxxx" ::= { mib-2 YY } -- ******** NOTE TO THE RFC EDITOR AND IANA ********* -- * In case this module is put on the standards track -- * fill out RFCxxxx with the RFC number of this document -- * assign a suitable value to YY by IANA -- * and remove this notice from the MIB testMIBObjects OBJECT IDENTIFIER ::= { testMIB 1 } testIndexNext OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains an appropriate value to be used for testIndex when creating entries in the testTable. The object is used in order to minimize collisions caused by multiple managers. The value 0 indicates that no unassigned entries are available. To obtain the testIndex value for a new entry, the manager issues a management protocol retrieval operation to obtain the current value of this object. After each retrieval, the agent should modify the value to the next lower unassigned index. If the agent is restarted this object shall be set to its highest value. The agent does not require that retrieved values are actually used in subsequent tests or that they are used in the order of their retrieval. Note that GETNEXT or GETBULK requests for this object will also decrease the value, and so it is quite possible that (large) gaps will occur." ::= { testMIBObjects 1 } -- The Test Table Expires May 28, 2000 [Page 10] INTERNET-DRAFT System/Interface Test MIB November 28, 1999 testTable OBJECT-TYPE SYNTAX SEQUENCE OF TestEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is used to initiate tests and to log test results. An entry in this table corresponds to an instance of a test. A test is invoked by creating a row with the appropriate test attributes and using testRowStatus to start a test. After invoking a test, the object testResult can be read to determine the outcome. If an agent can not perform the test, testResult is set accordingly. The testCode can be used to provide further test-specific or entity- specific (or even enterprise-specific) information concerning the outcome of the test. Only one test can be in progress on each entity at any one time. If one test is in progress when another test is invoked, the second test is rejected (e.g., for an SNMPv2 SET operation an inconsistentValue error is returned). Some agents may reject a test when a prior test is active on another entity. Before starting a test, a manager-station must first obtain 'ownership' of the entry in the testTable for the entity to be tested. This is accomplished by retrieving the value of testIndexNext. This value entitles the manager to create a row in the testTable with the value of testIndex being equal to the retrieved value of testIndexNext and testOwner set to the appropriate value for the manager. A prudent sequence to obtain 'ownership' of a testTable entry and to minimize collisions (e.g., with a manager not following the rules) is as follows: (1) Retrieve testIndexNext; stop if no more values are available (2) Test whether the corresponding testTable entry does exist through a retrieval operation (3) If the entry exists go back to (1), else (4) Once 'ownership' is obtained, the testOwner and test parameters can be setup, by creating a row with the reserved testIndex and appropriate test parameter settings. (5) Then the test is initiated by setting the Expires May 28, 2000 [Page 11] INTERNET-DRAFT System/Interface Test MIB November 28, 1999 testRowStatus to 'active'. The agent sets the value of testResult to 'inProgress'. On completion of the test, the agent sets testResult and testCode in accordance with the test results and sets the testResultTimeStamp. In general, a management station must not retransmit a request to invoke a test for which it does not receive a response; instead, it properly inspects an agent's MIB to determine if the invocation was successful. Only if the invocation was unsuccessful, is the invocation request retransmitted. Some tests may require the entity to be taken off- line in order to execute them, or may even require the agent to reboot after completion of the test. In these circumstances, communication with the management station invoking the test may be lost until after completion of the test. An agent is not required to support such tests. However, if such tests are supported, then the agent should make every effort to transmit a response to the request which invoked the test prior to losing communication. When the agent is restored to normal service, the results of the test are properly made available in the appropriate objects. Note that this requires that the testIndex value assigned to an entity must be unchanged even if the test causes a reboot. An agent must reject any test for which it cannot, perhaps due to resource constraints, make available at least the minimum amount of information after that test completes. Managers are responsible for removing rows that are no longer in use. The table is flushed when the agent is reset." ::= { testMIBObjects 2 } testEntry OBJECT-TYPE SYNTAX TestEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing objects for invoking a test and reporting test results." INDEX { testIndex } Expires May 28, 2000 [Page 12] INTERNET-DRAFT System/Interface Test MIB November 28, 1999 ::= { testTable 1 } TestEntry ::= SEQUENCE { testIndex Unsigned32, testTarget RowPointer, testType AutonomousType, testMoreInfo OCTET STRING, testResultTimeStamp TimeStamp, testResult INTEGER, testCode OBJECT IDENTIFIER, testOwner SnmpAdminString, testRowStatus RowStatus } testIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index of this table." ::= { testEntry 1 } testTarget OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "The target of the test. An example of a test target is an instance of an interface, identified by the OID 'ifIndex.17'. When the value zeroDotZero is written to this object, no action is taken. " DEFVAL { zeroDotZero } ::= { testEntry 2 } testType OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-create STATUS current DESCRIPTION "The identifier that specifies the test. OBJECT IDENTIFIER values assigned to tests are defined elsewhere, in association with specific types of entity. When the value 'zeroDotZero' is written to this Expires May 28, 2000 [Page 13] INTERNET-DRAFT System/Interface Test MIB November 28, 1999 object, no action is taken. Additional information for this test may be specified in testMoreInfo. The value of testType must be one of those listed in the testCapabilityTable." DEFVAL { zeroDotZero } ::= { testEntry 3 } testMoreInfo OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-create STATUS current DESCRIPTION "Additional test-specific information." DEFVAL { "" } ::= { testEntry 4 } testResultTimeStamp OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when a testResult has been reached. When a test is 'inProgress' the value of testResultTimeStamp shall be 0." ::= { testEntry 5 } testResult OBJECT-TYPE SYNTAX INTEGER { none(1), -- no test yet requested success(2), inProgress(3), -- transient state notSupported(4),-- not in testCapabilityTable unAbleToRun(5), -- due to state of system aborted(6), -- by manager action failed(7) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the result of the most recently requested test, or the value 'none' if no test has been started yet." DEFVAL { none } Expires May 28, 2000 [Page 14] INTERNET-DRAFT System/Interface Test MIB November 28, 1999 ::= { testEntry 6 } testCode OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains a code which contains more specific information on the test result, for example an error-code after a failed test or a result value such as round trip time for a 'ping' test. Error codes and other values this object may take are specific to the type of entity and/or test. The value may have the semantics of AutonomousType, RowPointer or VariablePointer textual conventions as defined in RFC 1903. The identifier: testCodeNone OBJECT IDENTIFIER ::= zeroDotZero is defined for use if no additional result code is available." ::= { testEntry 7 } testOwner OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "The manager which currently has the 'ownership' required to invoke a test on this entity, e.g., the manager station's transport address, management station name (e.g., domain name), network management personnel's name, location, or phone number." REFERENCE "McCloghrie, K., Kastenholz, F., The Interfaces Group MIB using SMIv2, RFC2233, Cisco Systems, Inc., FTP Software, November 1997." ::= { testEntry 8 } testRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION Expires May 28, 2000 [Page 15] INTERNET-DRAFT System/Interface Test MIB November 28, 1999 "The row status of the test information. A row must be active before tests can be activiated. Manipulation of the test: - When all test parameters (testTarget, testType, testMoreInfo and testOwner) have been properly set the test is started by setting testRowStatus to 'active'. This causes the testResult to assume the value 'inProgress' until some other value of testResult is reached. - If the manager sets testRowStatus to 'active' while the test is inProgress then this action will not affect the ongoing test. - Details of ongoing or completed tests are reported in testResult and testCode. - After test completion the test may be repeated by first setting testRowStatus to 'notInService', manipulating the test parameters as necessary, and setting the testRowStatus to 'active' again. - A manager may abort ongoing tests or remove completed test information by setting the testRowStatus to 'notInService' or 'destroy'." DEFVAL { notReady } ::= { testEntry 9 } -- Table size testTableMaxSize OBJECT-TYPE SYNTAX Unsigned32 (10..4294967295) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number entries in the testTable. Removal of old entries is the responsibility of the manager. The table is flushed when the agent is reset." ::= { testMIBObjects 3 } -- Test Capability Table testCapabilityTable OBJECT-TYPE SYNTAX SEQUENCE OF TestCapabilityEntry MAX-ACCESS not-accessible Expires May 28, 2000 [Page 16] INTERNET-DRAFT System/Interface Test MIB November 28, 1999 STATUS current DESCRIPTION "This table contains test types (potential values for the testType object) that are supported by this agent." ::= { testMIBObjects 4 } testCapabilityEntry OBJECT-TYPE SYNTAX TestCapabilityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in this table represents a test type." INDEX { testCapabilityIndex } ::= { testCapabilityTable 1 } TestCapabilityEntry ::= SEQUENCE { testCapabilityIndex Unsigned32, testCapabilityType AutonomousType } testCapabilityIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An integer index that uniquely identifies the entry." ::= { testCapabilityEntry 1 } testCapabilityType OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of test that can be invoked." ::= { testCapabilityEntry 2 } -- Notifications testMIBNotifications OBJECT IDENTIFIER ::= { testMIB 0 } testComplete NOTIFICATION-TYPE Expires May 28, 2000 [Page 17] INTERNET-DRAFT System/Interface Test MIB November 28, 1999 OBJECTS { testTarget, testType, testMoreInfo, testResult, testCode, testOwner } STATUS current DESCRIPTION "A testComplete trap signifies that a test has completed for a particular entity. If the testCode has the semantics of a VariablePointer, the variable it points at will also be included in the objects list." ::= { testMIBNotifications 1 } -- Conformance Information testMIBConformance OBJECT IDENTIFIER ::= { testMIB 3 } testMIBGroups OBJECT IDENTIFIER ::= { testMIBConformance 1 } testMIBCompliances OBJECT IDENTIFIER ::= { testMIBConformance 2 } -- Compliance Statements testMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP agents which support generic testing capabilities." MODULE -- this module MANDATORY-GROUPS { testMIBGroup, testNotificationGroup } OBJECT testTableMaxSize MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { testMIBCompliances 1 } Expires May 28, 2000 [Page 18] INTERNET-DRAFT System/Interface Test MIB November 28, 1999 -- Units of Conformance testMIBGroup OBJECT-GROUP OBJECTS { testIndexNext, testTarget, testType, testMoreInfo, testResultTimeStamp, testResult, testCode, testOwner, testRowStatus, testTableMaxSize, testCapabilityType } STATUS current DESCRIPTION "A collection of objects providing a generic test capability." ::= { testMIBGroups 1 } testNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { testComplete } STATUS current DESCRIPTION "The notifications used to indicate test completion." ::= { testMIBGroups 2 } END Expires May 28, 2000 [Page 19] INTERNET-DRAFT System/Interface Test MIB November 28, 1999 7. Security Considerations There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read- create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. The managed objects in this MIB contain sensitive information since, collectively, they allow the invocation of tests on the managed device. These tests may have consequences such as configuration changes, service interruptions, etc. Security considerations for individual tests are discussed in the documents defining such tests. It is thus important to control even GET access to these objects and possibly to even encrypt the values of these object when sending them over the network via SNMP. Not all versions of SNMP provide features for such a secure environment. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [RFC2574] and the View-based Access Control Model RFC 2575 [RFC2575] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Expires May 28, 2000 [Page 20] INTERNET-DRAFT System/Interface Test MIB November 28, 1999 8. Acknowledgments This document is a product of the IETF's Interfaces MIB Working Group. The original ifTestTable was the work of Keith McCloghrie (Cisco) and Frank Kastenholz (FTP Software) and has been used in this further evolution. The authors would like to acknowledge the following individuals for their input on requirements: James Watt (Newbridge) Dave Fowler (Newbridge) Steven Buchko (Newbridge) Milt Rosslinsky (ACC) Dawn Xie (Lucent) Chris Martin (Netedge) Harmen van der Linde (Bellcore) Bert Wijnen (IBM T. J. Watson Research) Expires May 28, 2000 [Page 21] INTERNET-DRAFT System/Interface Test MIB November 28, 1999 9. References [RFC2233] McCloghrie, K., Kastenholz, F., " The Interfaces Group MIB using SMIv2", RFC2233, Cisco Systems, Inc., FTP Software, November 1997. [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999 [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991 [RFC1215] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. Expires May 28, 2000 [Page 22] INTERNET-DRAFT System/Interface Test MIB November 28, 1999 [RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999 [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999 [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999 [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999 [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet- standard Network Management Framework", RFC 2570, April 1999 [RFC2037] McCloghrie, K., and A. Bierman, Editors, "Entity MIB", RFC2037, Cisco Systems, January 1996. Expires May 28, 2000 [Page 23] INTERNET-DRAFT System/Interface Test MIB November 28, 1999 10. Authors' Addresses Maria Greene Xedia Corp. 19 Russell St. Littleton, MA 01460 USA Phone: (978) 897-1828 Email: maria@xedia.com Keith McCloghrie Cisco Systems 170 West Tasman Drive San Jose, CA 95134 Phone: (408) 526-5260 Email: kzm@cisco.com Kaj Tesink Telcordia Technologies 331 Newman Springs Road P.O. Box 7020 Red Bank, NJ 07701-7020 Phone: (732) 758-5254 Email: kaj@research.telcordia.com 11. RFC Editor and IANA Considerations Prior to publication of this memo as an RFC, the RFC Editor and IANA are requested replace xxxx below with the RFC number of this document, to make a suitable OBJECT IDENTIFIER assignment for YY below and update the following in the MIB: DESCRIPTION "Initial version, published as RFCxxxx" ::= { mib-2 YY } -- ******** NOTE TO THE RFC EDITOR AND IANA ********* -- * In case this module is put on the standards track -- * fill out RFCxxxx with the RFC number of this document -- * assign a suitable value to YY by IANA -- * and remove this notice from the MIB Expires May 28, 2000 [Page 24] INTERNET-DRAFT System/Interface Test MIB November 28, 1999 12. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Expires May 28, 2000 [Page 25] INTERNET-DRAFT System/Interface Test MIB November 28, 1999 13. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Expires May 28, 2000 [Page 26] INTERNET-DRAFT System/Interface Test MIB November 28, 1999 Table of Contents 1 Status of this Memo ................................... 1 2 Abstract .............................................. 2 3 The SNMP Management Framework ......................... 3 4 Experience with the Interfaces Test Group ............. 5 5 Requirements for a Generic Test MIB ................... 5 5.1 Test Identification ................................. 5 5.2 Test Targets ........................................ 6 5.3 Logging Results ..................................... 6 5.4 Log Searching ....................................... 7 5.5 Determining Agent Test Capabilities ................. 8 6 Definitions ........................................... 9 7 Security Considerations ............................... 20 8 Acknowledgments ....................................... 21 9 References ............................................ 22 10 Authors' Addresses ................................... 24 11 RFC Editor and IANA Considerations ................... 24 12 Intellectual Property ................................ 25 13 Full Copyright Statement ............................. 26 Expires May 28, 2000 [Page 27]