When a NETCONF server rejects an <edit-config> with an <rpc-error>, which fields should automation read to decide what failed and where?

## Where errors appear Every NETCONF request is an `<rpc>` element with a `message-id` attribute, and every answer is an `<rpc-reply>` echoing it. A successful operation that returns no data answers `<ok/>`; a retrieval answers `<data>`; a failure answers one or more `<rpc-error>` elements. RFC 6241 Section 4.3 makes three promises worth memorising: - A server **MUST** return an `<rpc-error>` if any error condition occurs. - It **MAY** return several, but is **not required** to detect or report more than one, and need not check conditions in any particular order. - It **MUST NOT** return data-model-specific error detail the client lacks the access rights to see. Replies come back in request order: RFC 6241 requires a server to process `<rpc>` requests serially and to answer in the order they were received, even when a client pipelines several. ## The fields | Field | Content | Use in automation | |---|---|---| | `error-type` | `transport`, `rpc`, `protocol` or `application` | Which conceptual layer failed: secure transport, messages, operations or content. | | `error-tag` | A string from Appendix A | **The primary branch key.** | | `error-severity` | `error` or `warning` | Treat as `error`; RFC 6241 defines no tag that uses `warning`. | | `error-app-tag` | Data-model- or implementation-specific string | A finer key when present; the data-model value wins if both exist. | | `error-path` | Absolute XPath to the node involved | Which interface, which leaf, when one can be associated. | | `error-message` | Human-readable text, with `xml:lang` | Log it; never parse it. | | `error-info` | Protocol- or model-specific elements | Mandated detail, such as `bad-element`. | Optional means optional: `error-app-tag`, `error-path`, `error-message` and `error-info` are each absent when nothing appropriate applies. ## The error-tags an edit job meets Appendix A is normative and lists each tag with the error-types it may carry and any mandatory `error-info`. The ones an `<edit-config>` most often produces: 1. **`data-exists`**: a `create` operation hit data that already exists. 2. **`data-missing`**: a `delete` targeted absent data, or `default-operation none` met a level that does not exist in the target. 3. **`invalid-value`**: a parameter value is unacceptable; also returned when `<copy-config>` names the same source and target. 4. **`access-denied`**: authorization failed for the operation or the data. 5. **`in-use`** and **`lock-denied`**: a resource or lock is held by someone else; for `lock-denied`, `error-info` carries the holder's `session-id`. 6. **`operation-not-supported`**: the device does not implement what was asked. 7. **`malformed-message`**: the message could not be parsed; new in `:base:1.1`, and RFC 6241 says it must not be sent to old clients. 8. **`rollback-failed`**: a requested rollback, through `rollback-on-error` or `<discard-changes>`, did not complete. The older `partial-operation` tag, which listed succeeded, failed and skipped elements, is obsolete in RFC 6241 and should not be sent, so a client cannot rely on it to learn what an edit managed before it failed. ## Reading a reply RFC 6241's own example shows two errors from one edit, each with `error-type` `application`, `error-tag` `invalid-value`, an `error-path` naming a different interface, and an `error-message` such as "MTU value 25000 is not within range 256..9192". A robust client: - matches on `error-tag`, then on `error-app-tag` if it knows the data model; - uses `error-path` to tie the failure to an object in its own inventory; - treats several `<rpc-error>` elements as a list, and also handles a reply that stops at the first; - records `error-message` verbatim for the operator. ## Why strings and not numbers NETCONF error-tags are enumerated strings, not numeric codes. RESTCONF (RFC 8040), which carries the same data models over HTTP, maps each error-tag onto an HTTP status code, for example `data-exists` and `data-missing` to 409, and still returns the error-tag in the body. A client that handles both protocols should key its logic on the error-tag, which is common to both, rather than on the transport's status. ## Common mistakes - Matching on `error-message` text, which varies by implementation and language. - Assuming one `<rpc-error>` means one problem in the request. - Treating a missing `error-path` as a server bug; it is legitimately absent when no node can be associated. - Ignoring `error-type`: an `rpc`-layer `malformed-message` means the message could not be parsed at all, so resending the same bytes fails the same way. - Discarding `error-info`: for several tags Appendix A makes its content mandatory, such as `bad-element` naming the element at fault, which is often more precise than any message text.