Yet Another Next Generation (YANG, /jæŋ/) is a data modeling language for the definition of data sent over network management protocols such as the NETCONF and RESTCONF. Developed and maintained by the NETMOD working group in the Internet Engineering Task Force (IETF), YANG was initially published as RFC 6020 in October 2010, with a significant update to version 1.1 in August 2016 (RFC 7950).
YANG enables comprehensive network automation by providing a standardized way to model the configuration and state data of network elements. The language can be used to define the format of event notifications emitted by network devices and allows data modelers to define the signature of RPCs that can be invoked on network elements via the NETCONF protocol. Being protocol-independent, YANG models can be converted into various encoding formats, including XML, JSON, and CBOR, depending on the network configuration protocol's support.
YANG is a modular language and represents data structures in a hierarchical tree format. It includes numerous built-in data types, with the capability for users to derive additional application-specific types. More complex reusable data structures can be represented as "groupings," which promote model reusability and consistency. YANG data models can use XPath expressions to define constraints on the elements of a YANG data model, enabling validation of configuration data before it is committed to devices.
YANG has become the de facto standard for modeling network device configurations across the telecommunications industry and is widely supported by major network equipment manufacturers. It plays a crucial role in software-defined networking (SDN) and network function virtualization (NFV) environments by providing a consistent interface for programmatic network management.
Many network management protocols have associated data modeling languages. The first widely deployed Internet standard for network management was the Simple Network Management Protocol (SNMP). The data modeling language associated with SNMP was called the Structure of Management Information (SMI). The SMI language itself was based on the 1988 version of the Abstract Syntax Notation One (ASN.1). The current version of the SMI language, SMIv2 defined in RFC 2578, 2579 and 2580, has developed into an extended subset of ASN.1.
In the late 1990s, a project was started to create a replacement for SMIv2, which was called SMIng. One motivation was to decouple SMIng from the management protocol SNMP and to give SMIng a syntactic structure that is both easy to parse for computer programs and easy to learn for people familiar with programming languages that use a C-like notation. While the SMIng project did not succeed in the IETF, the SMIng specifications were published as experimental documents in May 2004 (RFC 3780, 3781).
Soon after the development of the NETCONF protocol in the IETF, it became clear that a data modeling language was needed to define data models manipulated by the NETCONF protocol. A design team created a proposal that became the basis of the YANG language. The syntactic structure and the base type system was essentially borrowed from SMIng. However, based on the lessons learned from the SMIng project, no attempts were made to make the YANG protocol neutral. Instead, YANG ties into concepts of the NETCONF protocol, such as the assumption that data model instances can be serialized into XML. Standardization of YANG started with the formation of the NETMOD working group in April 2008. The YANG 1.0 specification was published as RFC 6020 in October 2010. Recently, the NETMOD working group has been working on YANG 1.1, which has been published in August 2016 in RFC 7950.
The following YANG module example-sports shows a data model for team sports. The module declares a namespace and a prefix and imports the type library module ietf-yang-types before defining the type season. It then defines a container sports that includes a list of persons and a list of teams. A team has a list of players that reference persons via the leafref type and its path restriction.
module example-sports {
namespace "http://example.com/example-sports";
prefix sports;
import ietf-yang-types { prefix yang; }
typedef season {
type string;
description
"The name of a sports season, including the type and the year, e.g.,
'Champions League 2014/2015'.";
}
container sports {
config true;
list person {
key "name";
leaf name { type string; }
leaf birthday { type yang:date-and-time; mandatory true; }
}
list team {
key "name";
leaf name { type string; }
list player {
key "name season";
unique number;
leaf name { type leafref { path "/sports/person/name"; } }
leaf season { type season; }
leaf number { type uint16; mandatory true; }
leaf scores { type uint16; default 0; }
}
}
}
}
The code block below shows the JSON representation of an instantiation of the example-sports data model.
{
"example-sports:sports": {
"person": [
{
"name": "Lionel Andrés Messi",
"birthday": "1987-06-24T00:00:00-00:00"
},
{
"name": "Cristiano Ronaldo",
"birthday": "1985-02-05T00:00:00-00:00"
}
],
"team": [
{
"name": "FC Barcelona",
"player": [
{
"name": "Lionel Andrés Messi",
"season": "Champions League 2014/2015",
"number": 10,
"scores": 43
}
]
},
{
"name": "Real Madrid",
"player": [
{
"name": "Cristiano Ronaldo",
"season": "Champions League 2014/2015",
"number": 7,
"scores": 48
}
]
}
]
}
}
The code block below shows the XML representation of an instantiation of the example-sports data model.
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<sports xmlns="http://example.com/example-sports">
<person>
<name>Lionel Andrés Messi</name>
<birthday>1987-06-24T00:00:00-00:00</birthday>
</person>
<person>
<name>Cristiano Ronaldo</name>
<birthday>1985-02-05T00:00:00-00:00</birthday>
</person>
<team>
<name>FC Barcelona</name>
<player>
<name>Lionel Andrés Messi</name>
<season>Champions League 2014/2015</season>
<number>10</number>
<scores>43</scores>
</player>
</team>
<team>
<name>Real Madrid</name>
<player>
<name>Cristiano Ronaldo</name>
<season>Champions League 2014/2015</season>
<number>7</number>
<scores>48</scores>
</player>
</team>
</sports>
</data>
The following Request for Comments (RFCs) define the YANG language and some basic extensions:
The following requests for comments provide guidelines and supporting documentation:
The following requests for comments define standards-track protocols that are (partially) defined using YANG modules:
The following RFCs define standards-track YANG data models:
The following requests for comments are experimental specifications that use or extend YANG:
Open source implementations (sorted by name):
Closed source implementations (sorted by name):