RFC 10035

YANG Library: Addition of the augmented-by List

📅 published August 2026, from ietf

RFC 10035: YANG Library: Addition of the augmented-by List 🎀

Okay bestie, let's get you set up 💖 This is RFC 10035 from the IETF, a Standards Track doc dated August 2026 (ISSN 2070-1721). It was written by Z. Lin (Huawei), B. Claise (Everything OPS), and I. D. Martinez-Casanueva (Telefonica). It updates RFC 8525 and doesn't list anything it obsoletes. 🦋

Abstract ✨

So "YANG Library" (RFC 8525) is the spec for the ietf-yang-library YANG module. It tells you about the YANG modules, datastores, and datastore schemas a network management server is using. 🧚

This doc adds an augmented-by list to that module. The big payoff is that you can find all the dependencies between YANG modules just by querying the server's YANG library, no digging required 🔥 It also updates RFC 8525 so the augmented-by list is part of it.

Status of This Memo 🌸

This is an Internet Standards Track document. ✨

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841. 💅

Want the current status, any errata, or a way to send feedback? Head to https://www.rfc-editor.org/info/rfc10035. 🫶

Copyright Notice 🌈

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they're in effect on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License. 🙈

Table of Contents 📑

1.  Introduction
  1.1.  Requirements Language
  1.2.  Terminology
  2.  Motivation
  3.  Use Cases
    3.1.  Data Mesh Architecture
    3.2.  Data Catalog
  4.  The "ietf-yang-library-augmentedby" YANG Module
    4.1.  Data Model Overview
      4.1.1.  Tree Structure
      4.1.2.  The "ietf-yang-library-augmentedby" YANG Module
    4.2.  Implementation Instructions
      4.2.1.  The Scope of augmented-by
      4.2.2.  Examples
  5.  Operational Considerations
  6.  Security Considerations
  7.  IANA Considerations
  8.  References
    8.1.  Normative References
    8.2.  Informative References
  Appendix A.  Full Tree View of "ietf-yang-library"
  Acknowledgments
  Authors' Addresses

1. Introduction 🦋

So the YANG library [RFC8525] tells you which data models a server supports. It's basically an inventory of YANG modules. It also lists every datastore a network management server supports, plus the schema each of those datastores uses. Super helpful for clients! 💖

According to Sections 4.2.8 and 5.6.3 of [RFC7950], an "augment" adds extra nodes to a module, and a "deviation" changes (adds, modifies, or deletes) properties, meaning sub-statements, of another module's schema nodes. These are crucial clues about how a YANG data model is put together 👑 In this document we call that a "reverse dependency." It means a schema node's behavior depends on outside changes, so the influence flows backward from the augmenting and/or deviation module to the base module. Wild, right? 🤯

Getting the YANG schema tree (defined in Section 3 of [RFC7950]) is rough. You basically have to grab and parse every YANG module from the management server first. The deviation list in the YANG library lets clients find a module's reverse dependencies without fetching and parsing everything. The augmentation list, though? Not defined in the YANG library yet. Missing piece 😭

Since augmentation and deviation both work as YANG module dependencies, it makes total sense to document them the same way in the YANG library. Having both right there in the library gives you a clean way to figure out reverse dependencies. ✨

This document specifies a YANG module that augments the YANG library so it includes the YANG module augmentation information. It updates [RFC8525] by modifying the list in Section 2 so it also includes the augmented-by list. 🎀

One specific requirement for implementing this augmented-by YANG module: the modules and their augmented-by modules are required to be listed in the same module-set. Deviations already have a similar rule, so this is nothing new for them 🧚

1.1. Requirements Language 🎀

Okay, the capital-letter words are super important 🫶 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, exactly like this.

1.2. Terminology 📖

The terminology from [RFC8525] is used in this document. 💅

The term "client" is used as defined in [RFC6241] for NETCONF and [RFC8040] for RESTCONF. ✨

The term "YANG schema tree" is used as defined in Section 3 of [RFC7950]. 🌸

The term "Network Management Datastore Architecture (NMDA)" is used as defined in [RFC8342]. 🦋

Tree diagrams in this document use the notations defined in [RFC8340]. 🧚

This document also defines the following term: 👑

