NETCONF and RESTCONF
NETCONF and RESTCONF are the model-driven, standardized alternatives to screen-scraping CLI. Know NETCONF as a layered protocol over SSH (port 830): a transport layer, an RPC/messaging layer (<rpc>, <rpc-reply>, <ok>, <rpc-error>), and operations. Core operations: <get>, <get-config>, <edit-config>, <copy-config>, <delete-config>, <lock>/<unlock>, <close-session>, <kill-session>, and <commit> where candidate datastores exist. Understand datastores: running, candidate, startup, and (Junos) ephemeral; and edit-config attributes (merge, replace, create, delete, remove) plus the default-operation setting.
Know capabilities exchanged in the <hello> exchange (base 1.0/1.1, candidate, confirmed-commit, rollback-on-error, validate, xpath) - a common trap is attempting an operation the session did not advertise. Understand confirmed commit with a timeout for safe changes and automatic rollback.
RESTCONF exposes the same datastore/model over HTTPS using HTTP methods and media types (application/yang-data+json or +xml). It typically operates on the running/candidate datastore via URI paths and often uses the ?content=config|all query parameter to select config vs. state data. Traps: assuming RESTCONF supports every NETCONF operation (it does not, e.g., no <lock> in the same form); forgetting the Content-Type/Accept headers; and confusing NETCONF over SSH with SSH CLI.
Rule of thumb: lock → edit-config (candidate) → validate → commit (confirmed, with timeout) → verify → unlock. This sequence is the safe-change pattern exam questions reward.