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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
