Internet Draft                                                  G. Nunzi
Document: draft-nunzi-check-mib-00.txt                        J. Quittek
Expires: June 2004                                            M. Brunner
                                                                T. Dietz
                                                                     NEC
                                                           December 2003



     Definitions of Managed Objects for the Health Check Operations

                     <draft-nunzi-check-mib-00.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.  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

   Distribution of this document is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community,
   that is targeted at increasing scalability of network monitoring via
   SNMP.  In particular, the MIB module defined in this document
   describes a set of managed objects that allow to define a check
   procedure on a managed device.  The result of the  check is
   accumulated into a single managed object that can be read by a
   manager instead of reading all individual managed objects to be
   checked during the check procedure.



Nunzi, Quittek, Brunner, Dietz                                  [Page 1]

Internet-Draft                                             December 2003


Table of Contents

   1 Introduction .................................................    3
   2 The Internet-Standard Management Framework ...................    3
   3 Overview .....................................................    3
   3.1 Related MIB Modules ........................................    4
   3.1.1 Script MIB ...............................................    4
   3.1.2 Expression MIB ...........................................    5
   3.1.3 Event MIB ................................................    5
   4 Features .....................................................    6
   5 Structure of the MIB Module ..................................    8
   5.1 checkCapabilities ..........................................    9
   5.2 checkControl ...............................................    9
   5.3 checkResultTable ...........................................    9
   5.4 checkRuleTable .............................................   10
   5.5 checkFailureTable ..........................................   11
   5.6 checkNotifications .........................................   11
   6 MIB Usage ....................................................   11
   6.1 Usage Example ..............................................   12
   7 Definitions ..................................................   13
   8 Security Considerations ......................................   33
   9 Normative References .........................................   34
   10 Informative References ......................................   35
   11 Authors' Addresses ..........................................   35
   12 IPR Notices .................................................   36
   13 Full Copyright Statement ....................................   36


























Nunzi, Quittek, Brunner, Dietz                                  [Page 2]

Internet-Draft                                             December 2003


1.  Introduction

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes a set of managed objects that allow to
   define a health check procedure on a managed device.  The result of
   the health check is accumulated into a single managed object that can
   be read by a manager instead of reading all managed objects to be
   checked during the health check procedure.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119 [RFC2119].


