NETCONF: XML operations over SSH, on YANG models
Every mechanism has a step-by-step animation, the configuration explained line by line and the exam notes. Where a parameter changes the outcome, you get a simulator in which you change it yourself.
TL;DR
NETCONF (RFC 6241) sends management operations as XML RPCs over SSH, on port 830, on data described by YANG models. The session starts with a hello exchange that announces the capabilities: which version, which datastores (running, candidate, startup) and which YANG modules the server has. get-config and get read with subtree or XPath filters; edit-config writes with merge, replace, create, delete or remove and returns ok or a structured rpc-error. On servers with candidate, the flow is lock → edit-config → validate → commit → unlock, and commit confirmed reverts by itself if you don't confirm in time. The same session can receive notifications and YANG-Push telemetry. NACM decides who can do what, and RESTCONF and gNMI use the same models with another transport.
How to read the notes: red = critical for the exam, green = theory, blue = numbers, yellow = pitfalls, cyan = differences between platforms and standards. In the animations, the configuration lines used in the current step are highlighted automatically; the ← → arrows change the step when the animation is selected.
The analogy, in short
Think of a bank's secure counter: you show your ID at the door, the window shows which services and which forms the branch accepts, and every request is filled in on a standard form that the clerk checks before applying it. Some branches work on a draft and apply everything when you sign; the provisional signature cancels itself if you don't come back to confirm.
The model holds up to §12. From §13 on (RESTCONF, gNMI, layer-by-layer troubleshooting), it breaks; see the full analogy and its limits in §16.