Network automation means changing network devices through code and APIs instead of typing commands on each one. Standards help: YANG describes what a device can be configured with, NETCONF applies changes over remote procedure calls, and RESTCONF offers the same data over HTTP. The payoff is repeatable changes that you can test and undo.
What problem does it solve?
Manual changes drift. Two engineers configure the same kind of switch two ways, an emergency fix never gets written down, and nobody can say what the real configuration is. Automation makes the intended state a file, so the question becomes whether a device matches the file.
It also shrinks the blast radius of typing mistakes. A change reviewed in a pull request and tested against a lab is less likely to take out a data centre than a late night paste into a terminal.
What are YANG, NETCONF and RESTCONF?
RFC 7950 defines YANG 1.1 as a data modeling language for configuration data, state data, remote procedure calls and notifications. A YANG model is a typed schema for a device: an interface has a name, an enabled flag and an address list.
RFC 6241 defines NETCONF, which provides mechanisms to install, manipulate and delete the configuration of network devices. It uses XML for data and messages, and its operations are remote procedure calls.
RFC 8040 defines RESTCONF as an HTTP based protocol that gives a programmatic interface to data defined in YANG, using the datastore concepts from NETCONF. If your tools already speak HTTP and JSON, RESTCONF is the easier fit.
Which NETCONF features matter for safety?
The base spec includes safeguards that scripts over a command line lack. A candidate configuration datastore holds changes that can be manipulated without affecting the device's current configuration, then committed to the running one. Not all devices support it, so check the device's declared capabilities.
A confirmed commit applies a change and reverts it unless you confirm in time, which protects against locking yourself out. Rollback-on-error stops and undoes an edit if any part fails. Locks stop two sessions from editing at once.
Do you need these protocols to automate?
No. Many teams automate with vendor APIs, SSH command templates or configuration management tools. The standards matter when you manage several vendors and want one data model instead of one per vendor. Vendor support varies, and some devices expose only part of their configuration through YANG.
A constructed example
A company has 40 branch routers and needs to add a new DNS server address. The old process took a week of tickets.
The new one stores each branch's desired settings in a repository. A pipeline renders the change, pushes it to a lab device, runs a check that name resolution still works, then applies it to two pilot branches through a confirmed commit with a five minute window. When the check passes, it rolls out in batches of ten. One router fails because it runs an older software release and cannot take the change. The tool reports it and moves on rather than half applying the edit.
What are the security risks?
Automation concentrates power. The account that can push configuration to every router is a high value target. Give each pipeline its own credentials, restrict where it can connect from, and log every change with who approved it. NETCONF is usually carried over SSH, and RESTCONF over HTTPS, so key management and certificate checks apply as usual. Keep device credentials out of the repository.
Treat the automation code like production software: review it, scan its dependencies, and pin versions of the libraries it uses.
How to check or apply this
- Pick one repetitive change, such as a DNS server update or an NTP list.
- Write down the desired state in a version controlled file.
- Check which interfaces each device supports: NETCONF, RESTCONF or only a vendor API.
- Test against a lab device or emulator before any live change.
- Use candidate datastores or confirmed commits where they exist.
- Roll out in batches with an automated check after each one.
- Lock down the automation account and log every push.
Quick check
Is RESTCONF a replacement for NETCONF?
No. RESTCONF provides an HTTP interface to YANG defined data using NETCONF's datastore concepts. Many devices support both.
What stops a bad change from locking me out?
Where supported, a confirmed commit reverts the change automatically unless you confirm it within the window.
Sources
Last reviewed: 18 October 2026.