Reverse Dependency: the dependency on YANG modules that modify the behavior of a base YANG module from the outside, either by inserting additional nodes (augment) or by deviating existing nodes (deviation).

2. Motivation 🌈

When you're working with YANG modules, you need every dependency in place. [RFC7950] names four types of dependencies between YANG modules: 💖

Import: the "import" statement lets a module or submodule reference definitions that live in other modules.
Include: the "include" statement is used in a module to name each submodule that belongs to it.
Augment: the "augment" statement defines the spot in the data model hierarchy where extra nodes get inserted.
Deviation: the "deviation" statement defines a fragment of a module that the server does not implement.

"Import" and "include" are direct dependencies, so you can find them by parsing a YANG module's source code. "Augment" and "deviation" are reverse dependencies, though, because they're defined in some other module. 🔍

Reverse dependencies are a pain because they're defined externally, so you can't spot them by parsing the module itself. The usual way to find them is to pull every YANG module from the server and parse it. That takes forever, and every client that needs the info has to do it again. 😩

According to the definition of the "ietf-yang-library" module in [RFC8525], the "deviation" list names each YANG module with deviation statements that affect a given YANG module. Deviations and augmentations work in similar ways, so if the YANG library could report every reverse dependency, augmentations included, finding all the module dependencies would be way easier than fetching and parsing every module. 🎀 Also, to avoid problems on devices, like wrongly referring to modules in the wrong module-set, this document requires that base modules and their augmentations be listed in the same module-set. 🫶

The YANG library only provides the deviation list and no augmentations. Augmentations are used more and more, and automated network management needs them, so they're essential for clients trying to understand how the network management server's modules relate to each other. Thus, the YANG library should be extended to provide augmentation information too. 💜

3. Use Cases 🧚

3.1. Data Mesh Architecture 🦋

YANG-based telemetry [RFC8641] is in demand right now, and that creates a need to know a specific YANG module's dependency list in real time, as soon as a given YANG-Push notification for a subscription arrives. 📡

Some YANG-Push receivers collect this info ahead of time, storing the full module-set for every single server that could be streaming data. That isn't always practical, though. It breaks down for configured subscriptions [RFC8639], where the YANG-Push receiver isn't the one configuring the subscriptions, and for UDP transport [YANG-UDP]. For more details, check out Figure 1 in "An Architecture for YANG-Push to Message Broker Integration" [YANG-PUSH]. 🌸

This architecture depends on the YANG dependency info from this specification, so it can solve the problem of missing YANG semantics when notifications get transformed or indexed in a time series database. 💖

Before this specification existed, the way to get modules and find their dependencies was to pull the entire set of supported YANG modules from the network device. That got triggered by parsing the <subscription-started> message for every new YANG-Push subscription. Why? Because the YANG-Push receiver wouldn't know which YANG-Push publisher was sending the subscribed YANG content until the first notification showed up. So much wasted effort 😭

With the augmented-by info from this specification, the YANG-Push receiver can get the YANG reverse dependencies for the specific YANG module(s) in the subscription directly by querying the server. That saves collection and processing time at the receiver, because it only queries dependencies for the modules it actually needs, which helps with the real-time side of network observability. ✨

Here's an example YANG-Push message for this use case, received from a subscription to the "ietf-interfaces" YANG module: 🍓

  "datastore-contents": {
    "ietf-interfaces:interfaces": [
    {
      "interface": {
        "name": "eth0",
        "type": "iana-if-type:ethernetCsmacd",
        "oper-status": "up",
        "speed": "1000000",
        "ietf-ip:ipv4": {
          "enabled": true,
          "forwarding": true
        }
      }
    }
    ]
  }

To correctly interpret this message, you need both the "ietf-interfaces" and "ietf-ip" YANG modules. 🤯 Knowing only that the subscribed module is "ietf-interfaces" isn't enough, but that's currently the only dependency info the subscription exposes. So we need a way to discover all the relevant dependency modules, especially reverse dependencies like "ietf-ip" in this example. That way, every YANG module referenced in the pushed data can be reliably identified. 💜

3.2. Data Catalog 📚✨

Okay so, finding the YANG modules a network management server implements is literally paramount if you want to configure or monitor a network 💅. Ever since YANG showed up, the network industry has been making a huge pile of YANG modules. They come from Standards Development Organizations (SDOs), open-source communities, and network vendors 🌈. All that variety, where every device or service model is a little different, makes managing a multi-vendor network a big challenge for operators [Martinez-Casanueva2023] 😭.