2.  The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   RFC 3410 [RFC3410].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a MIB
   module that is compliant to the SMIv2, which is described in STD 58,
   RFC 2578 [2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
   [RFC2580].


3.  Overview

   Typically, checking healthiness of a managed node from a network
   management station requires reading a lot of individual managed
   objects at the node.  The management applications checks if the
   values of these objects are within certain ranges; indicating safe
   states, or have reached values indicating failure or error states.
   Polling the values from the managed device to compare them with the
   ranges' boundaries causes load on the management station in the
   network and on the managed node.  This limits the scalability of
   monitoring applications in terms of managed nodes and of managed
   objects to be checked per node.

   Configuring event notifications avoids the read operations; but can
   lead to flooding of notifications when a single failure triggers
   several events at the same time.  In both approaches; the manager
   applications can experiment difficulties in monitoring a high number
   of managed objects per device in large networks.


Nunzi, Quittek, Brunner, Dietz                                  [Page 3]

Internet-Draft                                             December 2003


   The basic idea of the CHECK MIB is to perform the comparison
   operations at the device and to aggregate the result into a single
   object.  The manager can poll the single result object or,
   eventually, configure the device to send a notification if the result
   identifies a failure condition.  This approach improves the
   scalability of monitoring applications; because the interactions with
   the controlled stations are reduced by a factor equal to number of
   objects aggregated by the result.

   The CHECK MIB aims to keep a high level of simplicity in the
   configuration of the checks as well as in the implementation of the
   module, while featuring, at the same time, capabilities which should
   fit for the most monitoring applications.

3.1.  Related MIB Modules

   Existing MIBs define similar features to distribute monitoring
   operations to managed nodes; as outlined briefly in the following
   paragraphs.  In general it can be stated that they focus on wider
   ranges of applications and offer richer capabilities than the CHECK
   MIB; but they don't achieve the same level of scalability, simplicity
   and efficiency.

3.1.1.  Script MIB

   The Script MIB [RFC3165] allows a NMS to download arbitrary programs
   (scripts) to the managed node and read intermediate or final results
   from program execution.  If supported by the Script MIB
   implementation, programs can access local managed objects of other
   MIB modules and perform even complex operations on them.  Among these
   operations the checks described above are included.

   However, the Script MIB also creates a lot of overhead.  It requires
   to code all comparisons into programs, to download them to the
   managed node and to control their execution.  Changes in the check
   operations, for example, the modification of one of several
   thresholds requires to identify the corresponding line of the
   program, modify it, re-compile it (required in some cases), download
   the modified program to the managed node (required in some cases),
   stop the execution of the original program and start the modified
   one.

   Another matter of complexity is the implementation of the Script MIB.
   It is very powerful concerning the handling of programs, passing
   arguments to them, receiving intermediate results and controlling
   their execution.  In addition, a runtime engine for the programs to
   be executed must be provided.  This is achieved by a rather complex
   and costly implementation.

   The rich capabilities of the Script MIB imply several security


Nunzi, Quittek, Brunner, Dietz                                  [Page 4]

Internet-Draft                                             December 2003


   issues.  Since the programs to be executed can potentially execute
   arbitrary code, strict access control to the Script MIB is required.

   Summarizing the consideration of the Script MIB, it is more than
   powerful enough for increasing scalability of monitoring applications
   as described above.  It offers a much richer and more general
   functionality.  However, the prices for this is a costly
   implementation, rather complex handling of the MIB required by an NMS
   and a set of security issues to be considered.

3.1.2.  Expression MIB

   The Expression MIB [RFC2982] allows to compute in the managed station
   simple expressions based on the values of the managed objects; the
   goal is to offer to the manager directly an elaboration of those
   values (for example the percentage line utilization per second
   elaborated with a mathematical expression from four objects of
   mib-2).  Moreover the Expression MIB introduce two new features: the
   "wildcard" to include the computation of all instances of an object
   in a table within a single expression and the type of sampling to
   consider different samples of object value.

   The drawbacks of this flexibility are the complexity in defining the
   expressions (each value in the expression is treated as a variable
   and must be correctly defined in a table for variables) and the
   difficulty in implementing it (the manager must implement a parser
   for the expression, a checker for the consistency of the expression
   with variables); moreover the expression can be incorrectly defined
   and so the manager must check for errors before reading results,
   avoiding automated control; finally the wildcard creates a value for
   each instance of the object referred, without aggregating each
   partial result.

   Most of the monitoring operations performed by manager applications
   resolve to simple comparison between values and don't require the
   computational capabilities offered by the Expression MIB.  However,
   those applications which need such capabilities can use the value
   objects of the Expression MIB as source for the comparison operations
   defined in the CHECK MIB.

3.1.3.  Event MIB

   The Event MIB [RFC2981] allows an agent to monitor managed objects at
   a device and to report failures when certain conditions on their
   values are met.  The manager can configure three types of condition
   to monitor the objects. If a condition is met, two different actions
   can be taken: either set a value of a object (to report failures to
   other MIBs) or send a notification.

   Each type of condition must be defined in a different table and is


Nunzi, Quittek, Brunner, Dietz                                  [Page 5]

Internet-Draft                                             December 2003


   associated with a different notification.  The Event MIB can control
   objects on the local managed station or on remote managed stations
   through the integration with the SNMPv3 Management Target and
   Notification MIBs [RFC2573].

   The Event MIB contains also two features already defined in the
   Expression MIB: the wildcard to reference all the instances of an
   object and the different types of sampling of the object's value.

   There's a certain overlap in the definition of the monitor operations
   in the Event MIB (trough the "trigger" objects) and in the CHECK MIB.
   This overlap is needed to achieve the simplicity and scalability
   goals aimed by the CHECK MIB.  The configuration of the triggers of
   the Event MIB is not simple due the need of accessing two different
   tables for each trigger; the implementation as well is complicated by
   the coexistence of three different types of triggers and the
   correspondent tables in the MIB tree.  Scalability is not addressed,
   because each trigger monitors a managed object and cannot be
   aggregated with others.


4.  Features

   The basic feature of the CHECK MIB is to perform a check procedure
   through a set of simple comparison operations between values of the
   monitored objects and control values.  The manager station initially
   configures the check procedure on the device and later it polls a
   value representing the result of the check.  Alternatively; the
   manager can configure the device to send a notification when the
   result identifies an error condition.

   In the CHECK MIB the comparison operation is called "rule".  A rule
   defines a monitored object, a reference value and the relationship
   expected between the value of the monitored object and the reference
   value; a rule fails if the relationship is not respected.  Rules are
   defined as entries in the checkRuleTable.

   A check is constituted by a set of rules and is defined in an object
   called "result".  When a check defined in a result is performed; each
   rule included by that result is performed in sequence.  At the end of
   the performance, the result object contains the result of the check;
   as explained afterwards.  Results are defined as entries in the
   checkResultTable and the rules included by a result are referenced
   using the name of the result as first index in the checkRuleTable.

   Several results can be defined on a device, where each of them
   performs a different check.  For example, one result can monitor
   general conditions of the device (like the internal temperature) and
   another one can monitor the operational status of a specific element
   (for example the link status of the interfaces installed).  The


Nunzi, Quittek, Brunner, Dietz                                  [Page 6]

Internet-Draft                                             December 2003


   figure below gives a snapshot of a general configuration and
   clarifies the aggregation of operations inducted by the CHECK MIB.

    rule1: obj1<30  --|
    rule2: obj2=2     |-- aggregated by --> result: checkGeneral
    rule3: obj9>=60 --|

    ruleA: obj1<30  --|
    . . .             |-- aggregated by --> result: checkSpecific
    ruleZ: obj9>=60 --|

   When a check is performed and some rules included fail; then a
   "failure" object is created for each rule which failed; each failure
   object contains the OID of the monitored object defined in the rule;
   as depicted below:

   performance of checkGeneral --> rule1: failed? Yes --> failure: obj1
                               --> rule2: failed? Yes --> failure: obj2
                               --> rule3: failed? Yes --> failure: obj9

   When the manager polling the result discovers a failure in the check,
   it can read the objects which didn't pass the last check.

   A rule defines also the integer value "severity" which measures the
   gravity of the rule for the result which includes it.  If some rules
   fail, then the result is updated with the maximum of the severities
   of the failed rules.  The purpose of the severity is to indicate the
   severity of the failures occurred in a check to the network manager.
   The scale of the severity is arbitrary chosen by the manager.
   Nevertheless this document implicitly uses for the examples a scale
   between 0 and 100, because it gives enough space to include enough
   levels of gravity of the checks of the managed stations.

   The CHECK MIB defines a notification object to report a failed check.
   The notification contains the severity of the result.  The trigger of
   a notification is a threshold value for the severity of the result
   and thus a notification is sent only if the severity reaches or
   overcomes the threshold value.  The management station can enable the
   threshold only for highly severe failures, so that a notification
   will not be sent for minor failures.  It's worth to notice that even
   if the managed objects controlled in a check carry correlated
   information and all the rules in a result happen to fail for the same
   failure in the monitored device, only one notification will be sent
   (no "events storming" is triggered).

   A check can be performed automatically, that is on regular intervals,
   or manually, that is each time the severity of a result is retrieved
   by the manager.

   The CHECK MIB can be used to monitor all the object types defined in


Nunzi, Quittek, Brunner, Dietz                                  [Page 7]

Internet-Draft                                             December 2003


   SMIv2 with the exception of the Opaque type. Integer values can be
   compared to control values (with relationships like <,<=,=,!=,>,>=).
   For counters it's possible to specify also a delta operation to
   monitor the increments at each check. IpAddress, OID, BITS and OCTET
   STRING values can be monitored only testing if they match the control
   value. The control value for all the object types is encoded into an
   OCTET STRING object, following the definitions given in the textual
   convention RuleValue.

   The objects to be monitored are identified by their OIDs.  In the
   simple case a rule monitors a single instance object.  Beside, it's
   possible to monitor with a single rule all the instances of a
   columnar object (that is an object defined inside a row of a table);
   in this case the OID of the columnar object itself must be indicated
   and the rule is applied to all the instances of the columnar object
   existing in the table.  The instances are retrieved as the objects
   next in lexicographical order to the OID specified in the rule.  A
   misconfigured OID (that is an OID which doesn't refer neither to an
   instance object nor a columnar object) may lead to retrieve wrong
   objects in the MIB tree and thus to compute wrong results in the
   performance of a check.

   Each result is identified by its name which is used as index in the
   checkResultTable.  The name of the result should give a brief
   description of the purpose of the result to help readability of the
   table.  Some recommendations are given in the definition of the CHECK
   MIB for the result's name; aiming at a common semantic between
   different management stations.  Following these suggestions, an
   example for a result's name is "zeusInterfaces", which identifies a
   check configured by a management application called "zeus" to monitor
   the the interfaces of the device.

   A useful application of the CHECK MIB is the support for checks pre-
   configured in the device by the manufacturer.  In this case the
   manager application might use the pre-configured checks, bypassing
   the configuration of all the rules.


5.  Structure of the MIB Module

   This section presents the structure of the MIB module that is
   specified in Section 7.

   The module contains five groups of managed objects:
      -  the capabilities group
         containing managed objects that indicate capabilities of the
         CHECK MIB implementation;
      -  the control group
         containing managed objects that control the working status of
         the CHECK MIB;


Nunzi, Quittek, Brunner, Dietz                                  [Page 8]

Internet-Draft                                             December 2003


      -  the result group
         containing the checkResultTable that provides results of check
         operations;
      -  the rule group
         containing the checkRuleTable that specifies check operations;
      -  the failed checks group
         containing the checkFailureTable that indicated managed objects
         for which a check failed.

   Additionally, a notification is specified that can be used for
   notifying a NMS about failed checks.

5.1.  checkCapabilities

   Information on middle-box capabilities is provided by the
   capabilities group of managed objects.  The following objects are
   defined:

    o   checkCapabMinCheckInterval
        This object indicates the minimum time between two performances
        of the same check that can be scheduled.

    o   checkCapabMaxResults
        This object indicates the maximum number of entries in the
        checkResultTable.

    o   checkCapabMaxRules
        This object indicates the maximum number of entries in the
        checkRuleTable.

5.2.  checkControl

   The working status of the CHECK MIB can be controlled through two
   objects:

    o   checkCtrlAdminStatus
        This object indicates the desiderated status of the CHECK MIB.

    o   checkCtrlOperStatus
        This object indicates the actual status of the CHECK MIB.

5.3.  checkResultTable

   This tables contains the results of the checks performed by the agent
   as well as some parameters to control how the checks are actually
   performed.  The following objects are defined:

    o   checkResultName
        This object indicates the name of the result. The name is used
        as index for the table and should give indicate the name of the


Nunzi, Quittek, Brunner, Dietz                                  [Page 9]

Internet-Draft                                             December 2003


        manager configuring the check and a label identifying the check
        procedure.

    o   checkResultSeverity
        This object indicates the result of the checks performed from
        the device.  A value of 0 indicates that no failure have been
        detected while performing the check.  A value greater than 0
        indicates the maximum of the severities of the rules failed at
        the last performance.

    o   checkResultSize
        This object indicates the number of failed rules at the last
        performance.

    o   checkResultTime
        This object indicates the time of the last performance.

    o   checkResultInterval
        If this object is set to 0, then the check is performed each
        time a manager retrieves the value of checkResultSeverity.  A
        value greater than 0 specifies the interval between two checks
        automatically performed by the device.

    o   checkResultSeverityThreshold
        This objects indicates if a notification should be sent if a
        check fails.  A value of 0 means that no notification will be
        sent. A value different from 0 indicates that a notification
        should be sent if a check fails with severity greater or equal
        to that value.

    o   checkResultRowStatus
        This objects permits the creation and deletion of rows.

5.4.  checkRuleTable

   This table defines the comparison operations to be executed for the
   checks specified in the checkResultTable.  The following objects are
   defined:

    o   checkRuleName
        This object indicates the name of the rule and is used as index
        for the table coupled with the checkResultName of the check
        which includes the rule.

    o   checkRuleOid
        This object indicates the OID of the object to be monitored.

    o   checkRuleValue
        This object indicates the value the object must be compared to.



Nunzi, Quittek, Brunner, Dietz                                 [Page 10]

Internet-Draft                                             December 2003


    o   checkRuleOperation
        This object indicates the relationship expected between the
        value of the monitored object and checkRuleValue.

    o   checkRuleSeverity
        This object indicates the severity for the rule defined by this
        entry.

    o   checkRuleRowStatus
        This object permits the creation and deletion of rows.

5.5.  checkFailureTable

   This table contains the failures registered while performing the
   checks.  For each rule failed, an entry in this table.  Each entry is
   indexed by the checkResultName and the checkRuleName of the rule
   failed and the checkFailureSeverity object.  Two objects are defined
   in the table:

    o   checkFailureSeverity
        This objects is indicates the severity with which the rule
        failed.

    o   checkFailureOid
        This objects is indicates the OID of the object for which the
        rule failed.

5.6.  checkNotifications

   The notification object checkResultFailed can be sent by the device
   when a check fails.  The notification contains only the
   checkResultSeverity object.

6.  MIB Usage

   This section explains how to configure check procedures and to
   implement monitor application with the CHECK MIB.

   When defining a new check, the manager should follow these steps:

      1. Create a new row in checkResultTable through the object
         checkResultRowStatus, using the name of the check as index.
      2. Set the values of checkResultSeverityThreshold and
         checkResultInterval.
      3. Create a new row in checkRuleTable through the object
         checkRuleRowStatus giving the name of check and the name of the
         rule as indexes.
      4. Configure the operation defined in the rule and its severity.
      5. Activate the row of the rule by writing to checkRuleRowStatus.
      6. Repeat step 3-5 for each rule to be included in the check.


Nunzi, Quittek, Brunner, Dietz                                 [Page 11]

Internet-Draft                                             December 2003


      7. Activate the row of the result by writing to
         checkResultRowStatus.

   A change in the RowStatus of a result is propagated also to the
   RowStatus of all the rules included by that result.  As consequences,
   deleting a row in the checkResultTable causes the deletion of all
   rows in the checkRuleTable and checkFailureTable with the same
   checkResultName (they are respectively the rules and the failures
   included by the check being deleted) and activating a results causes
   the activation of all the rules included.  The values of the objects
   with read-create permissions can be modified only when the row they
   belong to is put in the status notInService.

   If the device is put under maintenance (for example monitored objects
   are being reset); it's possible to disable temporally the performance
   of the checks, changing the value of the checkCtrlAdminStatus object.

6.1.  Usage Example

   This section presents an example that explains how a manager can use
   the CHECK MIB defined in this memo.  The purpose of this example is
   to explain the steps that can be performed by a network management
   station (NMS) to configure check procedures and to retrieve their
   results.

   When monitoring the correct behavior of the interfaces installed on a
   device; the main task is to make sure that all the interfaces
   installed have their operational status as UP; besides, the number of
   corrupted packets can be a first indicator of some malfunctions in
   the device.

   Instead of polling continuously the managed objects from the router,
   the NMS can configure the CHECK MIB to follow these rules:
      1. Control all the instances of ifOperStatus: if one interface is
         down, sends a notification.
      2. Control all the instances of ifInError and ifOutError: if too
         corrupted packets traverse an interface, then raise the
         severity of the check result.  For example 30 corrupted packets
         every 10 seconds should be marked as severity 40; 50 corrupted
         packets every 10 seconds as severity 70.

   If the check is configured to be performed every 10 seconds, then a
   new row in the checkResultTable must be created with the following
   set commands:

      checkResultRowStatus."mgrInterfaces" = create-and-wait(5)
      checkResultInterval."mgrInterfaces" = 10000
      checkResultSeverityThreshold."mgrInterfaces" = 100

   Then the rules must be defined for that check. For example the rule


Nunzi, Quittek, Brunner, Dietz                                 [Page 12]

Internet-Draft                                             December 2003


   for the ifOperStatus is configured with the following set commands:

      checkRuleRowStatus."mgrInterfaces"."status" = create-and-wait(5)
      checkRuleOid."mgrInterfaces"."status" = ifOperStatus
      checkRuleSeverity."mgrInterfaces"."status" = 100
      checkRuleValue."mgrInterfaces"."status" = 1
      checkRuleOperation."mgrInterfaces"."status" = less(3)
      checkRuleRowStatus."mgrInterfaces"."status" = active(1)

   Commands for the ifInErrors and ifOutErrors are similar.  As the last
   step, the check must be activated with the following command:

      checkResultRowStatus."mgrInterfaces" = active(1)

   The checkResultTable will look like:

       -----------------------------------------------------
       |Name      |Severity|Time|Interval|SeverityThreshold|
       -----------------------------------------------------
       |mgr_router|     100|0:00|    1000|              100|
       -----------------------------------------------------

   The checkRuleTable will look like:

       ---------------------------------------------------
       |Name       |         Oid|Value|Operation|Severity|
       ---------------------------------------------------
       |status     |ifOperStatus|    1|     less|     100|
       |inErrors30 |ifInErrors  |   30|    delta|      40|
       |outErrors30|ifOutErrors |   30|    delta|      40|
       |inErrors50 |ifInErrors  |   50|    delta|      70|
       |outErrors50|ifOutErrors |   50|    delta|      70|
       ---------------------------------------------------

   At this point if an interface switches its operational status to
   DOWN, only one notification will be sent containing the severity 100.

   On the other hand, if the NMS reports bad performance of end-services
   in the network (for example high level of packet-loss), than it can
   poll the severity of the result: a value of 40 or 70 might indicate
   the right cause of the bad performance reported.

7.  Definitions

   CHECK-MIB DEFINITIONS ::= BEGIN

   IMPORTS
       MODULE-IDENTITY, OBJECT-TYPE,
       NOTIFICATION-TYPE, mib-2,
       Unsigned32, TimeTicks, zeroDotZero


Nunzi, Quittek, Brunner, Dietz                                 [Page 13]

Internet-Draft                                             December 2003


           FROM SNMPv2-SMI                  -- RFC2578

       StorageType, RowStatus,
       TimeInterval, TimeStamp,
       TEXTUAL-CONVENTION
           FROM SNMPv2-TC                   -- RFC2579

       MODULE-COMPLIANCE, OBJECT-GROUP
           FROM SNMPv2-CONF                 -- RFC2580

       SnmpAdminString
           FROM SNMP-FRAMEWORK-MIB;         -- RFC3411

   checkMIB MODULE-IDENTITY
       LAST-UPDATED "200312191313Z"  -- December 19, 2003
       ORGANIZATION "IETF Distributed Management man Working Group"
       CONTACT-INFO
          "Editor:
             Giorgio Nunzi
             NEC Europe Ltd.
             Network Laboratories
             Kurfuersten-Anlage 36
             69221 Heidelberg
             Germany
             Tel: +49 6221 90511-39
             Email: nunzi@netlab.nec.de"
       DESCRIPTION
           "This MIB module defines a set of objects that allow
            to define a health check procedure on a managed node.
            The health check procedure is performed through a sequence
            of simple comparison operations on some managed objects
            against a control value.  The result of the health check
            is accumulated into a single managed object that can be
            read by a manager to discover the status of the whole
            set of managed objects instead of retrieving all the single
            values controlled during the health check procedure.

            The main purpose of the CHECK-MIB is increasing scalability
            of network management applications by moving check
            operations from the management station to managed nodes.

            There are five groups of managed objects defined
            by this MIB module:
              - objects describing capabilities
                of the CHECK-MIB implementation;
              - objects controlling the operational
                status of the health check procedure;
              - objects defining the checks in
                the checkResultTable;
              - objects defining the operations for each of


Nunzi, Quittek, Brunner, Dietz                                 [Page 14]

Internet-Draft                                             December 2003


                the configured checks in the checkRuleTable;
              - objects providing information about
                failed checks."
       REVISION    "200312191313Z"  -- December 19, 2003
       DESCRIPTION "Initial version"
       ::= { mib-2 7777 }
   -- 7777 to be assigned by IANA.

   RuleValue ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "1x"
       STATUS      current
       DESCRIPTION
           "The control value compared with the value of a monitored
            object.  This value encodes all the object types
            defined by the SMIv2, except the Opaque, with the
            following rules:
            - INTEGER, Integer32, Unsigned32, TimeTicks, Counter32,
              Gauge32: the integer value is encoded with 4 octets in
              network-byte order;
            - Counter64: the integer value is encoded with 8 octets
              in network-byte order;
            - IpAddress: the address value is encoded with a 4 in
              network-byte order;
            - OBJECT IDENTIFIER: each sub-identifier is encoded with
              4 octets in network-order and the whole OID is encoded
              as a sequence of sub-identifiers starting from the
              top-level;
            - BITS: all the named bits in the bitstring, commencing
              with the first bit and proceeding to the last bit, are
              placed in bits 8 (high order bit) to 1 (low order bit)
              of the first octet, followed by bits 8 to 1 of each
              subsequent octet in turn, followed by as many bits as
              are needed of the final subsequent octet, commencing
              with bit 8.  Remaining bits, if any, of the final octet
              are set to zero on generation and ignored while
              performing a check;
            - OCTET STRING: the string is encoded as it is."
       SYNTAX OCTET STRING

   SeverityConfigured ::= TEXTUAL-CONVENTION
       STATUS      current
       DESCRIPTION
           "The severity value measures the gravity of a failure of a
            rule or a result. A low value indicates a minor failure,
            while a high value indicates a sever failure. The scale of
            the severity is arbitrary chosen by the manager
            application.
            This textual convention represents the value of a severity
            which is configured by the manager."
       SYNTAX Unsigned32 (0..4294967293)


Nunzi, Quittek, Brunner, Dietz                                 [Page 15]

Internet-Draft                                             December 2003


   SeverityReturned ::= TEXTUAL-CONVENTION
       STATUS      current
       DESCRIPTION
           "The severity value measures the gravity of a failure of a
            rule or a result. A low value indicates a minor failure,
            while a high value indicates a sever failure. The scale of
            the severity is arbitrary chosen by the manager
            application.
            This textual convention represents the value of a severity
            which is set by the device after the performance of a rule.
            If the rule has been correctly performed, the value is
            equal to the severity configured for the rule.  If the rule
            has not been performed because the monitored object
            couldn't be accessed, then this values is set to
            4294967295.  If the rule has not been performed due to a
            lack of resources, then this value is set to 4294967294."
       SYNTAX Unsigned32

   --
   -- main components of this MIB module
   --

   checkObjects       OBJECT IDENTIFIER ::= { checkMIB 1 }
   checkNotifications OBJECT IDENTIFIER ::= { checkMIB 2 }
   checkConformance   OBJECT IDENTIFIER ::= { checkMIB 3 }

   --
   -- Capabilities group
   --
   -- The capabilities group contains a set of managed
   -- objects describing the capabilities of the CHECK-MIB
   -- implementation.
   --

   checkCapabilities        OBJECT IDENTIFIER ::= { checkObjects 1 }

   checkCapabMinCheckInterval OBJECT-TYPE
       SYNTAX      TimeTicks
       UNITS       "centi-seconds"
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The minimum interval that can be scheduled between two
            performances of the same check defined in the
            checkResultTable using the object checkResultInterval.

            This value is the minimum value allowed for the object
            checkResultInterval of the checkResultTable."
       ::= { checkCapabilities 1 }



Nunzi, Quittek, Brunner, Dietz                                 [Page 16]

Internet-Draft                                             December 2003


   checkCapabMaxResults OBJECT-TYPE
       SYNTAX      Unsigned32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The maximum number of entries supported in the
            checkResultTable.  A value of 0 indicates that
            there is no fixed limitation.

            Creating a new row in the checkResultTable with the
            object checkResultRowStatus after the maximum number
            of entries supported, leads to a resourceUnavailable
            error."
       ::= { checkCapabilities 2 }

   checkCapabMaxRules OBJECT-TYPE
       SYNTAX      Unsigned32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The maximum number of entries supported in the
           checkRuleTable.  A value of 0 indicates that there
           is no fixed limitation.

           Creating a new row in the checkRuleTable with the
           object checkRuleRowStatus after the maximum number
           of entries supported, leads to a resourceUnavailable
           error."
       ::= { checkCapabilities 3 }

   --
   -- Control group
   --
   -- The control group contains managed objects controlling
   -- the operational status of the check MIB implementation.
   --

   checkControl       OBJECT IDENTIFIER ::= { checkObjects 2 }

   checkCtrlAdminStatus OBJECT-TYPE
       SYNTAX  INTEGER {
                   up(1),       -- performing checks
                   silent(2),   -- no notifications sent
                   down(3)      -- all checks disabled
               }
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
          "The desidered state of the checking engine of the
           Check MIB implementation.  Setting this object to up(1)


Nunzi, Quittek, Brunner, Dietz                                 [Page 17]

Internet-Draft                                             December 2003


           indicates a request for performing all checks as defined
           in the checkResultTable and the checkRuleTable performed.
           Setting this object to silent(2) indicates that all the
           checks defined in checkResultTable must be performed, but
           no notification must be sent by the Check MIB
           implementation.  Setting this object to down(3) indicates
           a request for performing o more tests.

           When retrieved, the object returns the last value written
           to it, except after system boot when it returns the value
           up(1)."
           DEFVAL { up }
       ::= { checkControl 1 }

   checkCtrlOperStatus OBJECT-TYPE
       SYNTAX  INTEGER {
                   up(1),       -- performing checks
                   silent(2),   -- no notifications sent
                   down(3),     -- all checks disabled
                   flushing(4)  -- finishing checks already started
               }
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
          "The current operational state of the Check MIB
           implementation. The up(1) state indicates that all checks
           defined in the checkResultTable and the checkRuleTable are
           performed.  The silent(2) state indicates that all checks
           are performed as defined in the checkResultTable and the
           checkRuleTable, but no notification is sent by the Check
           MIB implementation.  The down(3) state indicates that no
           check is performed.  The flushing(4) state indicates that
           the checkCtrlAdminStatus has been set to down(3) and the
           managed node is completing the performance of checks that
           were scheduled before checkCtrlAdminStatus was set to
           down(3).  If the value of checkCtrlAdminStatus does not
           change again before these checks are completed, then the
           value of checkCtrlOperStatus will change to down(3) after
           the checks are completed.

           After a system re-initialization, the Check MIB
           implementation starts up with this object set to up(1)."
       ::= { checkControl 2 }

   --
   -- Result group
   --
   -- The Result group contains the objects to define the checks
   -- performed on the managed node.  The checks are organized
   -- in the checkResultTable.


Nunzi, Quittek, Brunner, Dietz                                 [Page 18]

Internet-Draft                                             December 2003


   --

   checkResultTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF CheckResultEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "This table contains the definitions of the checks
            to be performed by the Check MIB implementation.

            Each row defines one check and contains the
            parameters controlling the performance of the check
            as well as the result of the check.

            The operations performed by each check are defined as
            rules in the checkRuleTable."
       ::= { checkObjects 3 }

   checkResultEntry OBJECT-TYPE
       SYNTAX      CheckResultEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "An entry defining a check.  Each entry is indexed by
           the string checkResultName, which represents the name
           of the check.  An entry can be created with the object
           checkResultRowStatus only with the createAndWait operation.
           A check is never performed if its entry is in the
           notInService status.   Objects in an entry marked as
           read-create can be modified only when the entry is in
           notInService status."
       INDEX { checkResultName }
       ::= { checkResultTable 1 }

   CheckResultEntry ::= SEQUENCE {
       checkResultName                 SnmpAdminString,
       checkResultSeverity             SeverityReturned,
       checkResultSize                 Unsigned32,
       checkResultTime                 TimeStamp,
       checkResultInterval             TimeInterval,
       checkResultSeverityThreshold    SeverityConfigured,
       checkResultStorageType          StorageType,
       checkResultRowStatus            RowStatus
   }

   checkResultName OBJECT-TYPE
       SYNTAX      SnmpAdminString (SIZE (0..32))
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION


Nunzi, Quittek, Brunner, Dietz                                 [Page 19]

Internet-Draft                                             December 2003


           "A name describing the check.  Since the name serves as
            table index, it must be unique for each row in the table.
            The name of a check is chosen arbitrary by the manager
            creating the row in the checkResultTable, but some
            suggestions are given to offer a common semantic
            among different managers.

            The name should give a brief description of the check
            defined in the row.  In particular it is recommended
            that the name indicates:
              - the name of the manager who defined the row.
              - a label describing the check."
       ::= { checkResultEntry 1 }

   checkResultSeverity OBJECT-TYPE
       SYNTAX      SeverityReturned
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Each time the check defined by this entry (and the
            corresponding entries of the checkRuleTable) is performed,
            this object is set to to the maximum value of all
            checkRuleSeverity objects in corresponding entries of the
            checkRuleTable for which the check failed.  If the check
            passes for all corresponding rules, then the value of
            object checkResultSeverity is 0.

            If the object checkResultInterval contains the value 0,
            then the check is performed when the value of
            checkResultSeverity is retrieved by a manager.  If the
            object checkResultInterval contains a value greater than 0,
            then the check is performed automatically by the managed
            node and a read access by a manager just returns the value
            computed at the last scheduled check.

            Each time object checkResultSeverity is set, the value of
            object checkResultTime in the corresponding entry is
            set to the current time, and the value of object
            checkResultSize is set to the number of corresponding
            entries in the checkRuleTable for which the check failed.

            If no check has been performed so far, then the value
            of this object is 0."
       ::= { checkResultEntry 2 }

   checkResultSize OBJECT-TYPE
       SYNTAX      Unsigned32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION


Nunzi, Quittek, Brunner, Dietz                                 [Page 20]

Internet-Draft                                             December 2003


           "The number of rules defined in corresponding entries of the
            checkFailureTable for which the check failed when it was
            performed last.

            If no check has been performed so far, then the value
            of this object is 0."
       ::= { checkResultEntry 3 }

   checkResultTime OBJECT-TYPE
       SYNTAX      TimeStamp
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "A timestamp indicating the time when the last performance
            of the check defined in this row was completed.

            If no check has been performed so far, then the value of
            this object is 0.  Note that 0 is a valid timestamp."
       ::= { checkResultEntry 4 }

   checkResultInterval OBJECT-TYPE
       SYNTAX      TimeInterval
       UNITS       "centi-seconds"
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The interval between two performances of the check
            defined in this row.

            When this object is set to a value greater than 0,
            then the check is performed regularly with the number
            of centi-seconds indicated by this object between two
            performances.  When this object is successfully set
            to a value greater than 0, then the check is not
            performed immediately. The first check is performed
            after the number of centi-seconds specified by the
            new value of the object.  If a performance is scheduled
            to start before the previous one  has been completed,
            then the previous check will be completed and the
            scheduled check will be skipped.

            If the number of this object is 0, then the check is
            performed only on request when the value of the object
            checkResultSeverity is retrieved by a manager.

            A set operation on this object may lead to an
            inconsistentValue error in two cases:
            - if the vale passed is greater than 0 but less
              than the value of checkCapabMinCheckInterval;
            - if the value passed is greater than 0 and the


Nunzi, Quittek, Brunner, Dietz                                 [Page 21]

Internet-Draft                                             December 2003


              check defined in this row includes rules with
              delta operations."
       DEFVAL { 0 }
       ::= { checkResultEntry 5 }

   checkResultSeverityThreshold OBJECT-TYPE
       SYNTAX      SeverityConfigured
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "This object serves for sending notifications in
            case of failures occurred in the check defined
            in this row.

            If the value of this object is set to 0, then no
            notification is sent to the manager even if some
            rule defined for the check fails.
            Otherwise, if the performance of a check leads to
            a value of the object checkResultSeverity that is
            equal to or greater than the value of the object
            checkResultSeverityThreshold, then a notification
            is sent.  The notification is an instance of
            checkResultFailed."
       DEFVAL { 0 }
       ::= { checkResultEntry 6 }

   checkResultStorageType OBJECT-TYPE
       SYNTAX      StorageType
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The value of this object indicates the storage type
            of this entry in the checkResultTable and of all
            corresponding entries in the checkRuleTable.  The value
            of this object indicates whether the entries are stored
            in volatile memory and lost upon reboot or if they
            are backed up by non-volatile or permanent storage.

            If checkResultStorageType has the value permanent(4),
            then all objects whose MAX-ACCESS value is read-write
            can be modified, but the row cannot be deleted.  All the
            objects in corresponding entries of the checkRuleTable
            whose MAX-ACCESS is read-create are instead read-only with
            the exception of the checkRuleRowStatus.
            Attempts to set this object to permanent(4) will always
            fail with an inconsistentValue error."
       DEFVAL { volatile }
       ::= { checkResultEntry 7 }

   checkResultRowStatus OBJECT-TYPE


Nunzi, Quittek, Brunner, Dietz                                 [Page 22]

Internet-Draft                                             December 2003


       SYNTAX      RowStatus
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "This object allows to create and delete rows in the
            table. The value createAndGo(4) is not allowed and an
            wrongValue error is returned when attempting to set it.

            Objects of the same row can be modified only when
            checkResultRowStatus has the notInService(2) value and
            set operations on objects of a row in active(1) status
            result to inconsistentValue.  A change of the value of the
            checkResultRowStatus object is propagated to the
            checkRuleRowStatus of all the related entries in the
            checkRuleTable (those indexed by the same checkResultName);
            if the change of the value of a checkRuleRowStatus object
            results in an inconsistentValue error, then this error is
            returned to the manager while setting the value of this
            checkResultRowStatus.

            An attempt to set the value of this object to active(1),
            causes the following actions:
            - all the related entries in the checkRuleTable become
              active; if an attempt to activate an entry results in
              an inconsistentValue error, then this error is returned
              to the manager and further action is taken;
            - all the objects of this row become read-only, with the
              exception of checkResultRowStatus;
            - if the value of checkResultInterval is greater than 0,
              then the timer to schedule the performances of the
              check starts immediately, but the first check will be
              performed only but after the time specified by
              checkResultInterval; for rules defining delta operations
              the values of managed objects to be checked are read
              immediately, so that delta operations can be computed at
              the first scheduled check.
            - if the value of checkResultInterval is equal to 0, then
              retrieving the value of checkResultSeverity forces the
              performance of the check.
            When a row is put in the notInService status, then the
            following actions are taken:
            - all the objects of the row marked as read-create can be
              modified;
            - all the related entries in the checkRuleTable become
              notInService;
            - all scheduled future checks are canceled.
            - retrieving the value of checkResultSeverity returns
              always the value computed at the last check.
            When a row is deleted, then if an alarm was configured, it
            is removed, and all the related entries in checkRuleTable


Nunzi, Quittek, Brunner, Dietz                                 [Page 23]

Internet-Draft                                             December 2003


            are deleted (eventually freeing the resources allocated
            for delta operations defined by those rules).

            Creating a new row when the table reached the maximum
            number of entries defined in checkCapabMaxResults
            results in a resourceUnavailable error."
       ::= { checkResultEntry 8 }
   --
   -- Check Rule group
   --
   -- The Rule group contains the objects to define the operations
   -- performed for each check.  The operations are organized
   -- in the checkRuleTable.
   --

   checkRuleTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF CheckRuleEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "This table contains the definitions of the operations
            performed for checks defined in the checkResultTable.

            Each row defines an operation on the value of a managed
            object.  The operation consists in a comparison of the
            value of the managed object with a control value specified
            in checkRuleValue.  The relationship expected between the
            two values is indicated by checkRuleOperation.
            It is possible to reference in a single rule either a
            single instances object or all the instance of a columnar
            object of a table.

            For each operation, a severity is set which indicates
            the gravity of the failure of the comparison operation.

            The storage type of entries in this table is determined
            by the value of object checkResultStorageType in the
            corresponding entry of the checkResultTable."
       ::= { checkObjects 4 }

   checkRuleEntry OBJECT-TYPE
       SYNTAX      CheckRuleEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "An entry defining a rule for a check defined
            in the checkResultTable.  Each entry is indexed by:
            1. the checkResultName of the check which includes
               the operation defined by the entry;
            2. the string checkRuleName, which represents the


Nunzi, Quittek, Brunner, Dietz                                 [Page 24]

Internet-Draft                                             December 2003


               name of the operation.
            An entry can be created with the object
            checkResultRowStatus only with the createAndWait operation.
            A rule is never considered in the performance of the
            check defined in the related checkResultEntry, if its
            entry is in the notInService status.   Objects in an entry
            can be modified only when the entry is in
            notInService status."
       INDEX { checkResultName, checkRuleName }
       ::= { checkRuleTable 1 }

   CheckRuleEntry ::= SEQUENCE {
       checkRuleName              SnmpAdminString,
       checkRuleOid               OBJECT IDENTIFIER,
       checkRuleValue             RuleValue,
       checkRuleOperation         INTEGER,
       checkRuleSeverity          SeverityConfigured,
       checkRuleRowStatus         RowStatus
   }

   checkRuleName OBJECT-TYPE
       SYNTAX      SnmpAdminString (SIZE (0..32))
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "A name describing the rule.  Since the name serves as
            table index coupled with the value of checkResultName,
            it must be unique per each row in the table
            inside the scope of checkResultName.
            The name of a rule is chosen by the manager creating
            the row, but some suggestions are given to offer a
            common semantic between different managers.

            The name should give a brief description of the rule
            defined in the row.  In particular it is recommended
            that the name indicates the name of the managed object
            controlled by the rule."
       ::= { checkRuleEntry 2 }

   checkRuleOid OBJECT-TYPE
       SYNTAX      OBJECT IDENTIFIER
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The OID indicating the managed object to be checked.
            The OID must be:
            - the OID of an instance object: in this case the
              rule is applied to that object;
            - the OID of a columnar object (missing of the instance
              sub-identifier): in this case the rule is applied to all


Nunzi, Quittek, Brunner, Dietz                                 [Page 25]

Internet-Draft                                             December 2003


              the instances of the columnar object.

            The validity of the OID is verified when the manager tries
            to activate the row, following these actions:
            - the agent should try to read the value of the object
              referenced by the OID (like a snmp get operation); if the
              value is read, the OID refers to a valid instance object
              and the type of the object should be registered inside
              the agent;
            - if the object is not available, then the agent should try
              to read the next object in the lexicographical order (like
              a snmp get next operation); if the OID returned is a child
              node of the checkRuleOid, then the latter is assumed to be
              a columnar object and the type of the object read is
              stored inside the agent;
            - if no object could be found or the OID returned is not a
              leaf of checkRuleOid, then an inconsistentValue error is
              return to the attempt of activating the row.
            When setting the OID of a columnar object, at least one
            instance object must exist at the moment of the activation
            of the row, so that the validity test of OID passes and the
            row is activated.

            If the OID references an instance object that is removed or
            become inaccessible after the row has been activated, then
            rule automatically fails with a severity equal to
            4294967295.  If the OID value references a columnar object
            and no instance exists after the first performance, then
            the rule doesn't fail."
       DEFVAL { zeroDotZero }
       ::= { checkRuleEntry 3 }

   checkRuleValue OBJECT-TYPE
       SYNTAX      RuleValue
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The control value compared to the value of the managed
            object indicated by checkRuleOid.

            The control value encoded in this object must be consistent
            with the type of the object referenced by the checkRuleOid.
            The control value is considered inconsistent if:
            - the object type is INTEGER, Unsigned32, TimeTicks,
              Gauge32, Counter32, IpAddress and the size of the
              checkRuleValue is different from 4;
            - the object type is Counter64 and the size of the
              checkRuleValue is different from 8;
            - the object type is OBJECT IDENTIFIER and the size of the
              checkRuleValue is not a multiple of 4.


Nunzi, Quittek, Brunner, Dietz                                 [Page 26]

Internet-Draft                                             December 2003


            The consistency between the control value and the object
            type is verified when the rule is activated; if the
            consistency test fails, the attempt to active the row
            results in an inconsistentValue error."
       DEFVAL { "" }
       ::= { checkRuleEntry 4 }

   checkRuleOperation OBJECT-TYPE
       SYNTAX      INTEGER {
                       noOperation(0),
                       unequal(1), equal(2),
                       less(3), lessOrEqual(4),
                       greater(5), greaterOrEqual(6),
                       delta(7)
                   }
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "The value of this object specifies the comparison
            operation to be performed between the value of the
            managed object indicated by checkRuleOid and the
            value indicated by checkRuleValue.  Some operations
            cannot be applied to all the types of object. If
            the value of the checkRuleOperation is inconsistent
            with the type of the object indicated by checkRuleOid,
            then an attempt to activate the row results in an
            inconsistentValue error.

            The value 0 can be configured for all the object
            types and means that no operation is performed and
            the rule never fails.

            When the type of the object indicated by checkRuleOid
            is IpAddress, BITS, OBJECT IDENTIFIER then only the value
            equal(2) can be configured.  For the IpAddress, the value
            of the object indicated by checkRuleOid is compared byte
            by byte with the value of checkRuleValue and the rule
            doesn't fail if all the bytes are matched.  For the
            OBJECT IDENTIFIER, the rule doesn't fail if checkRuleValue
            encodes an OID of the same dimension of the value of the
            object indicated by checkRuleOid and the two OIDs are
            equal.  For the BITS, the rule doesn't fail if the
            checkRuleValue encodes a bitstring long at least as the
            number of the named bits and all the named bits are
            matched with that bitstring.

            When the type of the object indicated by checkRuleOid
            is INTEGER, Integer32, Unsigned32, Counter32, Counter64,
            TimeTicks, Gauge32, all the values from 1 to 6 can be
            configured.  These values define simple mathematical


Nunzi, Quittek, Brunner, Dietz                                 [Page 27]

Internet-Draft                                             December 2003


            operations: the rule doesn't fail if the the value
            of the object indicated by checkRuleOid is, respectively,
            !=, =, <, <=, >, >= than the value of checkRuleValue.

            A value of of delta(7) can be configured only for
            Counter32, Counter64, Gauge32; moreover it is permitted
            only if the check including the rule is performed
            automatically and thus its value of checkResultInterval
            greater than 0, otherwise an inconsistentValue error is
            returned.  For a delta operation, each time the rule is
            performed, the difference between the actual value of the
            managed object and its value at the last performance is
            considered and the rule doesn't fail if the difference is
            <= than the value of the checkRuleValue.  If the actual
            value is less than the previous one, then the difference is
            augmented with the value 4294967295, like as the managed
            object reached its maximum value and it has been resetted.

            Each time the new value of the managed object must be
            stored by the device in an internal buffer.  The buffer
            must be handled so that when a new managed object is
            controlled, a new entry is allocated for it.  If no more
            entries are available, then the rule fails with severity
            4294967294.
            If a managed object for which an entry was previously
            allocated, doesn't exist when a new execution of the delta
            operation is performed, its entry should be removed.
            When a new entry is allocated for a new managed object,
            its value is stored in the entry, but the operation is not
            computed and the rule doesn't fail; the delta operation
            is normally computed only from the second time."
       DEFVAL { noOperation }
       ::= { checkRuleEntry 5 }

   checkRuleSeverity OBJECT-TYPE
       SYNTAX      SeverityConfigured
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The severity of a failure of the operation specified by
            the row for the whole check.

            A severity of 0 indicates that a failure of the
            operation is irrelevant."
       DEFVAL { 1 }
       ::= { checkRuleEntry 6 }

   checkRuleRowStatus OBJECT-TYPE
       SYNTAX      RowStatus
       MAX-ACCESS  read-create


Nunzi, Quittek, Brunner, Dietz                                 [Page 28]

Internet-Draft                                             December 2003


       STATUS      current
       DESCRIPTION
           "The control to create and delete rows.  It is possible
            to create new rules only for a check which is already
            defined in the CHECK-MIB.  Creating a new row indexed
            by a value of checkResultName which doesn't exist
            already in any row of the checkResultTable results in a
            inconsistentName error.  The value createAndGo(4) is not
            allowed and an wrongValue error is returned when attempting
            to set it.

            Objects of the same row can be modified only when
            checkRuleRowStatus has the notInService(2) value and
            set operations on objects of a row in active(1) status
            result to inconsistentValue.
            A row in the notInService status is not considered in the
            performance of the check defined by the related entry in
            the checkResultTable (the one indexed by the same
            checkResultName).

            An attempt to set the value of this object to active(1),
            causes the following actions:
            - the validity of the value of checkRuleOid is verified;
              if it fails, then an inconsistentValue error is returned;
            - the consistency between the type of the object referenced
              by checkRuleOid and the value of checkRuleOperation is
              verified; if it fails, then an inconsistentValue error is
              returned;
            - the consistency between the type of the object referenced
              by checkRuleOid and the value of checkRuleValue is
              verified; if it fails, then an inconsistentValue error is
              returned;
            - if all the tests pass, the row is activated.

            An attempt to create a new row when the table has reached
            the maximum number of entries defined in checkCapabMaxRules
            results in a resourceUnavailable error.
            An attempt to create a new row in the table with the
            corresponding entry in the checkResultTable having the
            storage type permanent(4) results in an inconsistentValue
            error."
       ::= { checkRuleEntry 7 }

   --
   -- Failure group
   --
   -- The Failure group contains the object describing the failures
   -- of a check.  The failures are organized in the checkFailureTable.
   --



Nunzi, Quittek, Brunner, Dietz                                 [Page 29]

Internet-Draft                                             December 2003


   checkFailureTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF CheckFailureEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "This table lists all the rules defined in the
            checkRuleTable, which failed at the last
            time the check including them has been performed.

            Entries only describe objects for which the last check
            failed. Failures in checks before the last one are not
            indicated."
       ::= { checkObjects 5 }

   checkFailureEntry OBJECT-TYPE
       SYNTAX      CheckFailureEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "An entry referencing a failed rule.

            Each entry is indexed by:
            1. the checkResultName of the check including
               the rule failed;
            2. the severity of the rule failed;
            3. The checkRuleName of the rule failed.

            The manager, after having read a value of
            checkResultSeverity of a check different from 0, can
            directly read the rule failed with the maximum severity by
            retrieving the checkFailureOid with a get_next command
            without specifying the checkRuleName."
       INDEX { checkResultName, checkFailureSeverity, checkRuleName }
       ::= { checkFailureTable 1 }

   CheckFailureEntry ::= SEQUENCE {
       checkFailureSeverity   SeverityReturned,
       checkFailureOid        OBJECT IDENTIFIER
   }

   checkFailureSeverity OBJECT-TYPE
       SYNTAX      SeverityReturned
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "The severity with which the rule failed."
       ::= { checkFailureEntry 1}

   checkFailureOid OBJECT-TYPE
       SYNTAX      OBJECT IDENTIFIER


Nunzi, Quittek, Brunner, Dietz                                 [Page 30]

Internet-Draft                                             December 2003


       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The OID of the managed object for which a rule
            failed.

            This value contains the value of checkRuleOid
            of the rule failed."
       ::= { checkFailureEntry 2 }

   --
   -- Notifications. The definition of checkEvent makes notification
   -- registrations reversible (see STD 58, RFC 2578, Section 8.5).
   --

   checkEvent OBJECT IDENTIFIER ::= { checkNotifications 0 }

   checkFailed NOTIFICATION-TYPE
       OBJECTS     { checkResultSeverity }
       STATUS      current
       DESCRIPTION
           "This notification can be generated to report
            that a check failed.  The notification is generated each
            time, the value of checkSeverityThreshold is greater than
            0 and the performance of a check results in a value of
            checkResultSeverity that is greater than or equal to the
            value of checkSeverityThreshold.

            The notification contains the checkResultSeverity of
            the check failed."
       ::= { checkEvent 1 }

   --
   -- Conformance information
   --

   checkCompliances OBJECT IDENTIFIER ::= { checkConformance 1 }
   checkGroups      OBJECT IDENTIFIER ::= { checkConformance 2 }

   --
   -- Compliance statements
   --
   -- This is the CHECK-MIB compliance definition.
   --

   checkCompliance MODULE-COMPLIANCE
       STATUS      current
       DESCRIPTION
           "The compliance statement for SNMP entities that
            implement the CHECK-MIB."


Nunzi, Quittek, Brunner, Dietz                                 [Page 31]

Internet-Draft                                             December 2003


       MODULE      -- this module
       MANDATORY-GROUPS {
               checkCapabilitiesGroup,
               checkControlGroup,
               checkResultGroup,
               checkRuleGroup,
               checkFailureGroup,
               checkNotificationsGroup
       }
       ::= { checkCompliances 1 }

   --
   -- Groups statements
   --
   -- This is the definition of the objects group of the CHECK-MIB.
   --

   checkCapabilitiesGroup OBJECT-GROUP
       OBJECTS {
           checkCapabMinCheckInterval,
           checkCapabMaxResults,
           checkCapabMaxRules
       }
       STATUS      current
       DESCRIPTION
           "A collection of objects providing information about
            the capabilities of the CHECK-MIB implementation."
       ::= { checkGroups 1 }

   checkControlGroup OBJECT-GROUP
       OBJECTS {
           checkCtrlAdminStatus,
           checkCtrlOperStatus
       }
       STATUS      current
       DESCRIPTION
           "A collection of objects controlling the state of the
            CHECK-MIB."
       ::= { checkGroups 2 }

   checkResultGroup OBJECT-GROUP
       OBJECTS {
           checkResultSeverity,
           checkResultSize,
           checkResultTime,
           checkResultInterval,
           checkResultSeverityThreshold,
           checkResultStorageType,
           checkResultRowStatus
       }


Nunzi, Quittek, Brunner, Dietz                                 [Page 32]

Internet-Draft                                             December 2003


       STATUS      current
       DESCRIPTION
           "A collection of objects defining a check."
       ::= { checkGroups 3 }

   checkRuleGroup OBJECT-GROUP
       OBJECTS {
           checkRuleOid,
           checkRuleValue,
           checkRuleOperation,
           checkRuleSeverity,
           checkRuleRowStatus
        }
        STATUS      current
        DESCRIPTION
            "A collection of objects defining the operations
             computed for each check."
        ::= { checkGroups 4 }

   checkFailureGroup OBJECT-GROUP
       OBJECTS {
           checkFailureOid
        }
        STATUS      current
        DESCRIPTION
            "A collection of objects indicating managed objects
             for which a check operation failed."
        ::= { checkGroups 5 }

   checkNotificationsGroup OBJECT-GROUP
        OBJECTS {
            checkFailed
        }
        STATUS    current
        DESCRIPTION
            "The notifications emitted by the CHECK-MIB."
        ::= { checkGroups 6 }

   END


8.  Security Considerations

   This MIB allow the execution of check procedures on the devices.  An
   improper manipulation of its objects can lead on one side to waste of
   device's resources or to spoofing of managed object otherwise not
   accessible and on the other hand to alter the normal monitor process
   of managers.

   There are a number of management objects defined in this MIB module


Nunzi, Quittek, Brunner, Dietz                                 [Page 33]

Internet-Draft                                             December 2003


   with 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.  These are the tables and objects and their
   sensitivity/vulnerability:

   -  The use of checkCtrlAdminStatus can turn off the check procedures
   configured on the device; thus disabling the whole monitor
   application using them;

   -  The use of checkResultTable can alter or remove the configured
   checks; moreover it can allow the creation of new checks wasting
   resources on the controlled device;

   -  The use of the checkRuleTable can alter or remove the configured
   rules; in particular it can be possible to set the OID of managed
   objects to spy their values through the check procedure; moreover the
   improper addition of new rules can result in waste of resources on
   the controlled device.

   SNMP versions prior to SNMPv3 did not include adequate security.
   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 module.

   It is REQUIRED that implementers consider the security features as
   provided by the SNMPv3 framework (see [RFC3410], section 8),
   including full support for the SNMPv3 cryptographic mechanisms (for
   authentication and privacy).

   For implementations of the CHECK MIB it is REQUIRED to deploy SNMPv3
   and to enable cryptographic security.  It is then a customer/operator
   responsibility to ensure that the SNMP entity giving access to an
   instance of this MIB module 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.


9.  Normative References

[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.


Nunzi, Quittek, Brunner, Dietz                                 [Page 34]

Internet-Draft                                             December 2003


[RFC2580]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
            Rose, M. and S. Waldbusser, "Conformance Statements for
            SMIv2", STD 58, RFC 2580, April 1999.

[RFC3411]   Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture
            for Describing Simple Network Management Protocol (SNMP)
            Management Frameworks", STD 62, RFC 3411, December 2002.

[RFC3413]   Levi, D., Meyer, P. and B. Stewart "Simple Network
            Management Protocol (SNMP) Applications", STD 62, RFC 3413,
            December 2002

10.  Informative References

[RFC3410]   Case, J., Mundy, R., Partain, D. and B. Stewart,
            "Introduction and Applicability Statements for Internet-
            Standard Management Framework", RFC 3410, December 2002.

[RFC3165]   Levi, D. and J. Schoenwaelder, "Definitions of Managed
            Objects for the Delegation of Management Scripts", RFC 3165,
            August 2001.

[RFC2982]   Stewart, B., "Distributed Management Expression MIB", RFC
            2982, October 2000.

[RFC2981]   Stewart, B., "Event MIB", RFC 2981, October 2000.


11.  Authors' Addresses

     Giorgio Nunzi
     NEC Europe Ltd.
     Network Laboratories
     Kurfuersten-Anlage 36
     69115 Heidelberg
     Germany

     Phone: +49 6221 90511-39
     Email: nunzi@netlab.nec.de


     Juergen Quittek
     NEC Europe Ltd.
     Network Laboratories
     Kurfuersten-Anlage 36
     69115 Heidelberg
     Germany

     Phone: +49 6221 90511-15
     EMail: quittek@netlab.nec.de


Nunzi, Quittek, Brunner, Dietz                                 [Page 35]

Internet-Draft                                             December 2003


     Marcus Brunner
     NEC Europe Ltd.
     Network Laboratories
     Kurfuersten-Anlage 36
     69115 Heidelberg
     Germany

     Phone: +49 6221 90511-29
     Email: brunner@netlab.nec.de


     Thomas Dietz
     NEC Europe Ltd.
     Network Laboratories
     Kurfuersten-Anlage 36
     69115 Heidelberg
     Germany

     Phone: +49 6221 90511-28
     Email: dietz@netlab.nec.de


12.  IPR Notices

   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.


13.  Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.

   This document and translations of it may be copied and furnished to


Nunzi, Quittek, Brunner, Dietz                                 [Page 36]

Internet-Draft                                             December 2003


   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation 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.






























Nunzi, Quittek, Brunner, Dietz                                 [Page 37]