Re: [OPSAWG] Fw: I-D Action:draft-presuhn-floats-01.txt

["Randy Presuhn" <[e-mail]>]

Hi -

> From: "Andy Bierman" <[e-mail]>
> To: "Juergen Schoenwaelder" <[e-mail]>
> Cc: <[e-mail]>; "Robert Story" <[e-mail]>
> Sent: Tuesday, December 07, 2010 4:13 PM
> Subject: Re: [OPSAWG] Fw: I-D Action:draft-presuhn-floats-01.txt
>
> Adding TCs to the standards track without any use cases seems like a
> bad idea to me.

draft-ietf-ipfix-psamp-mib-02.txt is an example of a use case.
Whether it is a good example or a bad one is another question.
 
> I am not suggesting we revisit the Counter64 debates.
> That led to the logic that a 'rule' is needed to tell implementers
> which data type to use (i.e., wrap in < hour: use Counter64).
> I can imagine WGs defining lots of numbers as Float128 "just in case"
> it is ever needed.  This has an impact on agent performance,
> assuming the agent can even support Float128 at all.

Which will it be?  If you want this (or some other) document to provide
"advice", the nature of the IETF is that that advice will end up being
what looks like a bunch of rules, and those rules will almost certainly
be both over-engineered and short-sighted, like the rules for integer
types in SMI.  Codifying "common sense" is a notoriously difficult thing.

I think the performance argument is really a strawman.  If something is
in a MIB as a floating type, that's presumably because that is the
natural representation for the information, and consequently that
is the most likely internal form anyway.  That's a lot cheaper than
converting it to a human-readable character string, or even 
converting it from an interal float to a scaled integer for SNMP.

> In NETCONF, we got rid of floating point numbers since they
> are rarely needed and not commonly supported in routers and switches.
> I think the decimal64 data type is a good compromise (fixed point).

Fixed point is the wrong answer for data with a potentially large dynamic
range.  Floating point is the wrong answer for data, for example, that
is truly decimal / can be handled adequately by re-thinking the UNITS.
Maybe we need a reference to Knuth vol. 2 chapter 4, though I'd hope
anyone writing code would be aware of these CS basics and could
evaluate the trade-offs.

Randy