Re: [yang-doctors] 6991bis

[Robert Wilton <[e-mail]>]

Hi Juergen,

I agree that care is needed with floats/doubles, and I also agree that 
in many cases decimal64 is a better choice.  But that doesn't seem like 
a good argument to exclude them from the language entirely.

Performance wise, or modern hardware, floats/doubles are comparable to 
32/64 bit integers, and in some scenarios faster (e.g. divide operations).

I think that as YANG potentially extends to control/configure more 
devices than just network devices (e.g. servers, or as operators use 
YANG to model services and higher level abstractions, they will probably 
find the omission of floating point types to be somewhat frustrating).

But I can see that this is really a discussion for YANG.next rather than 
6991bis.

Thanks,
Rob


On 22/03/2018 11:39, Juergen Schoenwaelder wrote:
> 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