INTERNET-DRAFT System/Interface Test MIB April 7, 1999
Definitions of Managed Objects for
System and Interface Testing
April 7, 1999
Internet-Draft <draft-ietf-ifmib-testmib-05.txt>
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 October 7, 1999 [Page 1]
INTERNET-DRAFT System/Interface Test MIB April 7, 1999
Copyright (C) The Internet Society (1998). 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[16] which have been deprecated.
Expires October 7, 1999 [Page 2]
INTERNET-DRAFT System/Interface Test MIB April 7, 1999
3. The SNMP Network Management Framework
The SNMP Management Framework presently consists of five major
components:
0 An overall architecture, described in RFC 2271 [1].
0 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 RFC 1155 [2], RFC 1212 [3] and RFC 1215
[4]. The second version, called SMIv2, is described in
RFC 1902 [5], RFC 1903 [6] and RFC 1904 [7].
0 Message protocols for transferring management
information. The first version of the SNMP message
protocol is called SNMPv1 and described in RFC 1157 [8].
A second version of the SNMP message protocol, which is
not an Internet standards track protocol, is called
SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10].
The third version of the message protocol is called
SNMPv3 and described in RFC 1906 [10], RFC 2272 [11] and
RFC 2274 [12].
0 Protocol operations for accessing management information.
The first set of protocol operations and associated PDU
formats is described in RFC 1157 [8]. A second set of
protocol operations and associated PDU formats is
described in RFC 1905 [13].
0 A set of fundamental applications described in RFC 2273
[14] and the view-based access control mechanism
described in RFC 2275 [15].
Managed objects are accessed via a virtual information store,
termed the Management Information Base or MIB. 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 (e.g.,
use of Counter64). Some machine readable information in SMIv2
will be converted into textual descriptions in SMIv1 during
Expires October 7, 1999 [Page 3]
INTERNET-DRAFT System/Interface Test MIB April 7, 1999
the translation process. However, this loss of machine
readable information is not considered to change the semantics
of the MIB.
Expires October 7, 1999 [Page 4]
INTERNET-DRAFT System/Interface Test MIB April 7, 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 October 7, 1999 [Page 5]
INTERNET-DRAFT System/Interface Test MIB April 7, 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[17] 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.
3) A system that allows either 1) or 2).
Expires October 7, 1999 [Page 6]
INTERNET-DRAFT System/Interface Test MIB April 7, 1999
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 October 7, 1999 [Page 7]
INTERNET-DRAFT System/Interface Test MIB April 7, 1999
5.5. Determining Agent Test Capabilities
A testCapabilityTable has been defined to list the tests that
can be performed through this agent.
Expires October 7, 1999 [Page 8]
INTERNET-DRAFT System/Interface Test MIB April 7, 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
OwnerString
FROM IF-MIB
;
testMIB MODULE-IDENTITY
LAST-UPDATED "9904071200Z"
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 October 7, 1999 [Page 9]
INTERNET-DRAFT System/Interface Test MIB April 7, 1999
capability."
::= { mib-2 YY }
-- ******** NOTE TO THE RFC EDITOR AND IANA *********
-- * In case this module is put on the standards track
-- * 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
testTable OBJECT-TYPE
SYNTAX SEQUENCE OF TestEntry
MAX-ACCESS not-accessible
Expires October 7, 1999 [Page 10]
INTERNET-DRAFT System/Interface Test MIB April 7, 1999
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 (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.
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. Then the test is initiated by setting the
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
Expires October 7, 1999 [Page 11]
INTERNET-DRAFT System/Interface Test MIB April 7, 1999
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 }
::= { testTable 1 }
TestEntry ::=
SEQUENCE {
testIndex Unsigned32,
testTarget RowPointer,
testType AutonomousType,
testMoreInfo OCTET STRING,
testResultTimeStamp TimeStamp,
testResult INTEGER,
testCode OBJECT IDENTIFIER,
Expires October 7, 1999 [Page 12]
INTERNET-DRAFT System/Interface Test MIB April 7, 1999
testOwner OwnerString,
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
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
Expires October 7, 1999 [Page 13]
INTERNET-DRAFT System/Interface Test MIB April 7, 1999
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 }
::= { 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
Expires October 7, 1999 [Page 14]
INTERNET-DRAFT System/Interface Test MIB April 7, 1999
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 OwnerString
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
"The row status of the test information.
A row must be active before tests can be
activiated. Deactivating a row will abort any
ongoing test associated with that row.
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.
Expires October 7, 1999 [Page 15]
INTERNET-DRAFT System/Interface Test MIB April 7, 1999
- 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 { createAndWait }
::= { 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
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
Expires October 7, 1999 [Page 16]
INTERNET-DRAFT System/Interface Test MIB April 7, 1999
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
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
OBJECTS {
testTarget,
testType,
testMoreInfo,
testResult,
testCode,
testOwner }
STATUS current
DESCRIPTION
"A testComplete trap signifies that a test has completed for
Expires October 7, 1999 [Page 17]
INTERNET-DRAFT System/Interface Test MIB April 7, 1999
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 }
-- Units of Conformance
testMIBGroup OBJECT-GROUP
OBJECTS {
testIndexNext,
testTarget,
testType,
testMoreInfo,
Expires October 7, 1999 [Page 18]
INTERNET-DRAFT System/Interface Test MIB April 7, 1999
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 October 7, 1999 [Page 19]
INTERNET-DRAFT System/Interface Test MIB April 7, 1999
7. 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)
Expires October 7, 1999 [Page 20]
INTERNET-DRAFT System/Interface Test MIB April 7, 1999
8. References
[1] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing SNMP Management Frameworks",
RFC 2271, Cabletron Systems, Inc., BMC Software, Inc.,
IBM T. J. Watson Research, January 1998
[2] Rose, M., and K. McCloghrie, "Structure and
Identification of Management Information for TCP/IP-based
Internets", RFC 1155, Performance Systems International,
Hughes LAN Systems, May 1990
[3] Rose, M., and K. McCloghrie, "Concise MIB Definitions",
RFC 1212, Performance Systems International, Hughes LAN
Systems, March 1991
[4] M. Rose, "A Convention for Defining Traps for use with
the SNMP", RFC 1215, Performance Systems International,
March 1991
[5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.,
and S. Waldbusser, "Structure of Management Information
for Version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1902, SNMP Research,Inc., Cisco Systems,
Inc., Dover Beach Consulting, Inc., International Network
Services, January 1996.
[6] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.,
and S. Waldbusser, "Textual Conventions for Version 2 of
the Simple Network Management Protocol (SNMPv2)", RFC
1903, SNMP Research, Inc., Cisco Systems, Inc., Dover
Beach Consulting, Inc., International Network Services,
January 1996.
[7] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.,
and S. Waldbusser, "Conformance Statements for Version 2
of the Simple Network Management Protocol (SNMPv2)", RFC
1904, SNMP Research, Inc., Cisco Systems, Inc., Dover
Beach Consulting, Inc., International Network Services,
January 1996.
[8] Case, J., Fedor, M., Schoffstall, M., and J. Davin,
"Simple Network Management Protocol", RFC 1157, SNMP
Research, Performance Systems International, Performance
Systems International, MIT Laboratory for Computer
Expires October 7, 1999 [Page 21]
INTERNET-DRAFT System/Interface Test MIB April 7, 1999
Science, May 1990.
[9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.,
and S. Waldbusser, "Introduction to Community-based
SNMPv2", RFC 1901, SNMP Research, Inc., Cisco Systems,
Inc., Dover Beach Consulting, Inc., International Network
Services, January 1996.
[10] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.,
and S. Waldbusser, "Transport Mappings for Version 2 of
the Simple Network Management Protocol (SNMPv2)", RFC
1906, SNMP Research, Inc., Cisco Systems, Inc., Dover
Beach Consulting, Inc., International Network Services,
January 1996.
[11] Case, J., Harrington D., Presuhn R., and B. Wijnen,
"Message Processing and Dispatching for the Simple
Network Management Protocol (SNMP)", RFC 2272, SNMP
Research, Inc., Cabletron Systems, Inc., BMC Software,
Inc., IBM T. J. Watson Research, January 1998.
[12] Blumenthal, U., and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", RFC 2274, IBM T. J. Watson Research,
January 1998.
[13] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.,
and S. Waldbusser, "Protocol Operations for Version 2 of
the Simple Network Management Protocol (SNMPv2)", RFC
1905, SNMP Research, Inc., Cisco Systems, Inc., Dover
Beach Consulting, Inc., International Network Services,
January 1996.
[14] Levi, D., Meyer, P., and B. Stewart, SNMPv3
Applications", RFC 2273, SNMP Research, Inc., Secure
Computing Corporation, Cisco Systems, January 1998.
[15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", RFC 2275, IBM T. J. Watson
Research, BMC Software, Inc., Cisco Systems, Inc.,
January 1998.
Expires October 7, 1999 [Page 22]
INTERNET-DRAFT System/Interface Test MIB April 7, 1999
[16] McCloghrie, K., Kastenholz, F., " The Interfaces Group
MIB using SMIv2", RFC2233, Cisco Systems, Inc., FTP
Software, November 1997.
[17] McCloghrie, K., and A. Bierman, Editors, "Entity MIB",
RFC2037, Cisco Systems, January 1996.
Expires October 7, 1999 [Page 23]
INTERNET-DRAFT System/Interface Test MIB April 7, 1999
9. 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 2274 [12] and the
View-based Access Control Model RFC 2275 [15] 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 October 7, 1999 [Page 24]
INTERNET-DRAFT System/Interface Test MIB April 7, 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 to make a suitable OBJECT IDENTIFIER
assignment for YY below and update the following in the MIB:
::= { mib-2 YY }
-- ******** NOTE TO THE RFC EDITOR AND IANA *********
-- * In case this module is put on the standards track
-- * assign a suitable value to YY by IANA
-- * and remove this notice from the MIB
Expires October 7, 1999 [Page 25]
INTERNET-DRAFT System/Interface Test MIB April 7, 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 October 7, 1999 [Page 26]
INTERNET-DRAFT System/Interface Test MIB April 7, 1999
13. Full Copyright Statement
Copyright (C) The Internet Society (1998). 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 October 7, 1999 [Page 27]
INTERNET-DRAFT System/Interface Test MIB April 7, 1999
Table of Contents
1 Status of this Memo ................................... 1
2 Abstract .............................................. 2
3 The SNMP Network 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 Acknowledgments ....................................... 20
8 References ............................................ 21
9 Security Considerations ............................... 24
10 Authors' Addresses ................................... 25
11 RFC Editor and IANA Considerations ................... 25
12 Intellectual Property ................................ 26
13 Full Copyright Statement ............................. 27
Expires October 7, 1999 [Page 28]
