On 14. Sep 2021, at 21:16, Jürgen Schönwälder <j.schoenwael...@jacobs-university.de> wrote: > > Carsten, > > whatever you do, you will at the end need an extra bit.
Sure. There are 65537 values, so you need at least 16.000022 bits :-) > If BBF already > defined to use -1, so be it. That works for me and is consistent with the information model in 9046. What I find not so great is the side effect of going from uint16 to int32. I don’t see a big difference between Optional-uint16 = uint16 / -1 and Optional-uint16 = uint16 / empty I do not like Optional-uint16 = int32 > The alternative is to not instantiate the leaf if there is no value > and to accept that a client can't tell the difference between 'there > is no value' and 'the value has been suppressed by authorization'. Interesting. I wasn’t aware that this cannot be distinguished in YANG. But an “empty” would be present if it is chosen, no? Grüße, Carsten > > /js > > PS: You can define a maybe-uint16 type as a union in YANG but yes > there is no syntactic sugar to generalize this. > > On Tue, Sep 14, 2021 at 08:36:12PM +0200, Carsten Bormann wrote: >> On 14. Sep 2021, at 19:17, Jürgen Schönwälder >> <j.schoenwael...@jacobs-university.de> wrote: >>> >>> If other data models use an extended integer range and -1 to indicate >>> a special case, then this may be a strong reason to do the same in the >>> IETF YANG data model. >> >> Any data model based on FORTRAN certainly will do. >> Most other data modeling languages by now should have >> nullable/optional/Maybe types. >> >> Going from the actual data type, uint16, to int32, just to accommodate the >> “not present” case, strikes me as a mistake. >> (Which doesn’t mean that you may not want to do this in an implementation, >> after having validated the input data.) >> >> Grüße, Carsten >> > > -- > 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/> > > _______________________________________________ > babel mailing list > ba...@ietf.org > https://www.ietf.org/mailman/listinfo/babel _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
