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

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Nov 2009 17:14:56 +0100

On Mon, Oct 26, 2009 at 03:27:34PM +0100, David Spakes wrote:

> Between March 11 and June 9, there was a lengthy discussion on this
> list that resulted in a proposal to add a derived type called 'real'
> to draft-ietf-netmod-yang-types-04.  The proposal was submitted in
> its final form (below) before WGLC for draft-ietf-netmod-yang-types-03
> ended on June 10.
> 
> The draft-ietf-netmod-yang-types-04 document is out now and I see that the
> new derived type was not included.  Juergen's alternative proposal to make
> decimal64's fraction-digits substatement be optional (15-May) is not
> reflected in draft-ietf-netmod-yang-08 either.
> 
> Was this omission done intentionally, and if so, why?

Thanks for bringing this up again. Reviewing the mailing list
discussion thread "float vs. decimal", it is difficult for me to
determine a concensus position. What I saw were opinions to

a) add the proposed 'real' typedef
b) make fraction-digits optional, more closely following the XSD approach
c) leave things as they are (not clear the 'real' is needed urgently
   enough to add it now)
d) remove a bunch of other builtin types from YANG and make them typedefs
   instead

So the omission was done intentionally to the extend that I as the
editor do not understand the edits the WG agrees to (but the truth is
that this issue slipped through).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: David Spakes <[email-masked]>
Date: Fri, 6 Nov 2009 12:19:24 -0500 (EST)

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.

-dss

> that this issue slipped through).

-------------------------------------------------------------
 David Spakes                       email:   [email-masked]
 SNMP Research                      voice:   +1 865 573 1434
 3001 Kimberlin Heights Road          fax:   +1 865 573 9197
 Knoxville, TN  37920-9716  USA      http://www.snmp.com
-------------------------------------------------------------

---

From: Andy Bierman <[email-masked]>
Date: Fri, 06 Nov 2009 09:40:19 -0800

> the new typedef in draft-ietf-netmod-yang-08 and was surprised when it

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