Huawei

Townsend Street, 4th Floor George's Court Dublin Ireland zhuoyao.lin1@huawei-partners.com

Everything OPS

benoit@everything-ops.net

Telefonica

Ronda de la Comunicacion, S/N Madrid 28050 Spain ignacio.dominguezmartinez@telefonica.com

OPS NETCONF "YANG Library" specifies the YANG module "ietf-yang-library" that provides information about the YANG modules, datastores, and datastore schemas used by a network management server. This document augments the "ietf-yang-library" to provide the augmented-by list. It facilitates the process of obtaining all dependencies between YANG modules, by querying the network management server's YANG library. This document updates RFC 8525, as the lists in Section 2 is modified to also include augmented-by list. Source for this draft and an issue tracker can be found at .

The YANG library provides information about the data models supported by a server. This is presented as an inventory of YANG modules. It helps a client with listing all datastores supported by a network management server and the schema that is used by each of these datastores. According to Sections 4.2.8 and 5.6.3 of , augment defines additional nodes to a module while deviations change (add, modify, delete) properties (sub-statements) to other module's schema nodes. They provide crucial information about the YANG data model composition, and is referred to as reverse dependency in this document: this means the behavior of a schema node depends on external modifications, creating flow backward from the augmenting/deviation module to the base module. It is difficult to obtain the YANG schema tree (defined in Section 3 in ) without obtaining and parsing all the YANG modules from a management server. The deviation list defined in YANG library enables clients to obtain a module reverse dependency without having to get and parse all YANG modules. However, the augmentation list is not defined in it. Since both augmentation and deviation work as YANG module dependencies, it is reasonable to document them the same way in the YANG library. Having both augmentation and deviation directly available in the YANG library provides a convenient solution for determining the reverse dependencies. This document specifies a YANG module that augments the YANG library to include the YANG module augmentation information. It updates RFC 8525, as the lists in Section 2 is modified to also include augmented-by list. One specific requirement with the implementation of this augmented-by YANG module specification is, the modules and the augmented-by modules require to be listed in the same module-set. Note that a similar requirement already applies for the YANG deviations.

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 when, and only when, they appear in all capitals, as shown here.

The terminology from is used in this document The term "client" is used as defined in for NETCONF and for RESTCONF. The term "YANG schema tree" is used as defined in Section 3 of The term Network Management Datastore Architecture (NMDA) is used as defined in Tree diagrams in this document use the notations defined in . This document defines the following term:

• Reverse Dependency: is the dependency YANG modules that provide external modification to the behavior of a base YANG module, by inserting additional nodes (augment) or deviating existing nodes (deviation).

When using YANG modules, it is necessary to make sure that all its dependencies are present. identifies four types of dependencies between YANG modules:

• Import: the "import" statement allows a module or submodule to reference definitions defined in other modules.
• Include: the "include" statement is used in a module to identify each submodule that belongs to it.
• Augment: the augmentation defines the location in the data model hierarchy where additional nodes are inserted.
• Deviation: the "deviation" statement defines a fragment of a module that the server does not implement.

"import" and "include" are direct dependencies which can be obtained by parsing a YANG module source code, while the augmentation and deviation are reverse dependencies which are defined in another module. For the reverse dependencies, since they are defined externally, it is not possible to discover them by parsing the YANG module. The current way to discover the reverse dependencies is to query all YANG modules from the server and parse them. This is a lengthy process, which must be repeated for each client that requires this information. According to the definition of the module ietf-yang-library defined in , the "deviation" list describes that a module is deviated by which other modules. Since deviations and augmentations work similarly, if the YANG library could directly report all reverse dependencies, including augmentations, it would provide a much convenient solution to find module all dependencies, compared to obtaining and parsing all modules. In addition, to avoid causing problems in devices, for instance, falsely referring to modules in the wrong module-set, this document requires that the base modules and the augmentations be listed in the same module-set. The YANG library only provides the deviation list, without augmentations. With augmentations being more widely used and defined, and with use cases to automate network management, augmentations become essential information for clients to better understand the network management server module relationships. Thus, the YANG library should be extended to also provide the augmentation information.

