Subject: [netmod] new YANG 1.1 issue: support for IEEE754 types

From: Robert Varga <[email-masked]>
Date: Thu, 24 Apr 2014 17:13:01 +0200

Hi everyone,

while modeling some protocols (notably RSVP), we came across the need to 
represent IEEE754-2008 floating types without losing precision. I'd like 
to ask what is the group's sentiment regarding extending the base types 
with at least binary{32,64} (which have their counterparts in XML schema 
datatypes).

Thanks,
Robert

---

From: Andy Bierman <[email-masked]>
Date: Thu, 24 Apr 2014 08:20:47 -0700

On Thu, Apr 24, 2014 at 8:13 AM, Robert Varga <[email-masked]> wrote:

> represent IEEE754-2008 floating types without losing precision. I'd like to
> ask what is the group's sentiment regarding extending the base types with
> at least binary{32,64} (which have their counterparts in XML schema
> datatypes).
>
>
YANG originally had float32 and float64 types.
Networking vendors objected to mandatory floating-point support
as being too heavy-weight. (I tend to agree).

Our code still has float64 support because XPath needs it.
I think you could define these types with typedefs, which would make
them optional to implement.

Thanks,
> Robert

Andy

---

From: Robert Varga <[email-masked]>
Date: Thu, 24 Apr 2014 22:40:51 +0200

On 04/24/2014 05:20 PM, Andy Bierman wrote:
> On Thu, Apr 24, 2014 at 8:13 AM, Robert Varga <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi everyone,
>
>     while modeling some protocols (notably RSVP), we came across the
>     need to represent IEEE754-2008 floating types without losing
>     precision. I'd like to ask what is the group's sentiment regarding
>     extending the base types with at least binary{32,64} (which have
>     their counterparts in XML schema datatypes).
>
>

Can you elaborate on where the weight is coming from?

It seems to me that this is not necessarily a concern on network 
devices, as they provide the models, so they do not need to support 
floating types if they don't use them. Furthermore, I don't think having 
a base type implies having an arithmetic unit capable of working on it 
-- it's just the ability to store the value.

> them optional to implement.

I think we've done precisely what you're suggesting for OpenDaylight ( 
https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob_plain;f=concepts/src/main/yang/ieee754.yang;hb=HEAD 
):

         typedef float32 {
		type binary {
			length 4;
		}
	}

The problem with this approach is that it does not play nicely with 
RESTCONF, as the binary base type forces BASE-64 encoding, which 
confuses users, who expect bandwidth (specifically) to be a number, not 
a bunch of characters.

Another solution to this would be to standardize the typedef definition 
and have RESTCONF draft provide a special-case handling for these types.

Thanks,
Robert

---

From: Andy Bierman <[email-masked]>
Date: Thu, 24 Apr 2014 14:02:14 -0700

> Can you elaborate on where the weight is coming from?
Floating point is rarely needed.
The WG decided to use decimal64 instead.

> It seems to me that this is not necessarily a concern on network devices,
> as they provide the models, so they do not need to support floating types
> if they don't use them. Furthermore, I don't think having a base type
> implies having an arithmetic unit capable of working on it -- it's just the
> ability to store the value.
>
>
> https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob_plain;f=concepts/src/main/yang/ieee754.yang;hb=HEAD):
>
>         typedef float32 {
> 		type binary {
> 			length 4;
> 		}
> 	}
>
>
> RESTCONF, as the binary base type forces BASE-64 encoding, which confuses
> users, who expect bandwidth (specifically) to be a number, not a bunch of
> characters.
>
I don't want RESTCONF to use a different YANG language than other protocols.
This is a very minor issue.  Why do humans need to look at the encoding?
RESTCONF is supposed to be a programmatic API.

You could use type string if you really wanted to make the encoding
readable.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 25 Apr 2014 08:38:59 +0200 (CEST)

> The WG decided to use decimal64 instead.

+1.

We had long discussions about this - search the archives for "float"
around 2008/2009.  A proposal for adding these types back should have
answers for the problems we found that got us to remove them.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 25 Apr 2014 10:04:42 +0200 (CEST)

Hi,

Added as Y40.

/martin

Robert Varga <[email-masked]> wrote:
> Hi everyone,
> 
> while modeling some protocols (notably RSVP), we came across the need
> to represent IEEE754-2008 floating types without losing precision. I'd
> like to ask what is the group's sentiment regarding extending the base
> types with at least binary{32,64} (which have their counterparts in
> XML schema datatypes).
> 
> Thanks,
> Robert
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>