Subject: Re: [netmod] Y59: what about decimal56 data type?

From: Randy Presuhn <[email-masked]>
Date: Tue, 30 Dec 2014 11:44:10 -0800 (GMT-08:00)

Hi -

>From: Juergen Schoenwaelder <[email-masked]>
>Sent: Dec 30, 2014 10:11 AM
>To: Randy Presuhn <[email-masked]>
>Cc: "[email-masked]" <[email-masked]>
>Subject: Re: [netmod] Y59: what about decimal56 data type?
>
>On Tue, Dec 30, 2014 at 09:04:24AM -0800, Randy Presuhn wrote:
>> 
>> I think one might encounter them in performance statistics, where they'd
>> typically end up being configured only for setting thresholds defined in
>> terms of those statistics.  Experience with RFC 6340 suggests that while
>> the use cases may exist, the situations where floating point is the best
>> solution are relatively rare.
>>
>
>The RFC 6340 definintions are used by the following IETF MIB modules:
>
>- TED-MIB
>
>  Used to model bandwidth in bytes per second (tedMaxBandwidth,
>  tedMaxReservableBandwidth, tedUnreservedBandwidthPri0, ...,
>  tedUnreservedBandwidthPri7).

Definitely a questionable use.  Unsigned32 doesn't have
quite enough dynamic range, so some sort of hack would be
needed, but float just seems wrong to me.

>- PSAMP-MIB
>
>  Use for a probability (psampSampUniProbProbability).

This seems fairly legitimate, but my choice would
have been a scaled integer rather than float, unless
the near-universal underlying implementation technology
is IEEE float.

>- NHDP-MIB
>
>  Used for a quality value between 0 and 1 (nhdpHystAcceptQuality,
>  nhdpHystRejectQuality, nhdpInitialQuality).

Although my intuition would again be to go with a scaled integer
for this, I'd be willing to be persuaded if the implementations
consistently used float internally.

>I argue that none of them needs floating point numbers.

Agreed, none of these specific cases seems to meet the
requirements for *both* dynamic range and precision that
would justify using float.

Randy