[NETCONF-691] A question about empty container not showing Created: 26/May/20  Updated: 03/Aug/20  Resolved: 03/Aug/20

Status: Resolved
Project: netconf
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Medium
Reporter: wang senxiao Assignee: Jamo Luhrsen
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

When I use restconf in Sodium-SR1, I find one thing, if I create one container without set value to any child in it, It does not show up.

For example, there is following yang structure:

 

container A {

  leaf B {
    type string;
  }

  container C {
    // .....
  }
  container D {
    // .....
  }
}

When I new A, set value to B, and just new C, D. And then query root node A, the results are as follows:

"A": {
  "B": "123456"
}

 

C and D are not shown. So I just want to kown, can we display these empty containers that have been created?



 Comments   
Comment by wang senxiao [ 26/May/20 ]

jluhrsen

Comment by Jamo Luhrsen [ 27/May/20 ]

I am not sure the root cause of this, but wondering if it could be related to this work in
NETCONF-660? mjethanandani, do you think it's related?

Comment by Mahesh Jethanandani [ 27/May/20 ]

No. I do not think the two issues are related.

RFC 7950 in Section 7.5.1 says the following for non-presence containers. Container C & D are non-presence containers, so they will not be printed. If the desire is to print them regardless, then they should be marked with the 'presence' keyword.

"In particular, the presence of the
container node with no child nodes is semantically equivalent to the
absence of the container node."

Comment by Jamo Luhrsen [ 27/May/20 ]

Thanks mjethanandani

wsx25289, feel free to reply and/or close this ticket if this is makes sense to you.

Comment by Robert Varga [ 03/Aug/20 ]

As explained, an empty non-presence container has no semantic meaning and hence we automatically remove them.

Generated at Wed Feb 07 20:15:39 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.