A related question. > On Sep 14, 2021, at 12:31 PM, Mahesh Jethanandani <mjethanand...@gmail.com> > wrote: > > Hi Martin, > >> On Sep 14, 2021, at 11:17 AM, Martin Björklund <mbj+i...@4668.se >> <mailto:mbj+i...@4668.se>> wrote: >> >> Mahesh Jethanandani <mjethanand...@gmail.com >> <mailto:mjethanand...@gmail.com>> wrote: >>> Hi Juergen, >>> >>>> On Sep 14, 2021, at 10:17 AM, Jürgen Schönwälder >>>> <j.schoenwael...@jacobs-university.de >>>> <mailto:j.schoenwael...@jacobs-university.de>> wrote: >>>> >>>> On Tue, Sep 14, 2021 at 01:51:36PM +0000, STARK, BARBARA H wrote: >>>> >>>>> As I mentioned, BBF TR-181 uses int with range -1:65535 with -1 >>>>> meaning NULL. So I certainly have no issue with that approach. The >>>>> language in RFC9046 was intended to make sure this approach was allowed, >>>>> since this is how it's done in TR-181. >>>>> I guess I am a bit surprised to learn that YANG doesn't seem to have a >>>>> preferred way to handle this. Unfortunately, given my considerable lack >>>>> of YANG expertise, I can't recommend the "right" way to model this in >>>>> YANG. I can only insist that the model be able to express a value in the >>>>> range 0 to 2^16 and NULL value for these parameters. >>>>> Independent of the fact that the words in RFC9046 don't seem to have >>>>> expressed this perfectly clearly, that is absolutely the intent of those >>>>> words. I apologize that the RFC9046 words don't seem to be sufficiently >>>>> clear. >>>>> >>>>> Since you do mention the possibility of using -1 for NULL, I'd like to >>>>> understand who might find this approach unacceptable? The language in the >>>>> information model was definitely intended to express the acceptability of >>>>> using this approach from a Babel WG perspective (because I knew that's >>>>> how it would be done in TR-181). Would this be unacceptable to people >>>>> with YANG expertise? I think my preference would be to use this approach, >>>>> since it would provide additional consistency between the TR-181 and YANG >>>>> models. >>>> >>>> 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. Consistency across data models is a value, in >>>> particular for systems that may have to support multiple. While the >>>> conversion of different notations no hard, its one more thing to >>>> potentially get wrong. >>>> >>>> If you were starting with a blank sheet of paper, then the YANG idiom >>>> would likely be to use a union of a 16-bit integer and a special >>>> (string) value, which might even be of type empty. >>> >>> I hear two suggestions on what the “other” construct should be in the union >>> statement. Use ‘empty’ as you suggest, or use ‘boolean’. Are there any >>> pros/cons for either of the approaches? >> >> 'boolean' doesn't seem right, since that would mean that you could see >> the values 'true' | 'false' | <uint16>. >> >> If you want a union I suggest a union with one enum, perhaps: >> >> type union { >> type enumeration { >> enum null; >> } >> type uint16; >> } >> >> But Jürgens point about using a solution that other data models use >> makes sense. > > That would mean something like this: > > type union { > type empty; > type uint16; > } > > Right?
RFC 7950 says that the empty type cannot have a default value. The model had the value 0, which represented NULL as the default value for some of the attributes. With the suggested change, is there a way in the union for the empty type to be the default? If not, I will have to use Martin’s suggestion above of using a null enumeration. Thanks. > >> >> Yet another alternative could be to not instantiate this leaf when the >> value in the information model is null. > > I have never been very clear on what happens when the leaf goes from a > defined value to null. In other words, how do you “un-instantiate” a leaf? Do > you delete it? > > Cheers. > >> >> >> >> /martin >> >> >> >> >> >>> >>>> >>>> One of the reasons to have no common approach to these kind of >>>> questions is to provide the flexibility needed to do the right thing >>>> in different contexts. Of course, you may want to stay consistent in a >>>> data model or a collection of related data model. >>>> >>>> I skimmed RFC 8407 and it seems we do not have text discussion this >>>> specific situation. Perhaps we should have text, perhaps I have >>>> overlooked it. ;-) I think there are different patterns to choose from >>>> to handle this situation with their various pros and cons. >>>> >>>> /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/ >>>> <https://www.jacobs-university.de/>> >>> >>> Mahesh Jethanandani >>> mjethanand...@gmail.com <mailto:mjethanand...@gmail.com> > Mahesh Jethanandani > mjethanand...@gmail.com <mailto:mjethanand...@gmail.com> Mahesh Jethanandani mjethanand...@gmail.com
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
