Hi Martin,
> On Sep 14, 2021, at 11:17 AM, Martin Björklund <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> 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?
>
> 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/>
>>
>> Mahesh Jethanandani
>> mjethanand...@gmail.com
Mahesh Jethanandani
mjethanand...@gmail.com
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
