The YANG 1.1 Data Modeling Language
updated by
Extracted elements (32)
Grouping, type, and identity names are resolved in the context where they are defined rather than where they are used (static scoping), eliminating ambiguity when groupings are instantiated in modules other than the defining module.
The backward-incompatible changes to string quoting rules in YANG 1.1 — new escape sequences, prohibition of bare quotes in unquoted strings, and illegal noncharacters — were made to address specific ambiguities and defects in RFC 6020.
YANG 1.1 replaced the NETCONF <hello> capability-advertisement mechanism with 'ietf-yang-library', enabling clients to cache module support keyed on 'module-set-id' and detect changes without re-parsing capabilities on every session.
YANG's C-like syntax was chosen specifically for readability, since YANG prioritizes the time of model readers over module writers and toolchain developers.
In YANG 1.1, a submodule can reference all definitions in all submodules of the same module without an explicit 'include' statement. For backward compatibility with YANG 1, submodule 'include' of sibling submodules is still permitted (MAY) but no longer required.
YANG 1.1 introduces four backward-incompatible changes from YANG 1: revised double-quoted string escape rules, prohibition of quote characters in unquoted strings, 'when' and 'if-feature' illegal on list keys, and noncharacters illegal in the 'string' built-in type.
A module or submodule MUST NOT include submodules from other modules, and a submodule MUST NOT import its own module. A submodule MUST NOT include different revisions of other submodules than the revisions that its parent module includes.
A NETCONF server MUST advertise the yang-library capability in the <hello> message including 'revision' and 'module-set-id' parameters; both parameters MUST be present.
A NETCONF server MUST announce the modules it implements by implementing 'ietf-yang-library' (RFC 7895) and listing all implemented modules in the '/modules-state/module' list, replacing the YANG 1 capability-advertisement approach.
A server MUST NOT implement more than one revision of a module. If a server implements module A that imports module B and uses any node from B in an 'augment' or 'path' statement, the server MUST implement a revision of B that defines those nodes.
All identifiers defined in a namespace MUST be unique. Implementations MUST support identifiers up to 64 characters in length and MAY support longer identifiers. Identifiers are case sensitive.
Developers of YANG modules are RECOMMENDED to choose names with a low probability of colliding with standard or other enterprise modules, e.g., by using the enterprise or organization name as a prefix for the module name.
In a double-quoted string, the backslash MUST NOT be followed by any character other than 'n', 't', '"', or '\'. This is a backward-incompatible change from YANG version 1.
Scoped definitions MUST NOT shadow definitions at a higher scope; a type or grouping cannot be defined if a higher level in the statement hierarchy already has a definition with a matching identifier.
There MUST NOT be any circular chains of imports. If module 'a' imports module 'b', 'b' cannot import 'a'. Within a server, all module names MUST be unique.
XML namespaces for modules published in RFC streams MUST be assigned by IANA. Private module namespace URIs MUST be chosen so they cannot collide with standard or other enterprise namespaces.
The 'action' statement (new in YANG 1.1) defines an operation tied to a specific data node (container or list), as distinct from top-level 'rpc' operations. Actions are invoked via the NETCONF <action> element in the 'urn:ietf:params:xml:ns:yang:1' namespace.
The 'anydata' statement (new in YANG 1.1) defines a data node that can contain an unknown set of YANG-modelable nodes (excluding anyxml). It is RECOMMENDED over 'anyxml' when the contained data can be modeled in YANG.
The 'augment' statement inserts additional nodes into a data model hierarchy defined in another module or the current module. The inserted elements carry the augmenting module's XML namespace and may be conditional via a 'when' expression.
The 'choice' and 'case' statements model mutually exclusive schema alternatives. Only one case can be valid at a time; when a node from one case is created in the data tree, nodes from all other cases are implicitly deleted by the server.
The 'deviation' statement allows servers to formally declare how their implementation diverges from a data model, identifying the schema node and describing the specific deviation so clients can adapt behavior in advance.
The 'feature' and 'if-feature' statements provide conditional conformance: portions of a model are marked optional per feature, servers declare which features they support, and in YANG 1.1, 'if-feature' accepts boolean expressions over feature names.
The 'grouping' statement defines a reusable set of schema nodes instantiated via 'uses'. The 'refine' substatement allows targeted overrides at the point of use, and the 'augment' substatement can add nodes to the instantiated grouping.
The 'identity' statement defines a globally unique abstract name. In YANG 1.1, identities may be derived from multiple base identities, enabling multiple inheritance. XPath functions derived-from() and derived-from-or-self() test identity relationships.
YANG defines four main data node types: leaf (single typed value, no children), leaf-list (ordered sequence of values of one type), container (no value, has child nodes), and list (multiple keyed instances, each with child nodes).
YANG provides 19 built-in types: binary, bits, boolean, decimal64, empty, enumeration, identityref, instance-identifier, int8/int16/int32/int64, leafref, string, uint8/uint16/uint32/uint64, and union.
IANA assigns XML namespace URIs for YANG modules published in RFC streams (see RFC 6020 Section 14). YANG defines the reserved namespace 'urn:ietf:params:xml:ns:yang:1' for NETCONF <edit-config> operations, <error-info> content, and the <action> element.
YANG itself is a data modeling language and does not define protocol-level security mechanisms. Security for YANG-based management protocols (e.g., NETCONF) must be provided by those protocols. The security considerations of RFC 6241 (NETCONF) apply when YANG is used with NETCONF.
NETCONF constraint enforcement proceeds in three ordered phases: (1) payload parsing — malformed XML rejected; (2) edit-config processing — operations applied to the datastore; (3) validation — 'must', 'unique', 'min-elements', 'max-elements', 'mandatory', and 'require-instance' constraints checked.
YANG data nodes are XML-encoded using the module's declared namespace URI. Top-level nodes appear as child elements of NETCONF <config> or <data> elements in any order. Augmented nodes carry the augmenting module's namespace rather than the augmented module's namespace.
YANG modules are stored in UTF-8 encoded files. Legal characters are Unicode/ISO 10646 characters including tab, CR, and LF, but excluding other C0 control characters, surrogate blocks, and noncharacters. Noncharacters are also illegal in the 'string' built-in type at runtime.
YIN (YANG Independent Notation) is a semantically lossless XML representation of YANG modules. Each YANG statement maps to an XML element; the conversion is round-trippable. YIN files use the '.yin' extension and enable XSLT-based processing of data models.