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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
