Re: DECnet MIB question (4) Fri, 21 August 1992 19:00 UTC

Received: from by IETF.NRI.Reston.VA.US id ab04954; 21 Aug 92 15:00 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id ab04950; 21 Aug 92 15:00 EDT
Received: from by NRI.Reston.VA.US id aa14159; 21 Aug 92 15:01 EDT
Received: by; id AA26925; Fri, 21 Aug 92 12:00:59 -0700
Received: by; id AA21360; Fri, 21 Aug 92 11:14:38 -0700
Received: by; id AA21356; Fri, 21 Aug 92 11:14:37 -0700
Received: by; id AA24282; Fri, 21 Aug 92 11:14:36 -0700
Received: by (5.57/ULTRIX-fma-071891); id AA01032; Fri, 21 Aug 92 14:17:18 -0400
Message-Id: <>
To: Debasis Dalapati <>
Subject: Re: DECnet MIB question (4)
In-Reply-To: Your message of "Fri, 21 Aug 92 11:30:08 EDT." <>
Date: Fri, 21 Aug 92 14:17:14 -0400
X-Mts: smtp

The short answer to your question is that the locking counters are there only
because that was how the original DECNet specification is written.   They are
only required for those implementations of the MIB which do not support the
more standard SNMP based counters (DEC products are about the only ones that
come to mind right away).  SNMP based counters (from RFC1155), rather than 
latching at maxvalue (e.g. 65535) are:

"...a non-negative integer which monotonically increases until it
reaches a maximum value, when it wraps around and starts increasing again from
zero.  This memo specifies a maximum value of 2^32-1 ...... for counters"  

The counters which can be zerod in the MIB are those which correspond to the
objects which could be zerod in DECs original specifications - that really was
the reason for including this feature.  For many of groups which have counters
you will see seconds since last zero'd - useful if you see counters at max
value with what appear to be reasonably short time spans since seconds since
last zerod.