How does a NETCONF session work: what are capabilities, datastores and RPC messages?

At session start, client and device exchange capabilities, which tell the client what the device can do. Configuration and state live in datastores, which are read and changed with NETCONF operations sent as XML remote procedure call (RPC) messages.

* Open the session, learn the capabilities, edit the candidate, validate and commit it to running. *

1. Connect. The client opens the session, normally over SSH.
2. Exchange capabilities. Both sides send a <hello> listing their capabilities: which NETCONF features and which YANG models the device supports. The client now knows what it can ask for.
3. Work on datastores. A device keeps its configuration in datastores, for example running (active now), and on many devices candidate (a draft to commit) and startup (loaded at boot).
4. Send RPCs. Every request is an XML <rpc> message, such as <get-config> on the running datastore, and the device answers with an <rpc-reply>.

Datastores are what make transactions possible: you edit the candidate, validate it, and only then commit it to running.

Go deeper:

• RFC 8342 — Network Management Datastore Architecture — running, candidate, startup and operational datastores defined.