Subject: Re: [netmod] float vs. decimal

From: David Spakes <[email-masked]>
Date: Fri, 1 May 2009 16:54:01 -0400 (EDT)

If I read section 9.3 of draft-ietf-netmod-yang-05.txt correctly, and
if I didn't punch any incorrect keys on my keyboard, and assuming the
implementation of Microsoft's calc.exe works correctly on my PC, I
calculate the largest positive and largest negative values that can be
represented in a decimal64 as follows:

  largest int64 = (2^63)-1  =  9223372036854775807
  smallest int64 = -(2^63)  = -9223372036854775808

  10^-1  = 0.1
  10^-18 = 0.000000000000000001

  (largest int64)*(10^-1)   =  922337203685477580.7
  (largest int64)*(10^-18)  =  9.223372036854775807
  (smallest int64)*(10^-18) = -9.223372036854775808
  (smallest int64)*(10^-1)  = -922337203685477580.8

Largest positive value that can be represented in a decimal64:
    922337203685477580.7

Largest negative value that can be represented in a decimal64:
   -922337203685477580.8

I think the text in the draft is clear and concise, however, I don't
believe in the average software developer's ability to arrive at the
same numbers that I just did.  From years ago when I worked in a support
role, I can still remember having unpleasant conversations with a clients;
e.g., one who argued that some code was broken, because he insisted that
a Megabyte is 1,000,000 bytes, not 1,048,576 bytes.  As one of Jeff Case's
down-on-the-farm sayings goes, "Your mileage may vary."

Therefore, before this draft goes to publication, I would like to see the
following text added for clarity:

   The largest positive value that can be represented as a decimal64
   is 922337203685477580.7.  The largest negative value that can be
   represented as a decimal64 is -922337203685477580.8.

Regards,

David Spakes

On Thu, 30 Apr 2009, David Partain wrote:

> Re: [netmod] Working Group Last Call: draft-ietf-netmod-yang-05.txt
>
> Dear all,
>
> This is the working group last call on the current working group
> document:
>
> - YANG - A data modeling language for NETCONF:
> http://tools.ietf.org/html/draft-ietf-netmod-yang-05.txt
>
> The authors and the chairs think that this document is mature enough for
> WGLC.  This WGLC will last until May 15, 2009.
>
> Please review and send comments to this list.
>
> Thanks.
>
> David^2
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

-------------------------------------------------------------
 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: Sun, 03 May 2009 13:05:14 -0700

>   smallest int64 = -(2^63)  = -9223372036854775808

I think the ranges are different for each value of fraction-digits:

fd         min                       max
---------------------------------------------------------
1      -922337203685477580.8        922337203685477580.7
2      -92233720368547758.08        92233720368547758.07
3      -9223372036854775.808        9223372036854775.807
4      -922337203685477.5808        922337203685477.5807
5      -92233720368547.75808        92233720368547.75807
6      -9223372036854.775808        9223372036854.775807
7      -922337203685.4775808        922337203685.4775807
8      -92233720368.54775808        92233720368.54775807
9      -9223372036.854775808        9223372036.854775807
10     -922337203.6854775808        922337203.6854775807
11     -92233720.36854775808        92233720.36854775807
12     -9223372.036854775808        9223372.036854775807
13     -922337.2036854775808        922337.2036854775807
14     -92233.72036854775808        92233.72036854775807
15     -9223.372036854775808        9223.372036854775807
16     -922.3372036854775808        922.3372036854775807
17     -92.23372036854775808        92.23372036854775807
18     -9.223372036854775808        9.223372036854775807

>    represented as a decimal64 is -922337203685477580.8.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 03 May 2009 22:15:54 +0200 (CEST)

> I think the ranges are different for each value of fraction-digits:

[table deleted]

Exactly.  It is important to note that the full type is decimal64 + a
fixed value for fraction-digits.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sun, 03 May 2009 13:20:09 -0700

> fixed value for fraction-digits.

Do you think the table should go in the draft?

Andy

---

From: David Spakes <[email-masked]>
Date: Mon, 4 May 2009 10:44:26 -0400 (EDT)

> I think the ranges are different for each value of fraction-digits:

I fully agree, Andy.

To choose a value for fraction-digits, the designer must find the
correct balance between magnitude and precision for the application.
The greater the precision, the smaller the magnitude that can be
represented.  The greater the magnitude, the samller the precision
that can be represented.

Note than in your entire table, the largest-magnitude positive number is
922337203685477580.7 and the largest-magnitude negative number is
-922337203685477580.8.  Both are achieved when fraction-digits specifies
the coarsest precision of 1.

> Do you think the table should go in the draft?

I originally proposed only that the largest-magnitude positive number and
the largest-magnitude negative number be stated in the text.  However, I
would be in favor of including your table in the draft if others are also
in favor, since it conveys in no uncertain terms the choices for balancing
magnitude and precision.

Regards,

David Spakes

---

From: David Reid <[email-masked]>
Date: Wed, 13 May 2009 11:44:22 -0400

I was re-reading the decimal64 section and I think David's idea of listing
the upper an lower bounds is helpful. Andy's chart makes it even more clear.
I think decimal64 is kind of a wierd type that people won't be used to, so
any help the document can give is good.

-David Reid

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Mon, 18 May 2009 00:34:46 +0200

