[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 32-bit and 64-bit counters
Hi -
> From: "Kristine Adamson" <adamson@us.ibm.com>
> To: <ietfmibs@ops.ietf.org>
> Sent: Wednesday, October 27, 2004 10:35 AM
> Subject: 32-bit and 64-bit counters
>
> Hello.
> We are reviewing the current draft of the TCP-ESTATS-MIB, which is a
> new MIB that provides additional statistics for TCP Listeners and
> connections. The MIB currently proposes defining both 32-bit and 64-bit
> counters for the same statistics, using the characters HC (for "high
> capacity") in the object name to distinguish the 2 counters.
> We were wondering if it would be appropriate to just define 64-bit
> counters instead of defining 32-bit counters also. We referenced the
> "Guidelines for Authors and Reviewers of MIB Documents" document, which
> states the following under section 4.6.1.2:
>
> RFC 2578 Section 7.1.10 places a requirement on "standard" MIB
> modules that the Counter64 type may be used only if the information
> being modelled would wrap in less than one hour if the Counter32 type
> was used instead. Now that SNMPv3 is an Internet Standard and SNMPv1
> is Historic (see http://www.rfc-editor.org/rfcxx00.html for status
> and [RFC3410] for rationale) there is no reason to continue enforcing
> this restriction. Henceforth "standard" MIB modules MAY use the
> Counter64 type when it makes sense to do so, and MUST use Counter64
> if the information being modelled would wrap in less than one hour if
> the Counter32 type was used instead.
>
> Does the sentence "Henceforth _standard_ MIB modules MAY use the Counter64
> type when it makes sense to do so" mean that MIB authors are not always
> required to define both 32-bit and 64-bit counters for the same data?
...
I think the primary thrust of the statement in the MIB review guidelines
was to remove the prohibition against using Counter64 for things
that might take more than an hour to wrap as Counter32. The secondary
question is whether the redundant Counter32 objects can now be
avoided. In my opinion the answer should be "yes", but I don't think
the MIB review guidelines as currently written directly answer this question.
Randy