As the demand for YANG-based telemetry arises, there is a need for real-time knowledge of a specific YANG module's dependency list when a specific YANG-Push notification for a given subscription is received. Some YANG-Push receivers will collect the information in advance of the telemetry collection, storing the entire module set for every single server who could be streaming data. However, this approach is not always practical in case of Configured Subscriptions where the YANG-Push receiver is not configuring the subscriptions itself and in case of UDP transport . See figure 1 in An Architecture for YANG-Push to Message Broker Integration for more details. This architecture relies on the information of YANG dependencies in this specification to solve the problem of missing YANG semantics when notifications are transformed or indexed in Time Series Database. Prior to the implementation of this specification, the method used for obtaining modules and finding module dependencies is to retrieve the full set of supported YANG modules from the network device, triggered by parsing the <subscription-started> message for each new YANG-Push subscription, because the YANG-push receiver would not know which YANG-Push publisher sends the subscribed YANG content until the first notification is received. By using the provided augmentedby information in this specification, the YANG-Push receiver can directly obtain the YANG reverse dependencies for the specific YANG module(s) in the subscription by querying the server, saving collection and processing time at the YANG-Push receiver, by querying dependencies only for the required modules, and therefore helping with the real-time aspects of network observability. Following is an example YANG-Push message of this use case received from within a subscription to YANG module "ietf-interfaces":

To correctly interpret the semantics of this message, both the "ietf-interfaces" and "ietf-ip" YANG modules are required. Knowing only that the subscribed YANG module is "ietf-interfaces" is therefore insufficient, but that is currently the only dependency information exposed by the subscription information. In this case, a mechanism is needed to discover all relevant dependency modules, especially reverse dependencies (refer to "ietf-ip" in this example) so that every YANG module referenced in the pushed data can be reliably identified.

Finding the YANG modules implemented by a network management server is paramount for configuring and monitoring the status of a network. However, since the inception of YANG the network industry has defined large number of YANG modules developed by SDOs, open-source communities, and network vendors. This heterogeneity of YANG modules, that vary from one network device/service model to another, makes the management of a multi-vendor network a big challenge for operators. . In this regard, a data catalog provides a registry of the datasets exposed by remote data sources for consumers to discover data of interest. Besides the location of the dataset (i.e., the data source), the data catalog registers additional metadata such as the data model (or schema) followed in the dataset or even related terms defined in a business glossary. Data catalog solutions typically implement collectors that ingest metadata from the data sources themselves and external metadata sources. For example, a Kafka Schema Registry is a metadata source that provides metadata about the data model followed by some data stored in a Kafka topic. In this sense, a YANG-enabled network device can be considered as another kind of data source, which the Data Catalog can pull metadata from. For instance, the data catalog can include a connector that fetches metadata about the YANG modules implemented by the network device. Combining this metadata with others such as the business concept "interface", would enable data consumers to discover which datasets related to the concept "interface" are exposed by the network device. Network devices that implement YANG library expose metadata about which YANG modules are implemented, and which are only imported. However, what a data consumer needs at the end are the YANG modules implemented by the device, hence, the combination of implemented YANG modules with other YANG modules that might deviate or augment the formers. Consider a network device that implements the "ietf-interfaces" module and the "ietf-ip" module , where the latter augments the former. For a data catalog to collect this metadata, a connector would retrieve YANG library data from the target device. However, the current version of YANG library would not satisfy the use case as it would tell that the device implements both "ietf-interfaces" and "ietf-ip" modules, but will miss the augment dependency between them. A workaround is in combination with the YANG library data to additionally obtain both YANG modules and process them to discover that there is an augment dependency. This adds extra burden on the connector, which is forced to combine multiple metadata collection mechanisms. This process could be softened by extending YANG library to also capture augment dependencies, similarly to deviation dependencies.

The following is the YANG tree diagram for module "ietf-yang-library-augmentedby".

../../yanglib:module/name augment /yanglib:modules-state/yanglib:module: +--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 list "augmented-by" indicates by which modules that the current module is being directly augmented. The "yang-library/modules-state" is augmented despite its "deprecated" state to cope with the situation when container "modules-state" is used for compatibility reason with ietf-yang-library defined in . Both the NMDA and non-NMDA compliant additions are defined in the same YANG module for simplicity for users and implementors. For the scope of "augmented-by", this document only considers the direct augmentation relationship. The recursive result of augmentation or transitive dependency for module specified along the XPath, is out of the scope of this draft. Section 4.2 has given the implementation instructions.

This YANG module imports and augments the "ietf-yang-library" .

file "ietf-yang-library-augmentedby@2025-05-28.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: WG List: Authors: Zhuoyao Lin Benoit Claise Ignacio Dominguez Martinez-Casanueva "; description "This module augments the ietf-yang-library defined in RFC8525 to provide not only the deviation list, but also the augmented-by list, in order to give sufficient information about the YANG modules reverse dependency. It facilitates the process of obtaining the entire 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 XXXX; see the RFC itself for full legal notices."; // RFC Ed.: replace XXXX/YYYY with actual RFC number and remove // this note // replace 'date-revision' with the module publication date // the format is (YYYY-MM-DD) revision 2025-05-28 { description "Initial revision."; reference "RFC XXXX: Augmented-by Addition to the YANG Library (Note to the RFC-Editor: Please replace this with RFC plus the RFC number when this document can be published.)"; } grouping augmented-by { description "Provides augmented-by leaf-list from module info with the module-augmented-by grouping"; 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:yang-library/yanglib:module-set/yanglib:module" { description "Adds Augmented-by leaf-list to the list of modules of a module set"; uses augmented-by; } augment "/yanglib:modules-state/yanglib:module" { status deprecated; description "Adds Augmented-by leaf-list to the list of modules of a module set"; uses augmented-by; } } ]]>

