Re: [yang-doctors] 6991bis

[Juergen Schoenwaelder <[e-mail]>]

There was a long discussion during the design of YANG whether YANG
should have floating point types and the outcome back then was it
should not. I understand that some QoS standards do use floating point
formats but in general networking stacks do prefer to not use floating
point numbers - due to hardware constraints but also due to floating
point numbers are fragile and easily "wrong" unless you are very
careful with them. Unless you need to cover a huge range, types such
as decimal64 are usually faster and much more precise.

/js

On Thu, Mar 22, 2018 at 11:16:13AM +0000, Robert Wilton wrote:
> Not necessarily a discussion for here (and I've been told that it has
> happened before), but Rob/Lou were discussing their desire to see IEEE float
> (and presumably also IEEE double) types defined in YANG.
> 
> routing-types.yang (RFC 8294) defines bandwidth-ieee-float32, but ends up
> using a string as the base type (fine for text based encoding schemes, not
> so great for binary encoding schemes). Apparently OpenConfig have a similar
> definition that ends up with binary as the base type, but that also has its
> own problems.
> 
> Thanks,
> Rob
> 
> 
> On 22/03/2018 11:04, Reshad Rahman (rrahman) wrote:
> > Date is the only definition I am aware of, I was expecting/hoping the more experienced YDs would have more.
> > 
> > Regards,
> > Reshad.
> > 
> > 
> > On 2018-03-22, 11:01 AM, "Juergen Schoenwaelder" <[e-mail]> wrote:
> > 
> >      On Thu, Mar 22, 2018 at 10:28:02AM +0000, Reshad Rahman (rrahman) wrote:
> >      >
> >      > On Tuesday we discussed adding a typedef for date to avoid modules having to define their own. Is it worth doing a bis document just for this? Are there more common YANG types which need to be added?
> >      >
> >      What we can do is to start a 6991bis I-D to collect new definitions
> >      but pushing such a bis I-D through the whole process just for adding
> >      'date' is likely too costly.
> >      The last time we updated the common typedefs, the comments received
> >      during IESG processing were mostly concerning definitions we did not
> >      add or change, and this might happen again. Some of that was useful
> >      since terminology is often becoming better defined but sometimes this
> >      also leads to interesting alignment and compability issues. While
> >      there are errata pointing to 'internal' (yang related) terminology
> >      issues, it may be necessary to also carefully check alignment with
> >      other terminology documents that are coming along, such as
> >      draft-ietf-dnsop-terminology-bis-09.
> >      Anyway, which other definitions have we seen commonly used that could
> >      benefit from moving into 6991bis (and which are not covered by say
> >      routing types)?
> >      /js
> >      --
> >      Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >      Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> >      Fax:   [phone]         <https://www.jacobs-university.de/>
> > 
> > _______________________________________________
> > yang-doctors mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/yang-doctors
> 

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>