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

[Ladislav Lhotka <[e-mail]>]

On 07. 07. 20 15:57, Juergen Schoenwaelder wrote:
> 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.

If you mean "counter64" in the ietf-yang-types module, then it doesn't
fall apart in JSON, provided that the rules of RFC 7951 are followed.

Lada

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

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67