A NETCONF edit to a Catalyst 9800 is rejected. The session is up, and the payload names a configuration node that the controller's YANG model does not contain. Why was it rejected?
Select an answer to reveal the explanation.
Short Explanation
The session is fine. You asked the controller to edit a knob its model does not have, so it refused the payload. NETCONF is happy to edit this controller when the XML matches the model.
Full Explanation
YANG defines the tree a device will accept. A NETCONF edit that names a node outside that tree is rejected even though the SSH session is up. The failure is the payload, not the transport. NETCONF can edit a Catalyst 9800. A rejection of one bad node is not a ban on every payload. YANG is the model, not an SSH port. Putting a model name in the payload does not close the session by itself. The session stayed up. NETCONF operations are XML. A requirement for JSON would describe a different protocol. An XML edit that follows the model is valid. The controller compared the payload with the model it implements and refused the unknown node. A working SSH session only proves the transport is up. Exam caveat: two models can describe similar wireless data and still use different node names. A payload written for another platform fails here even when the idea is right. Operational check: compare the rejected node with the model the controller advertises and resend the edit against a node that exists.