Re: [babel] [netmod] NULL value for uint16

[Jürgen Schönwälder <[e-mail]>]

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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>