A Python script using the requests library sends a RESTCONF PATCH to update an interface description on an IOS XE router and receives HTTP 400 with a JSON body. The endpoint path and YANG leaf names look right at first glance. Which RFC 8040 error fields identify the standardized failure category and the affected node?
Select an answer to reveal the explanation.
Short Explanation
Good call — the status code only sorts the failure into a category, while the error body gives more detail. It's like a marked-up worksheet from the router: the error details can show which leaf to fix instead of making you rewrite the whole request.
Full Explanation
The RFC 8040 error body is the most direct diagnostic source for a RESTCONF failure. The error-tag gives a standardized category for the problem, while error-path, when supplied, identifies the node associated with it; together they can distinguish, for example, an invalid value from a failure tied to a particular interface leaf. Reading the error-message and error-info is a useful complementary practice, but those fields may be absent, implementation-specific, or less precise, so relying on them alone can miss the standardized failure category and affected node. Error-type and error-app-tag provide useful context about the error's layer and any application-specific label, but they do not replace error-tag or error-path for identifying what failed and where. The status and message can also guide investigation, and schema validation is sensible, but they do not extract the structured diagnostic fields from the response; a 400 does not by itself establish which payload detail is wrong. Exam caveat: error-path is optional, so its absence does not make the response invalid; use the fields that are actually present and interpret them alongside the request and YANG model. Practical check: preserve the response body and inspect its errors array, including error-tag, error-path, error-message, and error-info, before modifying or resending the PATCH.