Sofar (I have reviewed the document up to (and including) page 109, I have
not seen any showstoppers. In general, this is a well written document.

My review comments, none of them are fatal or showstoppers:

- I suspect (but am not sure) that either IESG members or RFC-Editor may
  want us to expand acronyms like YANG and YIN when we first use them.
  In fact that applies to all acronyms we use.
  
- In the abstract, I would leave out the 1st par.
  Certainly, in a year or so, the statement is (hopefully) no longer true.
  Besides, it is more of a "sales" statement than anything else.
  In the second para it states:
    YANG models the operations and content layers of NETCONF ...
  I guess you/we mean: YANG is used to model the .....

- Page 11:
  o  MIB: A Management Information Base, traditionally referring to a
     management information defined using SNMP's SMI.

  I would say either "A Management Information Base Module" or "Management Information Base"
  And "a management information defined" probly should be "a management information model defined.." ??
  Or maybe just remove the "a".

- Page 12
   o  A container node without a "presence" statement, which has has at
      least one mandatory node as a child.
  s/has has/has/

- Page 13
   scripts to operate on the models.  The conversion from YANG to YIN is
   loss-less, so content in YIN can round-tripped back into YANG.
  s/can round-tripped/can be round-tripped/ ??

- Page 21
  Not that it matters much, but when I see:
     typedef percent {
         type uint16 {
             range "0 .. 100";
         }
         description "Percentage";
     }

  I always wonder: why is this s uint16 and not a uint8 ??

- Page 25
  The name of the example notification "link-failure" is a bit strange
  Specifically since the example notification informs about a "link UP" condition,
  so that is recovery from a failure. Maybe better to name it "link-status-change"
  or some such?

- Page 29, sect 5.2
    The name of the file SHOULD be on the form:
  s/on the form/of the form/

- Page 47, section 7.1.10 states/uses:
              Phone: +1 800 555 0815
  According to www.ietf.org/ID-Checklist.html section 3.6.D I think we better use
              Phone: +1 800 555 0100

- Same in section 7.2.3

- Page 64, section 7.7.3, 3rd line
       A valid leaf-list or list MUST have least min-elements entries.
  s/have least/have at least/

I have reviewed up to (and including) page 109.

Bert
  ----- Original Message ----- 
  From: David Partain 
  To: [email-masked] 
  Sent: Thursday, April 30, 2009 9:04 AM
  Subject: [netmod] Working Group Last Call: draft-ietf-netmod-yang-05.txt

  Dear all,

  This is the working group last call on the current working group document:

  The authors and the chairs think that this document is mature enough for WGLC.  
  This WGLC will last until May 15, 2009.

  Thanks.

  David^2

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 18 May 2009 13:25:16 +0200 (CEST)

Hi Bert,

>   In fact that applies to all acronyms we use.

I will check all the acronyms.

>   Besides, it is more of a "sales" statement than anything else.

Removed.

>   I guess you/we mean: YANG is used to model the .....

Fixed.

>   Or maybe just remove the "a".

Removed both 'a's:

- MIB: Management Information Base, traditionally referring
  to management information defined using SNMP's SMI.

>       least one mandatory node as a child.

Fixed.

>   s/can round-tripped/can be round-tripped/ ??

Fixed.

>   I always wonder: why is this s uint16 and not a uint8 ??

Fixed.

>   so that is recovery from a failure. Maybe better to name it

Actually it is the if-admin-status that is included (just as
ifAdminStatus is included in the linkDown SNMP notification).

>   s/have least/have at least/

All of the above fixed.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 20 May 2009 22:45:46 +0200 (CEST)

Hi,

> I will check all the acronyms.

I found http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt
and I think it makes sense to follow it.  I suggest we remove the
defintion of MIB from our terminology list (it's well known according
to the ref above, and we just use it in one location), and I expanded
NETCONF and YIN.  I would like to keep YANG as being just a name.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 20 May 2009 23:15:19 +0200 (CEST)

> Do you think the table should go in the draft?

I have added the table to the draft:

   The following table lists the minimum and maximum value for each
   fraction-digit value:

     +----------------+-----------------------+----------------------+
     | fraction-digit | min                   | max                  |
     +----------------+-----------------------+----------------------+
     | 1              | -922337203685477580.8 | 922337203685477580.7 |
     | 2              | -92233720368547758.08 | 92233720368547758.07 |
     | 3              | -9223372036854775.808 | 9223372036854775.807 |
     | 4              | -922337203685477.5808 | 922337203685477.5807 |
     | 5              | -92233720368547.75808 | 92233720368547.75807 |
     | 6              | -9223372036854.775808 | 9223372036854.775807 |
     | 7              | -922337203685.4775808 | 922337203685.4775807 |
     | 8              | -92233720368.54775808 | 92233720368.54775807 |
     | 9              | -9223372036.854775808 | 9223372036.854775807 |
     | 10             | -922337203.6854775808 | 922337203.6854775807 |
     | 11             | -92233720.36854775808 | 92233720.36854775807 |
     | 12             | -9223372.036854775808 | 9223372.036854775807 |
     | 13             | -922337.2036854775808 | 922337.2036854775807 |
     | 14             | -92233.72036854775808 | 92233.72036854775807 |
     | 15             | -9223.372036854775808 | 9223.372036854775807 |
     | 16             | -922.3372036854775808 | 922.3372036854775807 |
     | 17             | -92.23372036854775808 | 92.23372036854775807 |
     | 18             | -9.223372036854775808 | 9.223372036854775807 |
     +----------------+-----------------------+----------------------+

/martin