So a data catalog is basically a registry of the datasets that remote data sources expose, so consumers can find the data they care about 🦋. Obviously it stores where the dataset lives (the data source), but it also keeps extra metadata like the data model (or schema) the dataset follows, or even related terms from a business glossary 📖.

Data catalog solutions usually have collectors that ingest metadata from the data sources themselves and from external metadata sources 🧚. For example, a message broker schema registry is a metadata source that tells you about the data model followed by some data stored in a message broker topic 💜.

Now here's the vibe: a YANG-enabled network device can count as another kind of data source, one the data catalog can pull metadata from 🔥. For instance, the catalog can include a connector that fetches metadata about the YANG modules a network device implements. If you combine that with other stuff like the business concept "interface", data consumers can discover which datasets related to the concept "interface" are exposed by the network device. It's giving main character energy 👑.

Here's the tea though 🫖: network devices that implement the YANG library expose metadata about which YANG modules are implemented and which are only imported. BUT what a data consumer actually needs is the YANG modules implemented by the device. So you need to combine those with other YANG modules that might deviate or augment the former 🙈.

Let's make it concrete. Say a network device implements the "ietf-interfaces" module [RFC8343] and the "ietf-ip" module [RFC8344], where the latter augments the former 🌸. For a data catalog to collect this metadata, a connector would grab YANG library data from the target device. The problem? The current version of the YANG library wouldn't cut it, because it would say the device implements both ietf-interfaces and ietf-ip, but it would miss the augment dependency between them 💀.

The workaround is to also get both YANG modules and process them together with the YANG library data, so you can discover that augment dependency. Iykyk, that's a lot of extra work for the connector, which ends up juggling multiple metadata collection mechanisms 😩. A cleaner glow-up would be extending the YANG library to also capture augment dependencies, similar to how deviation dependencies are captured ✨.

4. The "ietf-yang-library-augmentedby" YANG Module 🧚

4.1. Data Model Overview 🌸

4.1.1. Tree Structure 🌳

Here's the YANG tree diagram for the ietf-yang-library-augmentedby module 👀.

module: ietf-yang-library-augmentedby

  augment /yanglib:yang-library/yanglib:module-set/yanglib:module:
    +--ro augmented-by*   -> ../../yanglib:module/name
  augment /yanglib:modules-state/yanglib:module:
    x--ro augmented-by*   -> ../../yanglib:module/name

This YANG module augments the ietf-yang-library module by adding the augmented-by leaf-list in the yang-library/module-set and yang-library/modules-state. The name of the augmented-by list tells you which modules the current module is being directly augmented by 💖.

Okay, so yang-library/modules-state gets augmented even though it's deprecated 🙃. Why? Because some folks still use the modules-state container for compatibility reasons with the ietf-yang-library module defined in [RFC7895]. And both the NMDA [RFC8342] and non-NMDA compliant additions live in the same YANG module, to keep things simple for users and implementors 🧸.

For augmented-by, this document only looks at the direct augmentation relationship 🎯. The recursive result of augmentation, or transitive dependency, for modules specified along the XPath is out of scope here 🙅. For the implementation instructions, check Section 4.2 📝.

4.1.2. The "ietf-yang-library-augmentedby" YANG Module 🎀

This YANG module imports and augments the ietf-yang-library module [RFC8525] 🧩.

<CODE BEGINS> file "ietf-yang-library-augmentedby@2026-08-26.yang"
module ietf-yang-library-augmentedby {
  yang-version 1.1;
  namespace
    "urn:ietf:params:xml:ns:yang:ietf-yang-library-augmentedby";
  prefix yanglib-aug;

  import ietf-yang-library {
    prefix yanglib;
    reference
      "RFC 8525: YANG Library";
  }

  organization
    "IETF NETCONF (Network Configuration) Working Group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/netconf/>
     WG List:  <mailto:netconf@ietf.org>

