Subject: [OPSAWG] Fw: I-D Action:draft-presuhn-floats-00.txt

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 2 Dec 2010 08:54:53 -0800

Hi -

As a result of discussion on the MIB doctors' list, I've put together an
internet draft with textual conventions for floating point numbers.  There
is currently some work in progress, such as
http://datatracker.ietf.org/doc/draft-ietf-ipfix-psamp-mib/
which has a need for floats.  Rather than have a proliferation of
module-specific flavors of floats scattered through IETF (and
vendor) MIB modules, it would make sense to have
a standardized (small) set of options.  This draft is a step in that
direction. 

This probably should be standards-track, if we would like it to be used
by standards-track documents needing floats.

Would this WG be interested in taking this mercifully brief draft
as a WG item?

I believe it is very nearly ready for publication, given its very narrow
scope.  The only issue I am aware of is that while it tries to cite the
current version of the IEEE spec, the xml2rfc citation library only has
a very ancient version.

Randy

----- Original Message ----- 
> From: <[email-masked]>
> To: <[email-masked]>
> Sent: Monday, November 29, 2010 2:45 PM
> Subject: I-D Action:draft-presuhn-floats-00.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> Title           : Textual Conventions for the Representation of Floating-Point Numbers
> Author(s)       : R. Presuhn
> Filename        : draft-presuhn-floats-00.txt
> Pages           : 7
> Date            : 2010-11-29
> 
> This memo defines a Management Information Base (MIB) module
> containing textual conventions (TCs) to represent floating-point
> numbers.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-presuhn-floats-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
...

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 2 Dec 2010 21:51:57 +0000

Hi Randy,

I like your idea very much.

For the PSAMP-MIB module we defined a TC called PsampFloat64 in exactly the
same way as you do it in your draft.

We received a comment to rename PsampFloat64 to Float64TC with the intention
to have it re-used by future MIB modules, similarly to Unsigned64TC defined
in the APPLICATION-MIB module. The problem with this approach is that it is
hard to find general purpose TCs spread over a number of very specific MIB
modules.

Collecting them in a MIB module that serves this purpose only seems to me
the preferable approach.

I support making this a WG item. And yes, it has to be standards track,
otherwise it would not be very useful.

I have some comments on the draft that I will post in a separate email.

    Juergen

On 03.12.10 01:54  "Randy Presuhn" <[email-masked]> wrote:

> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: Robert Story <[email-masked]>
Date: Thu, 2 Dec 2010 20:51:49 -0500

On Thu, 2 Dec 2010 21:51:57 +0000 Juergen wrote:
JQ> I like your idea very much.

Me too. But I think it's just a teensy bit to narrow. Rather than a
FLOAT-TC-MIB, I'd like to see a NUMERIC-TC-MIB, and include Integer64
and Unsigned64.

-- 
Robert Story
Senior Software Engineer
SPARTA (dba Cobham Analytic Soloutions)

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 2 Dec 2010 19:57:48 -0800

Hi -

> From: "Robert Story" <[email-masked]>
> To: "Juergen Quittek" <[email-masked]>
> Cc: "Randy Presuhn" <[email-masked]>; <[email-masked]>
> Sent: Thursday, December 02, 2010 5:51 PM
> Subject: Re: [OPSAWG] Fw: I-D Action:draft-presuhn-floats-00.txt
...
> FLOAT-TC-MIB, I'd like to see a NUMERIC-TC-MIB, and include Integer64

I'd rather not add those to this document.  My experience with getting
what became RFC 2856 through the process leads me to think that
that it could take much longer to reach consensus on 64-bit integers.

My suggestion would be that if folks really want to do more 64-bit
integer TCs, a revision of RFC 2856 might be a sensible route,
rather than having some 64-bit integer support in that document's
MIB module and the rest in this one's.

Randy