show ... | display json --- for type empty in yang

[ben_piret]

Hello the community,

We are using types empty in our Yang model and we are a bit surprised by how outcome of those empty types are presented when we display our service in JSON (with the | display json)

For instance, on one example, it gives :

nsoadmin@ncs% show vpnconfig DUMMYVRF | display json
{
"data": {
"vpnconfig:vpnconfig": [
{
"name": "DUMMYVRF",
"pedevice": "R10B1930WIN0 R10B4530WIN0 R10B6041WIN0",
"route-distinguisher": 722,
"hubvpns": {"": "management","": "voice","": "publiwin","": "wuh",
"loopback-number": "119",
"clitype": "old",
"importRTin": "200",
"exportmap": "export-public-loop-only-management",
"redistributestatic": "false",
"redistributeconnected": true
}
}
]
}
}

The outcome is not very usable for the empty types : in my example it is :

"": "management","": "voice","": "publiwin","": "wuh",

The emtpy types all appear with the key = "" .

Do you thinks that it is normal ?

Kind regards.

Benoit

[vleijon]

It looks weird, but, what is the yang model for hubvpns?

[ben_piret]

snipset :

    grouping vpnconfig {

            leaf route-distinguisher {

                description "This is the route distinguisher long explanation";

                tailf:info "route distinguisher";

                type uint32;

                mandatory true;

            }

            leaf global-customer-as {

                tailf:info "Global Customer AS for all sites";

                type uint32;

            }

            container hubvpns {

                leaf own_rd {

                    tailf:info "Is this VPN im-exporting its own RD ?";

                    type empty;

                }

                leaf management {

                    tailf:info "export map export-public-loop-only-management / route-target import 9208:200";

                    type empty;

                }

                leaf internet {

                    tailf:info "Is this VPN spoke from Internet ?";

                    type empty;

                }

                leaf voice {

                    tailf:info "Is this VPN spoke from Voice (SBC) ?";

                    type empty;

                }

                leaf publiwin {

                    tailf:info "Is this VPN spoke from PUBLIWIN ?";

                    type empty;

                }

                leaf wuh {

                    tailf:info "Is this VPN spoke from WUH ?";

                    type empty;

                }

                leaf csoc {

                    tailf:info "Is this VPN spoke from CSOC-HUB ?";

                    type empty;

                }           

                leaf loopback-number {

                    tailf:info "VPN Loopback Number in R10 - example: 110 or 486/172.23.177.138";

                    type string {

...

[vleijon]

It looks reversed to me, and own_id is missing for some reason. That doesn't look good to me, I'd expect own_id:'', management:'' or something like that.

[ben_piret]

ok, I also thought that it was reversed in the json outcome - it should be : "management" : "" etc.

I will raise a SR with the TAC

Benoit

[ben_piret]

Hi,

Feedback from the case :

The reported issue has been fixed:

  - cli: When showing an empty leaf in JSON format, with the pipe command

    "display json", the output had the wrong format. This has been fixed.

The change was/will be included in below and later versions:

  * nso-5.2.6

  * nso-5.3.4

  * nso-5.4.3 (09-Mar-2021)

  * nso-5.5.1 (09-Feb-2021)

  * nso-5.6

[snovello]

Hello ,
‘display json’ is sometimes used to create examples of the json that is used from the REST API of NSO. To make it easier to copy paste that output directly I think it would be useful for NSO to output using the encoding defined in RFC 7951 – ‘JSON Encoding of Data Modeled with Yang’ which is the encoding used in RESTCONF. In that encoding an empty leaf foo, looks like “foo”:[null], so an array containing null.

[ben_piret]

Hello,

You are right - it's B/W in the RFC §6.9.

I will highlight this in the SR case so that it can be corrected in compliance with the RFC

Benoit

[ben_piret]

For those of you who have "deep access" to TAC SR, it's :SR # 690615369

Benoit

[ben_piret · Accepted solution]

Hi,

I tested it this morning in NSO 5.5.1, and the outcome is now good (see the "management": [null],)

Benoit

#### 

nsoadmin@ncs% show vpnconfig DUMMYVRF | display json
{
"data": {
"vpnconfig:vpnconfig": [
{
"name": "DUMMYVRF",
"route-distinguisher": 722,
"hubvpns": {
"management": [null],
"loopback-number": "119",
"clitype": "old",
"importRTin": "200",
"exportmap": "export-public-loop-only-management",
"redistributestatic": "false",
"redistributeconnected": true
}
}
]
}
}