     Authors:  Zhuoyao Lin
               <mailto:zephyre888@gmail.com>
               Benoit Claise
               <mailto:benoit@everything-ops.net>
               Ignacio Dominguez Martinez-Casanueva
               <mailto:i.domingumar@gmail.com>";
  description
    "This module augments the 'ietf-yang-library' module defined in
     RFC 8525 to provide not only the deviation list, but also
     the augmented-by list, in order to give sufficient
     information about the YANG module's reverse dependency.  It
     facilitates the process of obtaining all the
     dependencies of YANG module.

     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
     NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
     'MAY', and 'OPTIONAL' in this document are to be interpreted as
     described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
     they appear in all capitals, as shown here.

     Copyright (c) 2026 IETF Trust and the persons
     identified as authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject
     to the license terms contained in, the Revised BSD License
     set forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).

     All revisions of IETF and IANA published modules can be found
     at the YANG Parameters registry group
     (https://www.iana.org/assignments/yang-parameters).

     This version of this YANG module is part of RFC 10035; see
     the RFC itself for full legal notices.";

  revision 2026-08-26 {
    description
      "Initial revision.";
    reference
      "RFC 10035: YANG Library: Addition of the augmented-by List";
  }

  augment "/yanglib:yang-library/yanglib:module-set/yanglib:module" {
    description
      "Adds augmented-by leaf-list to the list of modules of a
       module set";
    leaf-list augmented-by {
      type leafref {
        path "../../yanglib:module/yanglib:name";
      }
      description
        "Leaf-list of the augmentations used by this server to
         modify the schema tree of the module associated with
         this entry.  Note that the same module can be used for
         augmented-by for multiple modules, so the same
         entry MAY appear within multiple 'module' entries.

         This reference MUST NOT (directly or indirectly)
         refer to the module being augmented and MUST NOT
         be referenced in the import-only list.

         Robust clients may want to make sure that they handle a
         situation where a module augments itself (directly or
         indirectly) gracefully.";
    }
  }

  augment "/yanglib:modules-state/yanglib:module" {
    status deprecated;
    description
      "Adds augmented-by leaf-list to the list of modules of a
       module set";
    leaf-list augmented-by {
      type leafref {
        path "../../yanglib:module/yanglib:name";
      }
      status deprecated;
      description
        "Leaf-list of the augmentations used by this server to
         modify the schema tree of the module associated with
         this entry.  Note that the same module can be used for
         augmented-by for multiple modules, so the same
         entry MAY appear within multiple 'module' entries.

         This reference MUST NOT (directly or indirectly)
         refer to the module being augmented and MUST NOT
         be referenced in the import-only list.

         Robust clients may want to make sure that they handle a
         situation where a module augments itself (directly or
         indirectly) gracefully.";
    }
  }
}
<CODE ENDS>

4.2. Implementation Instructions 🛠️

4.2.1. The Scope of augmented-by 🔍

Let's talk about what augmented-by actually covers 🔍. The augmented-by leaf-list should only look at YANG modules that directly augment the YANG module in question in the ietf-yang-library module 🎯, and the augmenting and augmented modules must be defined in the same module-set.

The "direct augment" is identified by the relationship between the augment module and the target node's parent module that it augments 💅. Only the direct parent module of the target node is augmented. The rest of the parent modules defined in the schema tree are only indirect dependencies, so they are not augmented modules 🙅. (Refer to the definition of "target node" in Section 7.17 of [RFC7950] 📖.)

If a YANG application needs a recursive dependency or a specific schema tree dependency, the search logic should be implemented by the application itself 🧠.

4.2.2. Examples 📚

This section gives you two module-set examples and their corresponding ietf-yang-library-augmentedby query results 🦋. They explain the definition of "direct augment" stated in Section 4.2.1 ✨.

The two scenarios use the same three YANG modules (Module A, B, and C) defined in the module-set. The relationships among them are different, though 👀. All three YANG modules are defined in the same module-set name "module-set1", so they can augment or be augmented by the others. Otherwise, the YANG validation should fail 💀.

The examples use line wrapping per [RFC8792] 🌈.

4.2.2.1. Example 1 🦋

okay so let's set the scene 🎬 here's how Module A, Module B, and Module C are related:

Module A is the base module with container "foo-a"
Module B augments "/A:foo-a" with container "foo-b"
Module C augments "/A:foo-a" with leaf "leaf-c"

the "ietf-yang-library-augmentedby" query result is giving main character energy 💅 (file example_yanglib_result1.xml):

