A team standardises on the OpenConfig interfaces model and builds its RESTCONF payload in YANG Suite's Data worksheet. You need the description change for interface GigabitEthernet0/0/1 to land in the running config. Which JSON structure should YANG Suite produce for that RESTCONF request?
Select an answer to reveal the explanation.
Short Explanation
OpenConfig splits every interface into a writable config block and a read-only state block, so you put description in config. The entry also needs its interface name, since that key's what tells the server which port to touch. The name works like a house number on an envelope: the leaf says what to change, the key says where it goes.
Full Explanation
OpenConfig deliberately separates what an operator sets from what a device reports: each interface list entry carries its key leaf, a config container for writable leaves, and a state container marked read-only in the YANG module. Because description sits under the interface config container, a RESTCONF write to the config datastore resolves the leaf, matches the name key, and applies the change to the right interface. Dropping the leaf straight into the list entry follows the IETF interfaces layout instead, and that model has no config container, so the path simply does not exist in the module you standardised on. Writing into the state block fails because state leaves are config false and the server rejects them, however well the rest of the payload is formed. Identifying the entry by ifIndex fails because the list key is name, and an entry without its key cannot be matched to an interface. Exam caveat: widely used models mix these conventions, so correct nesting always follows the module you pick rather than a habit carried over from another model. Practical check: paste your draft into YANG Suite's data worksheet and confirm it validates, or GET the interface with content=config and mirror that shape.