Re: [netmod] Justification for decimal64 over string for floating point values in geo location data?

[Juergen Schoenwaelder <[e-mail]>]

On Tue, Jul 07, 2020 at 09:24:31AM -0400, Christian Hopps wrote:
> 
> I dislike having to specify arbitrary limits b/c of the type. I think it would be useful to have integer and real number support that allowed for specifying "at least" precision, but not forcing the model to specify an "at most".
>

You can have defined limits or undefined limits with implementation
specific limits (only rarely you find implementations that de-facto
have no limits).

> In generally I dislike many of the specified semantic restrictions I
> find in YANG models, they seem to be the most oft-cited examples of
> when a "backward incompatible" change might need to be made to a
> model.
 
ASN.1 had INTEGER, a type of unlimited precision. In the early SNMP
days things started to fail to interoperate when you hit the 16-bit
limit. JSON (much newer) has numbers that start to become interesting
when you need more precision, a simple 64-bit counter starts falls
apart in JSON.

I can't tell how many of the "backward incompatible" changes are due
to picking too restrictive types.

/js

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