Re: proposal for new types in SNMPv2

[Anil Rijsinghani <[e-mail]>]

> >     o Integer64 - for 64-bit quantities that increase at too rapid
> >       a rate to use Integer32 and poll (FddiMsgTimeStamp and
> >       FddiTransitionTimeStamp, 64-bit objects measured in 80 nsec units)
> > 
> >       A guideline for the use of this type, as in the Counter64
> >       definition, would probably be a good idea as well.
> 
> Tell me what the restrictions on use are and I'll tell you whether I
> like it or not.

    It appears that this could be used in two situations, a) where
    the absolute value of an object is of interest, and that value
    could become greater than 32 bits, b) in objects where the
    rate of change is interesting and the rate is too fast.  In case a,
    it's easy to see whether use of this type is necessary or not.
    In b, the restriction could be drawn from the Counter64 one, although
    one hour seems a little too stringent; something like one day would
    be less demanding on the manager.

> >     o Unsigned Integer - we are restricted in the Fddi MIB to using only
> >       (0..2147483647), thus unable to represent half the possible
> >       range.  (I assume Gauge could not be used due to its requirement
> >       to latch)
> 
> This doesn't seem like such a big deal, providing that people are
> already able to implement the BER for Gauge correctly.  (It's that fifth
> octet that people keep screwing up...)

    Would an implementation hint in the SMI document be in order for
    all types susceptible to such an error?

    Anil