Re: [netmod] float vs. decimal (fwd)

[Andy Bierman <andy at netconfcentral.com>]

David Spakes wrote:
> Don't forget that decimal64 wasn't the original proposal...!
> In February/March of this year, a big part of my day was spent
> implementing the float32 and float64 types that were described in an
> earlier draft.  We had that code working reasonably well when decimal64
> came along, and afterwards a lot had to be jettisoned.  :-)
> 
> Back then, there seemed to be several voices on the mailing list
> expressing concern that by moving from float32/float64 to decimal64, YANG
> was losing the ability to express infinitely large and infinitely small
> numbers.  I was not one of those voices.  My concern about decimal64 then
> and now is that the document writer must specify a fixed decimal position
> when defining a leaf.
> 
> So from my viewpoint, there was never a complete concensus on the proposal
> for having the decimal64 built-in type in YANG in the first place.
> 
> Both 'a' and 'b' were proposed as compromise positions to allow the
> working group to come to concensus on the acceptance of decimal64.  Some
> members of the list objected to 'b' because it was important to their
> concerns to keep the fraction-ditits statement as a required substatment.
> 
> The value of the compromise proposal 'a' is that the decimal64 type
> remains defined exactly as it is today.  The 'real' typedef is a union of
> many forms of decimal64, and that is something any document writer can do
> today without the typedef.  My argument for adding the typedef is that it
> encourages all document writers who need a floating decimal point to
> define the leaf in exactly the same way.
> 
> There were no substantial arguments against the 'real' typedef that I can
> recall.  I took the absence of meaningful counterargument against the
> 'real' typedef as a vote for compromise and concensus.  I expected to find
> the new typedef in draft-ietf-netmod-yang-08 and was surprised when it
> wasn't there.
> 

It should not be surprising.  Only changes that
have WG consensus get added, especially after a
WGLC has been done for the draft.

Derived types are all the same to the client and server code.
This is a higher-level data-modeling decision -- whether or
not the 'real' typedef is something that WGs should reuse,
or must build-their-own from decimal64.

Data modeling decisions like typedefs are very subjective.
I don't object to 'real' being added to yang-types, but
it doesn't seem very important.  The 'real' data type has not
been needed in SMIv2, so why is it needed in YANG?
We determined that decimal64 was more appropriate, based
on use cases.  I don't see why we need to emulate a 'real'
data type in YANG.


> -dss


Andy