5.4Interpreting responses and models

In model-driven automation, what you exchange with a device is not human-oriented show output but a structured response (JSON/XML) and the model (YANG) that governs it. To judge whether automation "worked," you must read success/failure from the response shape, grasp what each part of the model represents, and read what a change diff actually changes. This section trains that reading skill as the interpretation of a given response, model, and diff, not memorization.

5.4.1Reading RESTCONF/NETCONF responses

• RESTCONF maps CRUD to HTTP methods over HTTP (GET = read / POST = create / PUT = replace / PATCH = partial update / DELETE = delete). Responses are an HTTP status plus a JSON/XML body: 200 OK/201 Created are success, 204 No Content is success with no body, 401 is unauthenticated, 404 is a missing path (data), and 409 is a conflict. Read success/failure from both status and body.
• NETCONF exchanges XML over SSH (usually port 830); success is <ok/> inside <rpc-reply> and failure is <rpc-error> (cause in <error-tag>). It separates datastores as candidate (for editing) -> commit -> running (live), finalized by <commit> after <edit-config>. Judge success/failure by whether the reply is <ok/> or <rpc-error>.
• Read JSON response keys with their namespace: e.g., "ietf-interfaces:interface": [{ "name": "GigabitEthernet2", "enabled": true }] reads as "in the interface list of the ietf-interfaces model, there is an enabled entry named GigabitEthernet2." Calmly map which model, which element, what value.

5.4.2Reading the YANG model hierarchy

• YANG is a language that describes the data model (structure definition) of device config/state. Its main constructs are a leaf holding one value, a leaf-list of same-kind leaves, a container grouping elements, and a list of repeated entries identified by a key (e.g., many interfaces). The actual XML/JSON data is an instance of this YANG hierarchy.
• The knack for reading a model is to see "single or multiple?" and "what is the key?": list interface { key "name"; leaf enabled { type boolean; } } means "interface can occur multiple times keyed by name, and each has one boolean enabled." This structure appears in a response JSON as [...] (an array = list) or true/false (a boolean leaf).

5.4.3Reading a unified diff

• A unified diff represents before/after change. The leading --- old / +++ new identifies which file's old/new, and the @@ -a,b +c,d @@ hunk header shows position ("old starts at line a for b lines, new at c for d lines"). The line prefixes are key: - = a removed line, + = an added line, (space) = context (unchanged).
• Read a diff for its net change: - ip address 10.0.0.1 255.255.255.0 next to + ip address 10.0.0.2 255.255.255.0 means "the IP is changed from .1 to .2." Only + is an addition, only - is a deletion. In Git code review or a playbook diff, read whether this change is as intended and whether a dangerous deletion is mixed in.

Suppose you are investigating a failed automation job. The job was supposed to enable an interface via RESTCONF, but downstream validation reports "the IF is still down." Looking first at the RESTCONF response, a PATCH /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet2 returned HTTP/1.1 204 No Content. Jumping to "the body is empty, so it failed" is a mistake—204 is "success with no body," and the update itself was accepted. So where is the cause? Checking the diff (unified diff) you sent, the intent was "set enabled to true," but the actual payload was: - "enabled": true and + "enabled": false. That is, the net change is "enabled -> disabled," a content error swapping true and false. The response (204) is a success, but the content you sent was wrong—so the IF stays down; that is the correct isolation. Here YANG knowledge pays off: in ietf-interfaces, list interface { key "name"; leaf enabled { type boolean; } }, so enabled is a boolean leaf and should carry true (a boolean), not "true" (a string) or 1. Were this NETCONF, you would read success/failure not from an HTTP status like 204 but from <ok/> or <rpc-error> in the response XML, and confirm whether <commit> finalized candidate into running after <edit-config>. Being able to read this chain separately—communication success/failure from the response shape (204 = success), the content error from the diff (true -> false), and the value type from YANG (boolean leaf)—is the heart of model-driven troubleshooting.

5.4.4Section summary

• RESTCONF maps HTTP methods to CRUD; read success from status plus body (201 created / 204 success no body / 401 / 404). NETCONF uses <ok/> success / <rpc-error> failure, candidate -> commit -> running
• YANG defines the structure/type of container/list(key)/leaf/leaf-list, and the response JSON/XML is its instance; a boolean leaf takes a boolean
• A unified diff reads position from the @@ hunk and net change from - removed / + added / space context. Isolate response success/failure, diff content, and model type separately