YANG is a data modeling language specifically designed to model the configuration and state data of network devices that are managed using the NETCONF protocol. The name itself stands for Yet Another Next Generation, and it was introduced through RFC 6020 in 2010 before being significantly updated in RFC 7950. YANG provides a structured, hierarchical way to describe network data in a format that both humans and machines can process consistently. It defines data types, groupings, constraints, and relationships between different pieces of network configuration, making it a foundational technology for modern network automation and programmability.
The importance of YANG in today’s networking environment cannot be separated from the broader movement toward model-driven network management. Traditional network management relied heavily on CLI commands and SNMP, both of which suffered from inconsistency across vendors and limited machine-readability. YANG addresses these problems by providing a formal language for describing exactly what data a device exposes, how that data is structured, and what constraints apply to valid values. When network engineers and automation developers work with YANG models, they gain a precise, vendor-independent vocabulary for interacting with network devices in a programmatic and repeatable way.
Origins of IETF Models
The Internet Engineering Task Force, universally referred to as IETF, has been the primary standards body responsible for developing YANG models that aim for broad interoperability across the entire networking industry. IETF YANG models are developed through a rigorous consensus-driven process involving contributions from network vendors, operators, and academic researchers from around the world. Each model goes through multiple drafts, extensive review periods, and formal publication as an RFC before it is considered a finalized standard. This process is thorough and deliberate, which produces models that are carefully considered but sometimes slow to arrive.
IETF models are designed around the principle of vendor neutrality — the idea that a single model should work correctly regardless of which vendor’s device is being managed. Well-known IETF YANG models include RFC 8343 for interface management, RFC 8344 for IP address management, RFC 8349 for routing management, and RFC 7317 for system management. These models define a common baseline of network functionality that every compliant device should support. The trade-off is that IETF models often represent the lowest common denominator of functionality — they cover what all vendors can agree upon, which means vendor-specific features and advanced capabilities frequently fall outside their scope.
OpenConfig Initiative Background
OpenConfig is a collaborative working group formed by major network operators including Google, Microsoft, AT&T, and other large-scale network consumers who were frustrated with the pace and scope of IETF standardization efforts. Rather than waiting for consensus-based standards bodies to produce models, OpenConfig took an operator-driven approach — defining YANG models based on what large-scale network operators actually need to manage their infrastructure effectively. The models are developed publicly on GitHub, updated frequently, and designed with operational practicality as the primary concern rather than theoretical completeness or committee consensus.
The philosophy behind OpenConfig differs meaningfully from IETF in several important ways. OpenConfig models are designed to be configuration-centric, meaning they prioritize the data that operators need to configure and monitor devices rather than covering every possible aspect of device behavior. They also emphasize a clear separation between configuration data and operational state data, implementing a consistent pattern where every managed object has both a config container holding intended configuration and a state container holding operational telemetry. This separation makes OpenConfig models particularly well-suited to streaming telemetry use cases, where network devices continuously publish operational state data to collection systems for real-time monitoring and analysis.
Cisco Native Model Philosophy
Cisco has developed its own extensive library of YANG models that expose the full depth of IOS XE, IOS XR, and NX-OS device capabilities in a way that neither IETF nor OpenConfig models can fully replicate. Cisco native models are generated directly from the internal data structures of Cisco operating systems, which means they reflect every configuration option, every operational state variable, and every platform-specific feature that the device supports. While this approach produces models of extraordinary breadth and detail, it also results in models that are inherently tied to Cisco’s implementation choices and operating system versions.
The practical implication of Cisco’s native model approach is that these models provide the most complete access to device functionality but at the cost of portability. A network automation script written against Cisco native YANG models will interact with Cisco devices with full fidelity, accessing features and configuration hierarchies that simply do not exist in IETF or OpenConfig equivalents. However, that same script cannot be applied to a Juniper, Arista, or Nokia device without substantial rewriting. Cisco native models are therefore most valuable in environments where Cisco devices are the standard platform and operator productivity is prioritized over multi-vendor portability.
Structural Differences Between Models
The structural organization of IETF, OpenConfig, and Cisco native YANG models reflects the different philosophies and priorities behind each approach. IETF models tend to use a relatively flat structure with carefully defined groupings that can be reused across multiple models. They follow the YANG module organization conventions established in the original RFC specifications and tend to be conservative in their use of augmentation and deviation mechanisms. The result is a clean, well-documented structure that is easy to read and reason about but sometimes requires multiple separate models to cover a complete feature area.
OpenConfig models use a consistent structural pattern throughout their entire library — every managed element follows the same config and state container convention, and models are organized into a coherent hierarchy that reflects how operators think about network topology and services rather than how vendors implement internal data structures. Cisco native models, by contrast, follow the internal hierarchy of IOS XE or IOS XR configuration, which means the model structure mirrors the CLI hierarchy that Cisco engineers are already familiar with. This makes Cisco native models intuitive for experienced Cisco operators but potentially confusing for those approaching them from a vendor-neutral automation background.
Namespace and Module Organization
YANG namespaces and module naming conventions differ significantly across IETF, OpenConfig, and Cisco native models, and these differences have practical consequences for tools and automation code that must work with multiple model families simultaneously. IETF models use namespaces rooted at the ietf.org domain and follow a naming convention that prefixes module names with “ietf-” followed by the functional area, such as ietf-interfaces, ietf-ip, or ietf-routing. These namespaces are globally unique and stable across all vendors who implement the same IETF standard.
OpenConfig modules use namespaces rooted at openconfig.net and prefix module names with “openconfig-” followed by the feature area, such as openconfig-interfaces, openconfig-bgp, or openconfig-platform. Cisco native modules use namespaces that reflect the specific operating system and feature area, with naming conventions like Cisco-IOS-XE-native for core IOS XE configuration or Cisco-IOS-XR-infra-intf-cfg for IOS XR interface configuration. When building automation tools that must consume multiple model families, the namespace differences require careful handling to avoid conflicts and ensure that XPath expressions and filter operations target the correct model hierarchy on each device.
NETCONF and RESTCONF Support
All three model families — IETF, OpenConfig, and Cisco native — can be accessed through either NETCONF or RESTCONF on supported devices, but the practical implementation details and level of support vary considerably. NETCONF, defined in RFC 6241, uses XML encoding and provides operations for getting configuration, editing configuration, and retrieving operational state. RESTCONF, defined in RFC 8040, provides a REST-based alternative that supports both XML and JSON encoding, making it more accessible for developers comfortable with web API patterns. Cisco devices running IOS XE 16.6 and later support both protocols simultaneously, allowing operators to choose the encoding and transport that best fits their tooling.
The relationship between model families and protocol support becomes important when performing operations like capability exchange during NETCONF session establishment. When a NETCONF client connects to a device and receives the server’s hello message, the capabilities list reveals which YANG modules are supported and at which revision. This capability negotiation allows automation tools to determine at runtime whether a device supports IETF, OpenConfig, Cisco native, or some combination of all three model families. Tools built on libraries like ncclient for Python or the Go YANG library can use this information to select the appropriate model for each device and operation, enabling more robust and adaptive automation code.
BGP Configuration Comparison
Examining how each model family handles BGP configuration reveals the practical trade-offs between them in concrete terms. The IETF BGP model, defined in a series of drafts that have evolved over several years, covers core BGP functionality including neighbor configuration, address family settings, route policy application, and operational state. It provides a solid foundation for basic BGP management but lacks the depth needed to configure advanced BGP features like complex route reflection topologies, fine-grained timer tuning, or vendor-specific optimization settings.
The OpenConfig BGP model is one of the most mature and widely adopted in the OpenConfig library, covering neighbor configuration, peer groups, address families, route policies, and a comprehensive set of operational state counters and telemetry paths. It is supported by Cisco, Juniper, Arista, and Nokia devices with varying degrees of completeness. The Cisco native BGP model for IOS XE or IOS XR exposes every BGP configuration option available in the operating system, including features that have no equivalent in IETF or OpenConfig. For network operators who need to configure advanced Cisco BGP capabilities through automation, the native model is frequently the only option that provides access to the required configuration hierarchy.
Interface Management Across Models
Interface management is one of the most fundamental network management functions, and it serves as an excellent case study for understanding how the three model families approach the same problem differently. The IETF interfaces model defined in RFC 8343 covers basic interface configuration including interface type, description, MTU, and administrative status, along with RFC 8344 for IP address assignment. These two models together provide a minimal but functional foundation for interface management that any compliant device should support regardless of vendor.
The OpenConfig interfaces model extends this foundation considerably, adding support for subinterfaces, VLAN tagging, Ethernet-specific settings, and a rich set of operational state counters that make it particularly useful for telemetry-driven monitoring. The Cisco native interface model for IOS XE exposes the complete interface configuration hierarchy including platform-specific features, QoS policy application, detailed CEF settings, and interface-level features that are unique to Cisco platforms. Network engineers automating interface provisioning in multi-vendor environments typically use OpenConfig as the primary model and fall back to vendor-native models only for features that OpenConfig does not yet cover, a pragmatic hybrid approach that balances portability with completeness.
Telemetry and Streaming State
Model-driven telemetry has become one of the most compelling use cases for YANG models in modern network operations, and the three model families differ significantly in how well they support high-frequency operational state streaming. OpenConfig was designed from the beginning with telemetry as a first-class concern, and its consistent config and state container separation makes it straightforward to subscribe to specific operational state paths and receive continuous updates as values change. OpenConfig telemetry paths are stable across vendors and operating system versions, making them reliable targets for monitoring infrastructure built on tools like Telegraf, InfluxDB, and Grafana.
Cisco native models also support model-driven telemetry on IOS XE and IOS XR, and in many cases they expose more granular operational state data than OpenConfig equivalents. For deeply Cisco-centric operations teams, native model telemetry paths provide access to platform-specific counters and diagnostics that have no OpenConfig analog. IETF models are generally less mature for telemetry use cases, as they were designed primarily around configuration management rather than high-frequency state streaming. The practical recommendation for most organizations building telemetry infrastructure is to use OpenConfig paths wherever coverage is adequate and supplement with native model paths for platform-specific metrics that matter for operational visibility.
Automation Tool Compatibility
The choice of YANG model family has direct implications for which automation tools and frameworks can be used effectively. Ansible’s network automation modules, particularly those in the cisco.ios and cisco.iosxr collections, have historically relied on CLI-based interaction but increasingly support NETCONF with YANG filtering. The yang-explorer tool from Cisco and the pyang compiler from the IETF community both allow developers to browse, validate, and compile YANG models into usable code structures. NSO, Cisco’s Network Services Orchestrator, has native support for all three model families and can perform model translation between them for multi-vendor service provisioning.
Python-based automation using the ncclient library provides direct NETCONF access to any model family, and the netmiko library adds SSH-based fallback for devices that do not yet fully support YANG-based management. The pyangbind library generates Python bindings from YANG models, allowing developers to work with typed Python objects that correspond directly to model structures rather than constructing XML or JSON payloads manually. YANG development kits provided by Cisco for IOS XE and IOS XR include pre-generated bindings for native models, lowering the barrier to entry for automation developers who want to work with native model capabilities without manually compiling model files.
Deviation and Augmentation Patterns
One of the most important but often overlooked aspects of real-world YANG model deployment is the use of deviations and augmentations, which allow vendors to customize standard models to reflect the actual capabilities and limitations of their platforms. A deviation statement in YANG allows a device vendor to declare that a specific node from a standard model is not supported, has a different data type, or has different constraints than the standard specifies. Augmentation allows a vendor to add new nodes to a standard model without modifying the original, extending it with platform-specific capabilities while preserving compatibility with the base standard.
Cisco devices make extensive use of both deviations and augmentations when implementing IETF and OpenConfig models. A Cisco IOS XE device might implement the OpenConfig interfaces model but include deviations that indicate certain optional features are not supported on that platform, along with augmentations that add Cisco-specific interface parameters not present in the base OpenConfig model. Automation developers must account for these deviations and augmentations when writing code that targets standard models on Cisco devices — assumptions about full compliance with the base model specification can lead to runtime errors when the code encounters a deviation that restricts or alters expected behavior.
Practical Model Selection Guide
Selecting the appropriate YANG model family for a given automation task requires balancing several competing factors including the vendor mix in the environment, the features required, the tools available, and the long-term portability goals of the automation project. In genuinely multi-vendor environments where Cisco, Juniper, Arista, and Nokia devices must all be managed through the same automation codebase, OpenConfig is typically the best starting point because it offers the broadest vendor support and the most consistent cross-platform behavior. IETF models serve as a reliable baseline for the most fundamental operations — interface status, IP addressing, basic routing — where broad compliance is well established.
In environments that are predominantly or exclusively Cisco, native models offer the most complete access to device capabilities and the most direct mapping to the CLI-based mental models that Cisco-experienced engineers already possess. A pragmatic hybrid strategy — using OpenConfig for the majority of configuration and telemetry operations while selectively using Cisco native models for features that fall outside OpenConfig’s coverage — is the approach adopted by most mature network automation programs. Documenting which model family is used for each feature area and maintaining that documentation alongside automation code ensures that teams can maintain and extend their automation work as model coverage evolves over time.
Conclusion
The comparison between IETF, OpenConfig, and Cisco native YANG models ultimately reflects three different but equally legitimate approaches to the challenge of network device programmability, each optimized for a different set of priorities and use cases. IETF models represent the gold standard of vendor-neutral standardization, produced through a careful consensus process that ensures broad industry agreement but sometimes sacrifices speed and feature depth in favor of universality. They are the right choice when long-term stability, cross-vendor compatibility, and formal standards compliance are the primary requirements, and they provide the foundational building blocks upon which both OpenConfig and many vendor-native models are constructed.
OpenConfig occupies a practical middle ground that has proven enormously influential in the industry precisely because it was built by the people who operate large-scale networks rather than by committee. Its operator-driven design philosophy, consistent structural conventions, and strong telemetry support have made it the de facto standard for multi-vendor network automation in service provider and hyperscaler environments. The rate at which OpenConfig models are being adopted by vendors and implemented in production networks continues to accelerate, and the gap between OpenConfig coverage and vendor-native completeness continues to narrow as the working group expands its model library into new feature areas.
Cisco native models remain indispensable for organizations running Cisco infrastructure at scale who need complete programmatic access to every capability their devices support. The breadth and detail of native model coverage is unmatched by any standard model family, and for teams already deeply invested in Cisco platforms, the productivity gains from working with native models often outweigh the portability trade-offs. The existence of model translation capabilities in tools like NSO further reduces the cost of using native models by allowing them to coexist with standard model workflows rather than forcing an exclusive choice between approaches.
Looking at the broader trajectory of the industry, the boundaries between these three model families are gradually becoming less rigid. Vendors are increasingly implementing OpenConfig models with higher fidelity, IETF standardization is accelerating in certain functional areas, and tooling support for seamless multi-model automation continues to improve. Network engineers and automation developers who invest time in genuinely understanding all three model families — their origins, their structures, their strengths, and their limitations — will be far better positioned to make informed architecture decisions, write more robust automation code, and adapt effectively as the model-driven networking landscape continues to mature. The future of network management is unquestionably model-driven, and YANG in all its forms is the language through which that future will be built.
