> On Jul 7, 2020, at 8:30 AM, Juergen Schoenwaelder > <[email protected]> wrote: > > On Tue, Jul 07, 2020 at 08:27:19AM -0400, Christian Hopps wrote: >> >> Mentioned in the earlier mail >> >> instead of >> >> "decimal64" >> >> use >> >> "type string { pattern '[0-9]+(\.[0-9]+)?'; }" >> > > And then everybody implements what he/she likes? That would be a big > step backward since every implementation will then interpret the > numbers differently.
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". 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. BTW, I think decimal64 is fine for this use-case, I mainly asked on the list b/c I'm curious about the more general use-case. Thanks, Chris. > > /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/> >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
