A YANG module named example-bgp-config defines container bgp with leaf router-id of type string, plus list neighbor keyed by leaf address of type string and carrying leaf remote-as of type uint32. The engineer is decoding a RESTCONF response as JSON. Which structure for the bgp member maps the container, list and leaf nodes correctly under RFC 7951?
Select an answer to reveal the explanation.
Short Explanation
Under RFC 7951, your bgp container is a JSON object: router-id is a string, and neighbor is an array of objects. Each neighbor object keeps its address key and remote-as sibling together, like a card holding all the details for one entry.
Full Explanation
The correct structure follows the YANG node kinds and their declared types: a container is represented by an object, the neighbor list by an array of objects, and each leaf by a scalar member of the appropriate object. The list entries include both address, the key leaf, and remote-as, the uint32 leaf. Encoding remote-as as a string is a plausible choice in some application-specific JSON formats, but it does not preserve the RFC 7951 representation of this uint32 value, which is a JSON number. Omitting address can be useful when intentionally returning a filtered projection, but it fails to represent the complete neighbor list entry described here and leaves out the required key. An object keyed by address is a common map or dictionary representation for indexed records, but RFC 7951 represents a YANG list as a JSON array; the key remains a leaf within each list-entry object rather than replacing the list structure. Exam caveat: RFC 7951 has special string encoding rules for certain integer types, notably int64 and uint64, so do not generalize from those to uint32. Practical check: validate a sample response against the module’s YANG schema and confirm that each neighbor array element contains its key and a numeric remote-as.