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