JSON empty leaf-list encoding issue

[VandanaAkhramka]

This is a bug that affects libyang1 (hit on 1.0.225-1.1). I have not tested whether the same bug affects v2 as well.

I have a YANG module with a leaf-list of type string:

module null_leaflist_json {
  prefix "null_leaflist_json";
  namespace "urn:test:null_leaflist_json";

  leaf-list test_array {type string;}
}

The correct way to represent an empty leaf-list is in JSON is

"test_array": []

I have made a fix for this in my fork of this repo and added a regression test. Please see the PR #1821 for the fix. Could you please review my fix and help me get it merged in?

[michalvasko]

We first need to agree on what you said and I don't, currently. It is not important what valid JSON is but rather what is valid YANG data JSON, specifically the leaf-list. So, I do not think that an empty array is valid, you just do not include the test_array in this case in the JSON at all. Also, the special array should be [[null]], I think. It is the encoding of a single instance of

leaf-list ll {
  type empty;
}

[Skepfyr]

@michalvasko Why don't you think that an empty array is valid, that RFC seems silent on topic?
From RFC 7951 Section 5.3 and RFC 7950 Section 7.7 I think:

• [null] is the representation of the single value of the empty type
• [[null]] is a list containing a single "empty" type
• [] is the representation of the empty list

That third point definitely isn't explicitly called out, but RFC 7951 doesn't state that a list can't be empty, and YANG definitely has the concept of an empty list:

7.7.5. The "min-elements" Statement

The "min-elements" statement, which is optional, takes as an argument
a non-negative integer that puts a constraint on valid list entries.
A valid leaf-list or list MUST have at least min-elements entries.

If no "min-elements" statement is present, it defaults to zero.

YANG also differentiates between the presence of an empty list and the absence of the list because of default values:

7.7.2. The leaf-list's Default Values

The default values of a leaf-list are the values that the server uses
if the leaf-list does not exist in the data tree.

[michalvasko]

YANG also differentiates between the presence of an empty list and the absence of the list because of default values:

No, I believe it is the same thing and default values are applied in both cases.

Having example YANG

container cont {
  leaf l {
    type string;
  }
  leaf-list ll {
    type string;
  }
}

you would write JSON data with "empty" ll leaf-list like this

"cont": {
  "l": "value"
}

and not like this

"cont": {
  "l": "value",
  "ll": []
}

If you can reference something saying otherwise, I would consider accepting it.

[Skepfyr]

Reading those RFCs a bit more closely I agree with you that not present vs [] are identical from a YANG point of view. However 7951 is silent on which one of those is preferred, and I definitely don't see it ruling out the [] representation. Why do you only want to support the not present representation? From an interop point of view it feels reasonable to support both, for example the yangson python library accepts both representations.

I had a quick look through the IETF netmod working group's email archive and couldn't see this issue mentioned at all; I could ask them as they're still active but in some ways their opinion doesn't matter if other implementations have interpreted the standard more broadly.

[michalvasko]

I think it makes perfect sense to ask on the mailing list so please do. I will modify libyang if it is agreed that this can be supported.

[michalvasko]

Fine, based on what was said in the mailing list it should be supported. But it hardly seems like a critical feature.

[Skepfyr]

Thanks very much! This is incredibly useful for our use-case, so we really appreciate the change.

[VandanaAkhramka]

Hi @michalvasko, could you please review my changes to libyang1 please? - #1821
Thanks,
Vandana