<!-- NOTE: '\' line wrapping per RFC 8792 -->
<yang-library xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
  <content-id>1</content-id>
  <module-set>
    <name>module-set1</name>
    <module>
      <name>A</name>
      <revision>2026-08-19</revision>
      <namespace>urn:ietf:params:xml:ns:yang:A</namespace>
      <augmented-by
      xmlns="urn:ietf:params:xml:ns:yang:\
      ietf-yang-library-augmentedby">B</augmented-by>
      <augmented-by
      xmlns="urn:ietf:params:xml:ns:yang:\
      ietf-yang-library-augmentedby">C</augmented-by>
    </module>
    <module>
      <name>B</name>
      <revision>2026-08-19</revision>
      <namespace>urn:ietf:params:xml:ns:yang:B</namespace>
    </module>
    <module>
      <name>C</name>
      <revision>2026-08-19</revision>
      <namespace>urn:ietf:params:xml:ns:yang:C</namespace>
    </module>
  </module-set>
</yang-library>
<modules-state xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
    <module-set-id>0</module-set-id>
</modules-state>

bestie, both Module B and Module C directly augment the container "foo-a" 🫶 so both B and C get listed as "augmented-by" modules for Module A. iconic ✨

4.2.2.2. Example 2 💖

same cast, but the plot twist is in the wiring 🎀

Module A is the base module with container "foo-a"
Module B augments "/A:foo-a" with container "foo-b"
Module C augments "/A:foo-a/B:foo-b" with leaf "leaf-c"

the "ietf-yang-library-augmentedby" query result (file example_yanglib_result2.xml):

<!-- NOTE: '\' line wrapping per RFC 8792 -->
<yang-library xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
  <content-id>1</content-id>
  <module-set>
    <name>module-set1</name>
    <module>
      <name>A</name>
      <revision>2026-08-19</revision>
      <namespace>urn:ietf:params:xml:ns:yang:A</namespace>
      <augmented-by
      xmlns="urn:ietf:params:xml:ns:yang:\
      ietf-yang-library-augmentedby">B</augmented-by>
    </module>
    <module>
      <name>B</name>
      <revision>2026-08-19</revision>
      <namespace>urn:ietf:params:xml:ns:yang:B</namespace>
      <augmented-by
      xmlns="urn:ietf:params:xml:ns:yang:\
      ietf-yang-library-augmentedby">C</augmented-by>
    </module>
    <module>
      <name>C</name>
      <revision>2026-08-19</revision>
      <namespace>urn:ietf:params:xml:ns:yang:C</namespace>
    </module>
  </module-set>
</yang-library>
<modules-state xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
  <module-set-id>0</module-set-id>
</modules-state>

ngl this one is a whole twist 😭 even though the augment XPath statement used by Module C is rooted at the container "foo-a" defined in Module A, the node Module C actually augments is the container "foo-b" defined in Module B. so Module C is not considered to directly augment Module A, and therefore it does not appear in the "augmented-by" leaf-list of Module A. only Module B, which directly augments the container "foo-a", gets listed as an "augmented-by" module for Module A 💀✨

5. Operational Considerations 🛠️

okay the vibe check here: with augmented-by in the picture, the base modules and the augmented-by modules are required to be listed in the same module-set. no skipping, periodt 💅

also, the reverse dependency is going to make the ietf-yang-library instance on the server bigger 📈 and the ietf-yang-library instance, and therefore the augmented-by instance, should be updated whenever new YANG modules get onboarded 🔄

if you want to see what the expected augmented-by result looks like in a YANG example, check out Section 4.2.2 🎀

6. Security Considerations 🔐

this section is modeled after the template described in Section 3.7.1 of [RFC9907]. okay, it's serious time, but make it cute 🌸

the "ietf-yang-library-augmentedby" YANG module is a data model that's designed to be accessed through YANG-based management protocols, like the Network Configuration Protocol (NETCONF) [RFC6241] and RESTCONF [RFC8040]. these YANG-based management protocols (1) have to use a secure transport layer (e.g., Secure Shell (SSH) [RFC4252], TLS [RFC9846], and QUIC [RFC9000]) and (2) have to use mutual authentication 🫶

the Network Configuration Access Control Model (NACM) [RFC8341] is basically the bouncer 🚪 it provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.