This section explains the scope of augmented-by. The "augmented-by" leaf-list should only consider those YANG modules that directly augment the YANG module in question in the "ietf-yang-library", 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 to. Only the direct parent module of the target node is augmented, and the rest of the parent modules defined in the schema tree are only indirect dependencies but not augmented modules. (Refer to "Target node" definition in Section 7.17 of ) In the case when a YANG application requires recursive dependency or specific schema tree dependency, the search logic should be implemented by the application itself.

This section provides two module-set examples and their corresponding ietf-yang-library-augmentedby query results to explain the definition of "direct augment" stated in Section 4.2.1. The two scenarios are provided with the same three YANG modules (Module A, B, and C) defined in the module-set, however the relationships among them are different. All three YANG modules are defined in the same module-set name 'module-set1' to be able to augment or be augmented by the others. Otherwise, the YANG validation should fail.

Relationships among Module A, Module B and Module C in this example are following:

• 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:

file "example_yanglib_result1.xml" 1 module-set1 A 2024-02-29 urn:ietf:params:xml:ns:yang:A B C B 2024-02-29 urn:ietf:params:xml:ns:yang:B C 2024-02-29 urn:ietf:params:xml:ns:yang:C 0 ]]>

In this example, both Module B and Module C directly augment the container "foo-a". Therefore, both B and C are listed as "augmented-by" modules for Module A.

Relationships among Module A, Module B and Module C in this example are following:

• 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 is:

file "example_yanglib_result2.xml" 1 module-set1 A 2025-06-18 urn:ietf:params:xml:ns:yang:A B B 2025-06-18 urn:ietf:params:xml:ns:yang:B C C 2025-06-18 urn:ietf:params:xml:ns:yang:C 0 ]]>

In this example, although the augment XPath statement used by Module C is rooted from the container "foo-a" defined in Module A, the node that Module C directly augments is the container "foo-b" defined in Module B. As a result, Module C is not considered to directly augment Module A and therefore does not appear in the "augmented-by" leaf-list of Module A. Only Module B, which directly augments the container "foo-a", is listed as an "augmented-by" module for Module A.

With the implementation of augmented-by, the base modules and the augmented-by modules require to be listed in the same module-set. Note that the reverse dependency will increase the size of the ietf-yang-library instance on the server. Also, the ietf-yang-library instance, and therefore the augmented-by, should be updated when new YANG modules are onboarded". A YANG example with the expected augmented-by result is provided in Section 4.2.2.

Note to the RFC-Editor: Please remove this section before publishing.

Zhuoyao Lin did the prototype implementation of the augmented-by list feature of this draft and demonstrated it based on Netopeer2 in IETF 119 Hackathon. Netopeer2 is a NETCONF server & client implementation developed by CESNET. Source code is here: . The actual feature is implemented by extending the libyang and sysrepo which are the base libraries for Netopeer2 to support populating the augmented-by list.

Zhuoyao Lin did a docker image of netopeer2 that integrates the augmented-by feauture in sysrepo and libyang. The result is presented at IETF 120 hackathon. The source code can be obtained here:

Zhuoyao Lin did an implementation of find-dependency based on the ietf-yang-library with augmented-by feature in the YANG-Push message parser library libyangpush. The result is presented in IETF 120 hackathon. The source code can be obtained here:

This section introduced the device implementations status of this document from vendors like Huawei, Cisco, 6Wind. The list of Router Images supporting (upcoming and already implemented) the ietf-yang-library-augmentedby YANG module proposed in this document is following:

• Huawei VRP R025C00 for NE8000 and NE40 (2025-10-15).
• Cisco IOS XR 25.3.1 (2025-08-31).
• Huawei VRP R024C10 for MA5800T-X17 (2025-06-30).
• 6WIND VSR 3.10.

This section follows the guidelines in Section 3.7 of . The "ietf-yang-library-augmentedby" YANG module defines a data model that is designed to be accessed via YANG-based management protocols, such as NETCONF and RESTCONF . These YANG-based management protocols require the use of a secure transport layer (e.g., SSH , TLS , and QUIC ) and require mutual authentication. The Network Configuration Access Control Model (NACM) provides a 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 these readable data nodes may be considered sensitive or vulnerable in some network environments. It is important to control read access (e.g., via get, get-config, or notification) to these data nodes. Specifically, the following readable data nodes contain potentially sensitive information: /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. Therefore, access control policies SHOULD restrict read access to authorized users only. There are no RPCs or action operations defined in this module. Therefore, there are no particularly sensitive RPC or action operations. This module uses groupings from the ietf-yang-library YANG module defined in , 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 , the Section 6 Security Considerations of apply here as well. Refer to that Section for information as to which nodes may be considered sensitive or vulnerable in network environments.

