Subject: [Disman] ping-mib-2, traceroute-mib-3

From: Giorgio Nunzi <[email-masked]>
Date: Wed, 28 Jan 2004 12:07:51 +0100

Dear all,

I collected some notes regarding the REMOPS MIBs.

I start with two similar remarks for the ping-mib and the traceroute-mib.
Looking at the ping-mib, if the value of pingCtlFrequency is different
from zero, then the ping tests can be processed forever, dealing to
theoretically infinitive values of the objects
pingResultsProbeResponses and pingResultsSentProbes.

pingCtlFrequency  OBJECT-TYPE
     SYNTAX      Unsigned32
     UNITS       "seconds"
     MAX-ACCESS  read-create
     STATUS      current
     DESCRIPTION
         "The number of seconds to wait before repeating a ping test
         as defined by the value of the various objects in the
         corresponding row.

         A single ping test consists of a series of ping probes.
         The number of probes is determined by the value of the
         corresponding pingCtlProbeCount object.  After a single
         test completes the number of seconds as defined by the
         value of pingCtlFrequency MUST elapse before the
         next ping test is started.

         A value of 0 for this object implies that the test
         as defined by the corresponding entry will not be
         repeated."
     DEFVAL { 0 }
     ::= { pingCtlEntry 10 }

   pingResultsProbeResponses OBJECT-TYPE
     SYNTAX      Unsigned32
     UNITS       "responses"
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "Number of responses received for the corresponding
         pingCtlEntry and pingResultsEntry.  The value of this object
         MUST be reported as 0 when no probe responses have been
         received."
     ::= { pingResultsEntry 7 }

   pingResultsSentProbes OBJECT-TYPE
     SYNTAX      Unsigned32
     UNITS       "probes"
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "The value of this object reflects the number of probes sent
         for the corresponding pingCtlEntry and pingResultsEntry.
         The value of this object MUST be reported as 0 when no probes
         have been sent."
     ::= { pingResultsEntry 8 }

The values of pingResultsProbeResponses and pingResultsSentProbes are
subjected to grow as long as the test is active and the related value
of pingCtlFrequency is different from 0, so I suggest to change the
SYNTAX clause of both objects to Gauge32.

Similarly, in the traceroute-mib the objects
traceRouteResultsTestAttempts and traceRouteResultsTestSuccesses
should be changed to Gauge32.

  traceRouteResultsTestAttempts OBJECT-TYPE
     SYNTAX      Unsigned32
     UNITS       "tests"
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "The current number of attempts to determine a path
         to a target.  The value of this object MUST be started
         at 0."
     ::= { traceRouteResultsEntry 6 }

  traceRouteResultsTestSuccesses OBJECT-TYPE
     SYNTAX      Unsigned32
     UNITS       "tests"
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "The current number of attempts to determine a path
         to a target that have succeeded.  The value of this
         object MUST be reported as 0 when no attempts have
         succeeded."
     ::= { traceRouteResultsEntry 7 }

Does someone agree?

Giorgio

-- 
Giorgio Nunzi
Network Laboratories              Heidelberg, Germany
NEC Europe Ltd.                   http://www.netlab.nec.de