A long while ago Marcel Wiget sent me an interesting email along the lines “I think you should do a Software Gone Wild podcast with Phil Shafer, the granddaddy of NETCONF”

Not surprisingly, as we started discovering the history behind NETCONF we quickly figured out that all the API and automation hype being touted these days is nothing new – some engineers have been doing that stuff for almost 20 years.

Phil Shafer designed Junos to have CLI on top of internal API in 1997, and his main ideas were:

• Everything available in operational and configuration mode is accessible to external applications via API
• API should be release-independent and survive software upgrades

The Junos API was always there, and after it was made public in 2000, Phil tried to push this same idea through IETF. 15 years later we’re finally making some multi-vendor progress.

However, some Juniper customers quickly realized how useful that approach is: they were modifying device configurations with automation tools decades ago and there were environments where changing device configuration via CLI was a fireable offense in early 2000.

We spent the rest of the podcast discussing NETCONF history and evolution details, including:

• Why they decided to use XML instead of JSON
• Why is JSON easier to parse than XML?
• Why it’s easier to troubleshoot XML documents than JSON data structures
• Why it’s easier to extend XML than JSON
• Why is NETCONF so watered-down compared to what Junos does
• Why should you use NETCONF or gRPC to read operational data instead of SNMP
• Why NETCONF won’t replace SNMP
• What streaming telemetry is, why it makes sense and why it usually uses UDP
• Why NETCONF notifications could be more dynamic than SNMP traps
• Why RESTCONF appeals to programmers with only two hammers in their toolbox
• What the difference between YANG (data model description) and XML/JSON (data model representation) is.

You’ll find them all in Episode 85 of Software Gone Wild.