there are no writable ("config true") data nodes defined in this YANG module 🙌

this YANG module defines only readable ("config false") data nodes. some of the readable data nodes in this module may be considered sensitive or vulnerable in some network environments, so it is important to control read access (e.g., via get, get-config, or notification) to these data nodes 😬 specifically, these subtrees and data nodes have particular sensitivities and vulnerabilities:

/yang-library/module-set/module/augmented-by
/modules-state/module/augmented-by (modules-state is deprecated)

⚠️ these nodes expose the augmentation relationships among modules implemented by a server. unauthorized read access could help an attacker identify implementation structure, optional features, or software components present on a server, which might then be used to target known platform vulnerabilities. it's giving danger zone. therefore, access control policies SHOULD restrict read access to authorized users only. no exceptions, no cap 🚨

there are no RPCs or action operations defined in this module, so there are no particularly sensitive RPC or action operations. a clean slate 🧼

this module uses groupings from the "ietf-yang-library" YANG module defined in [RFC8525], which defines nodes that may be considered sensitive or vulnerable in network environments. since this document augments the "ietf-yang-library" YANG module defined in [RFC8525], the Security Considerations of [RFC8525] apply here as well. refer to Section 6 of [RFC8525] for information about which nodes may be considered sensitive or vulnerable in network environments 📖

7. IANA Considerations 📋

IANA has registered the following URI in the "ns" registry within the "IETF XML Registry" registry group [RFC3688]:

URI:  urn:ietf:params:xml:ns:yang:ietf-yang-library-augmentedby
Registration Contact:  The IESG
XML:  N/A, the requested URI is an XML namespace.

IANA has registered the following YANG module in the "YANG Module Names" registry [RFC6020] within the "YANG Parameters" registry group:

Name:  ietf-yang-library-augmentedby
Maintained by IANA?  N
Namespace:  urn:ietf:params:xml:ns:yang:ietf-yang-library-augmentedby
Prefix:  yanglib-aug
Reference:  RFC 10035

8. References 📚

8.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.

