Re: Floating point usage in a MIB module

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

The below is broken. I proposed a valid approach many years
ago. (Of course there are other valid approaches, and I believe
that they have been summarized in the FAQ for news group
COMP.PROTOCOLS.SNMP.)
The approach that I proposed is implemented in the NET-SNMP
agent and manager.

Until we go to, say, SMIv2.1 there is no easy way to support
display hints for floats. It's not the easy cases, but the
hard ones like plus infinity that makes the work difficult.

I truely believe that floats are important. And even though
the last time we talked about this, and Jeff Case and Andy Bierman
were againest it due to the costs, I understand their concern
but do not agree with the extent of the costs, and believe the
benefits are quite great.

Note, octet string (a binary encoding) is workable, but
quite undesirable. Also, note that there are many ways
to provide a value other than FLOAT in the TC below.

On Thu, 29 Jan 2004, Wijnen, Bert (Bert) wrote:
> MIB Doctors, do we believe that this is a proper
> way to express a 32-bit floating point number?
> 
>   TeLinkBandwidth ::= TEXTUAL-CONVENTION
>     DISPLAY-HINT "d"
>     STATUS       current
>     DESCRIPTION
>        "This type is used to represent link bandwidth in bps. This
>         value is represented using a 32 bit IEEE floating point
>         format."
>     REFERENCE
>        "IEEE Standard for Binary Floating-Point Arithmetic,
>         Standard 754-1985"
>     SYNTAX       Unsigned32
> 
> I think that at least the DISPLAY-HINT seems weird here, no?
> Now, the author may have done so because of a warning he got if there
> was no display hint.
> 
> But is Unsigned32 the best way? Or would an OCTET STRING SIZE(4) be better
> with a DISPLAY HINT of "1d.3d" or something like that. I don't think
> we have a way to properly provide a DISPLAY-HINT for a float, do we?
> 
> Thanks,
> Bert 
> 
Regards,
/david t. perkins