Subject: Non-member submission from [Kaj Tesink <[email-masked]>]

From: "Ted Brunner 503.627.1317" <[email-masked]>
Date: Mon, 12 Apr 1999 10:51:22 -0700

Ted Brunner		VideoTele.com
			Tektronix
			MS 50-475
[email-masked]	14150 SW Karl Braun
503.627.1317		Beaverton OR 97005	

------- Forwarded Message

Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 09 Apr 1999 20:03:42 -0400
To: [email-masked]
From: Kaj Tesink <[email-masked]>
Subject: Posting of <draft-ietf-ifmib-testmib-05.txt>
Cc: [email-masked], [email-masked]
Mime-Version: 1.0
Content-Type: multipart/mixed;
	boundary="=====================_289749277==_"

- --=====================_289749277==_
Content-Type: text/plain; charset="us-ascii"

Hi,

Please post the attached as draft-ietf-ifmib-testmib-05.txt.

The key changes were as announced on the mailing list. See below. Note that
draft-ietf-atommib-test-05.txt depends on this.
Any final comments?

Thanks,

Kaj

- ---------------------------------

>>
>>comments on draft-ietf-ifmib-testmib-04.txt
>>-------------------------------------------
>>
>>0.typo for testTarget MAX-ACCES  => MAX-ACCESS
>>
>>1.The module name would probably better to be IF-TEST-MIB as opposed
>>  to just TEST-MIB. The latter has too much chance for conflicts.
>>  I think I would accordingly prefix all descriptors with ifTestXxxx
>>  instead of just testXxxx
>
>i have pointed out that this change was made deliberatedly in the past
>to allow non-if tests as well.
>

i have not made further changes on this

>>
>>2.I suggest that the WG decides if they want this on the standards
>>  track or under experimental and then use mib-2 or experimental
>>  accordingly.
>>  And, omit the IMPORT for the one you decide against
>
>standards track process will be followed
>
>>
>>3.For testIndexNext you may want to add a note that each GETNEXT or
>>  GETBULK for this object will also decrease the value, and so it
>>  is quite possible that (large) gaps will occur.
>
>will do
>
>>
>>4.You state that only one test can be active and that invocation of
>>  a second test will be rejected. Such invocation of a second test
>>  is done by setting another row to active (if I understand it
>>  correctly). Please specify what error-code will be returned in
>>  this case. I think this is best specified in the DESCRIPTION of
>>  the rowstatus.
>
>will copy similar text from elsewhere

see inconsistentValue text

>
>>
>>5.I wonder if testMoreInfo is supposed to be human readable?
>>  If so, some form of UTF8 string is a better syntax I think.
>
>brian hassink's point was:
>
>These MIBs are nice to see. In a recent project, we had several concerns
>with the
>test objects defined by the IF MIB (i.e. notification of a completed test to
>avoid polling, logging of test results to avoid loss due to a subsequent test,
>and test parameters) and opted to write our own test objects and procedures
>in an
>enterprise MIB. These concerns appear to have been addressed by the
>proposed test
>MIB. One small comment is that "testParameters" may be a slightly more
accurate
>name for the "testMoreInfo" object.
>
>my understanding is that the syntax and object descriptor was choosen
>the way it is to allow maximum flexibility, e.g., to allow non-human-readable
>info. testParameters may also constrain it to pointers or something like that.
>based on that understaing my suggestion is to keep as is,
>but i'm open to other interpretetations.
>
>any other views?

i havent made any changes on this

>
>>
>>6.Would a DEFVAL of 'none' not be a good deault for testResult?
>
>done
>
>>
>>7.There is no storage type for testTable. Does that mean that all
>>  entries are volatile, except for the exception that you stated
>>  in case a test causes a re-start of the agent? Might be good
>>  to say something about it. Mmm... you state it in testTableMaxSize.
>>  Seems it belongs in the table DESCRIPTION too.
>
>done
>
>>
>>8.Testcapabilities is nice to list all capabilities.
>>  It does not indicate though which tests can be applied to which
>>  targets. Is that something that a manager should just try and
>>  find out by tryal and error?
>
>might become a very long list

i havent made any changes on this

>
>>
>>9.If this MIB goes onto standards track, then you also need to add
>>  an IPR section (see RC2026, sect 10.4).
>
>done
>
>
- --=====================_289749277==_
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: attachment; filename="testmib.rfc"

          INTERNET-DRAFT    System/Interface Test MIB      April 7, 1999

                        Definitions of Managed Objects for
                           System and Interface Testing

                                  April 7, 1999

                        <draft-ietf-ifmib-testmib-05.txt>

                                   Maria Greene
                                   Xedia Corp.
                                 [email-masked]

                                 Keith McCloghrie
                                  Cisco Systems
                                  [email-masked]

                                    Kaj Tesink
                              Telcordia Technologies
                            [email-masked]

          1.  Status of this Memo

          This document is an Internet-Draft.  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.''

          To learn the current status of any Internet-Draft, please
          check the ``1id-abstracts.txt'' listing contained in the
          Internet- Drafts Shadow Directories on ftp.ietf.org (US East
          Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast),
          or munnari.oz.au (Pacific Rim).

          Expires October 7, 1999                               [Page 1]

          INTERNET-DRAFT    System/Interface Test MIB      April 7, 1999

          Copyright Notice

          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:  [email-masked]

                     Keith McCloghrie
                     Postal:  Cisco Systems
                              170 West Tasman Drive
                              San Jose, CA 95134
                              USA
                     Tel:     +1 408 526 5260
                     E-mail:  [email-masked]

                     Kaj Tesink
                     Postal:  Telcordia Technologies
                              331 Newman Springs Road
                              Red Bank, NJ 07701
                              USA
                     Tel:     +1 732 758 5254
                     E-mail:  [email-masked]"
                 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: [email-masked]

                         Keith McCloghrie
                         Cisco Systems
                         170 West Tasman Drive
                         San Jose, CA 95134
                         Phone: (408) 526-5260
                         Email:  [email-masked]

                         Kaj Tesink
                         Telcordia Technologies
                         331 Newman Springs Road
                         P.O. Box 7020
                         Red Bank, NJ  07701-7020
                         Phone: (732) 758-5254
                         Email: [email-masked]

          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]

- --=====================_289749277==_
Content-Type: text/plain; charset="us-ascii"

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Kaj Tesink
Telcordia Technologies (formerly Bellcore)
Email  [email-masked]
Tel    732.758.5254
Fax    732.758.2269
Postal 331 Newman Springs Rd
       Red Bank, NJ 07701
       USA

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

- --=====================_289749277==_--

------- End of Forwarded Message