[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.

[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>.

[RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., and R. Wilton, "YANG Library", RFC 8525, DOI 10.17487/RFC8525, March 2019, <https://www.rfc-editor.org/info/rfc8525>.

8.2. Informative References 📚✨

okay bestie, these are the background reads and the receipts 🧾💜 they're not the core spec, just the extra context behind it. let's go!

[Martinez-Casanueva2023] Martinez-Casanueva, I. D., Gonzalez-Sanchez, D., Bellido, L., Fernandez, D., and D. R. Lopez, "Toward Building a Semantic Network Inventory for Model-Driven Telemetry", IEEE Communications Magazine, vol. 61, no. 3, pp. 60-66, DOI 10.1109/MCOM.001.2200222, March 2023, <https://doi.org/10.1109/MCOM.001.2200222>.

[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, January 2006, <https://www.rfc-editor.org/info/rfc4252>.

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.

[RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, <https://www.rfc-editor.org/info/rfc7895>.

[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.

[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.

[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/info/rfc8342>.

[RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, <https://www.rfc-editor.org/info/rfc8343>.

[RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", RFC 8344, DOI 10.17487/RFC8344, March 2018, <https://www.rfc-editor.org/info/rfc8344>.

[RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, E., and A. Tripathy, "Subscription to YANG Notifications", RFC 8639, DOI 10.17487/RFC8639, September 2019, <https://www.rfc-editor.org/info/rfc8639>.

[RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, September 2019, <https://www.rfc-editor.org/info/rfc8641>.

[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, "Handling Long Lines in Content of Internet-Drafts and RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, <https://www.rfc-editor.org/info/rfc8792>.

[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.

[RFC9846] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026, <https://www.rfc-editor.org/info/rfc9846>.

[RFC9907] Bierman, A., Boucadair, M., Ed., and Q. Wu, "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models", BCP 216, RFC 9907, DOI 10.17487/RFC9907, March 2026, <https://www.rfc-editor.org/info/rfc9907>.

[YANG-PUSH] Graf, T. and A. Elhassany, "An Architecture for YANG-Push to Message Broker Integration", Work in Progress, Internet-Draft, draft-ietf-nmop-yang-message-broker-integration-13, 2 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-nmop-yang-message-broker-integration-13>.

[YANG-UDP] Feng, A. H., Francois, P., Zhou, T., Graf, T., and P. Lucente, "UDP-based Transport for Configured Subscriptions", Work in Progress, Internet-Draft, draft-ietf-netconf-udp-notif-26, 29 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif-26>.

Appendix A. Full Tree View of "ietf-yang-library" 🌳

okay so this is the full picture 🖼️✨ it's the YANG tree diagram [RFC8340] for the "ietf-yang-library" module, showing it after the augmentation from the "ietf-yang-library-augmentedby" module is added in. the RPCs and notifications are in here too, so nothing gets left out 💅

[NOTE: '\' line wrapping per RFC 8792]
module: ietf-yang-library
  +--ro yang-library
  |  +--ro module-set* [name]
  |  |  +--ro name                  string
  |  |  +--ro module* [name]
  |  |  |  +--ro name                        yang:yang-identifier
  |  |  |  +--ro revision?                   revision-identifier
  |  |  |  +--ro namespace                   inet:uri
  |  |  |  +--ro location*                   inet:uri
  |  |  |  +--ro submodule* [name]
  |  |  |  |  +--ro name        yang:yang-identifier
  |  |  |  |  +--ro revision?   revision-identifier
  |  |  |  |  +--ro location*   inet:uri
  |  |  |  +--ro feature*                    yang:yang-identifier
  |  |  |  +--ro deviation*                  -> ../../module/name
  |  |  |  +--ro yanglib-aug:augmented-by*
                                     -> ../../yanglib:module/name
  |  |  +--ro import-only-module* [name revision]
  |  |     +--ro name         yang:yang-identifier
  |  |     +--ro revision     union
  |  |     +--ro namespace    inet:uri
  |  |     +--ro location*    inet:uri
  |  |     +--ro submodule* [name]
  |  |        +--ro name        yang:yang-identifier
  |  |        +--ro revision?   revision-identifier
  |  |        +--ro location*   inet:uri
  |  +--ro schema* [name]
  |  |  +--ro name          string
  |  |  +--ro module-set*   -> ../../module-set/name
  |  +--ro datastore* [name]
  |  |  +--ro name      ds:datastore-ref
  |  |  +--ro schema    -> ../../schema/name
  |  +--ro content-id       string
  x--ro modules-state
     x--ro module-set-id    string
     x--ro module* [name revision]
        x--ro name                yang:yang-identifier
        x--ro revision            union
        +--ro schema?             inet:uri
        x--ro namespace           inet:uri
        x--ro feature*            yang:yang-identifier
        x--ro deviation* [name revision]
        |  x--ro name        yang:yang-identifier
        |  x--ro revision    union
        x--ro conformance-type    enumeration
        x--ro submodule* [name revision]
        |  x--ro name        yang:yang-identifier
        |  x--ro revision    union
        |  +--ro schema?     inet:uri
        x--ro yanglib-aug:augmented-by*\
          -> ../../yanglib:module/name

  notifications:
    +---n yang-library-update
    |  +--ro content-id    -> /yang-library/content-id
    x---n yang-library-change
       x--ro module-set-id    -> /modules-state/module-set-id

Acknowledgments 🫶

big thank-you energy to everyone who helped out 💖 the authors want to thank Jan Lindblad and Jean Quilbeuf for their help during the design of the YANG module 🧚 and Thomas Graf, Rob Wilton, Andy Bierman, Jean Quilbeuf, Alex Huang Feng, Per Andersson, Mahesh Jethanandani, and Med Boucadair for their valuable review and comments 🌸 literally the dream review squad 👑

Authors' Addresses 🦋

here's who wrote it and where to find them 📬

Zhuoyao Lin
Huawei
Townsend Street, 4th Floor George's Court
Dublin
Ireland
Email: zephyre888@gmail.com

Benoit Claise
Everything OPS
Belgium
Email: benoit@everything-ops.net

Ignacio Dominguez Martinez-Casanueva
Telefonica
Ronda de la Comunicacion, S/N
28050 Madrid
Spain
Email: i.domingumar@gmail.com

📦 where this page comes from

ietf: rfc10035 2026-08
💖 girlified by claude-haiku-5-5 on 2026-10-15: a language model's rewrite of the original, under its terms