An engineer loads the Cisco-IOS-XE-native module in YANG Suite and exports JSON for a RESTCONF edit that sets a loopback interface description. The model stores interfaces as a list keyed by name, and the payload must round-trip through a RESTCONF server without ambiguity about which entry is being edited. Which JSON instance structure matches the YANG model for this interface edit?
Select an answer to reveal the explanation.
Short Explanation
YANG Suite builds the payload straight from the module tree, so the list key has to survive the trip into JSON. RFC 7951 requires every list element to carry its key leaf, which is how a RESTCONF server picks the right row. Miss it and you've lost the interface you meant.
Full Explanation
YANG models describe a hierarchy of containers, lists and leaves, and RESTCONF serialises that hierarchy into JSON exactly as the tree is shaped. Because interfaces form a list keyed by the name leaf, RFC 7951 requires every JSON list element to include its key leaves, and that key is what lets the server identify which entry the edit targets. A payload that hangs the description directly under the module name describes a leaf at a level where the model defines none, so the server rejects the request as unknown data. Omitting the key from the list element leaves the entry unidentifiable, and the instance no longer matches the model even if a lenient server accepts it. Writing the description as an attribute confuses XML syntax with model data, because RFC 7951 encodes every YANG leaf as a JSON member and JSON has no attributes. Exam caveat: YANG Suite can emit XML or JSON, so switch the output format before copying anything. A practical check is to send the payload with RESTCONF and confirm a success status, then GET the resource back to see the description applied.