This document registers one URI in the "IETF XML Registry" . Following the format in , the following registration has been made. 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. This document registers one YANG module in the "YANG Module Names" registry Name: ietf-yang-library-augmentedby Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-library-augmentedby Prefix: yanglib-aug Reference: RFC-to-be (Note to the RFC-Editor: Please replace this with RFC plus the RFC number when this document can be published.) Maintained by IANA: N

BSD-3-Clause license BSD-3-Clause license BSD-3-Clause license Swisscom This document describes the motivation and architecture of a native YANG-Push notifications and YANG Schema integration into Apache Kafka Message Broker and YANG Schema Registry. Universidad Politecnica de Madrid, Telefonica I+D Universidad Politecnica de Madrid Universidad Politecnica de Madrid Universidad Politecnica de Madrid Telefonica I+D IEEE Communications Magazine

The following is the YANG tree diagram for module ietf-yang-library after adding augmentation from module ietf-yang-library-augmentedby. The RPCs and notifications are included as well.

../../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 +--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 ]]>

Note to the RFC-Editor: Please remove this section before publishing.

The list name has been updated from "augmentation" to "augmented-by", in order to represent the usage clearly. The leafref has been changed from absolute path "/yanglib:yang-libraray/yanglib:module-set/yanglib:module/yanglib:name" to relative path "../../yanglib:module/yanglib:name". The YANG validation in the appendix B shows that this path can work as expected. Section 5 Implementation and section 6 Changes has been added.

Updated the Use case content in Section 3.1. Add explanation: the scope of use case "Data Mesh Architecture" is limited to configured subscription. Updated Implementation status content.

Updated affiliations Update content of Section 3.1 Data Mesh use case. Explain the limitation of applying get-all-schemas solution under the background of using UDP-notif of configured subscription, and how the feature proposed in the draft can improve the solution. Full review of document. Nits and refinement of sections.

Rewrite Section 2 Motivation. Update Section 6 Changes's subsection title. Update the Section 7 security consideration and section 8 IANA Considerations. Added in the appendix the Impact Analysis of ietf-yang-library and proposal for the RFC8525bis draft.

Resubmitted the draft name from: draft-lincla-netconf-yang-library-augmentedby-02 to: draft-ietf-netconf-yang-library-augmentedby-00

Correct the yanglint validation invalid example. Updated the explaination to the yanglint validation example principle. Delete Section "ietf-yang-library Impact Analysis, as an evaluation for RFC8525bis". The idea of updating the RFC8525 is paused.

Update and rephrase the Introduction section. Add Section 4.2 Implementation Instructions. Address in Section 4.2.1 that the definition of "augmented-by" only consider the direct augment. A YANG example for explaining this purpose has been put into Section 4.2.2. Draft refinement. Reference update.

Merge review comment from Thomas.

Update module content ietf-yang-library-augmentedby: Organise the augmentation content to grouping; Add augmentation to modules-state container. Appendix B is deleted.

Update ietf-yang-library-augmentedby module revision.

Merged Jean, Thomas and Alex's editorial feedback. Merged Andy's review. Changed contents are listed following:

• Section 1: Rewrite introduction. Added definition for 'reverse dependency'. Avoid possible misleading expression about reverse dependency and external dependency.
• Section 2: Editorial Changes.
• Section 3: Merged editorial feedback from Alex, mainly for Section 3.1.
• Section 4: Move the full tree diagram to appendix A; Correct the YANG file date; Update the description statement in YANG module to provide implementation instructions information; Improve the text of implementation instruction and the direct augment example.
• Appendix: For Appendix A: The ietf-yang-library full tree view has been moved to Appendix A. For Appendix B: The yanglint validation example has been moved from Appendix A to Appendix B. The invalid yanglint example has been removed. Set up texted has been added before the validation example.

Change the reference in IANA Consideration to 'RFC-to-be'.

Merged Per's review and comments.

Updated YANG module's line length and spacing. Corrected the "author" to "authors". Corrected typo. Added section 5 Operational Considerations to explain that the base and augmentedby modules should be in the same module-set.

Corrected the typo of 'requires'. Moved RFC8525 reference to Nomative References section.

Mentioned in the title that this document updates RFC8525.

Updated draft according to the AD review.

Resolving nits.

Improved the examples, based on the designated expert review.

Address Med's DISCUSS.

The author would like 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.