Guidelines for YANG Example Validation and Coverage Analysis in IETF Documents
draft-cardona-claise-netmod-yang-coverage-00

Network Modeling                                              C. Cardona
Internet-Draft                                                       NTT
Intended status: Informational                                 B. Claise
Expires: 7 January 2027                          Everything OPS & Arrcus
                                                             6 July 2026

  Guidelines for YANG Example Validation and Coverage Analysis in IETF
                               Documents
              draft-cardona-claise-netmod-yang-coverage-00

Abstract

   This document defines guidelines for including YANG example instances
   in IETF documents in a way that enables automatic extraction and
   validation.  It introduces the concept of YANG module "coverage" to
   measure how thoroughly example instances exercise a YANG module's
   data nodes.  By standardizing how YANG examples are included,
   validated, and measured for coverage, these guidelines help authors
   catch errors before publication and give reviewers and implementers
   greater confidence that the examples in a specification are correct
   and cover a sufficient range of scenarios - ultimately making the
   underlying data models easier to implement and use.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 7 January 2027.

Copyright Notice

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

Cardona & Claise         Expires 7 January 2027                 [Page 1]
Internet-Draft            YANG Module Coverage                 July 2026

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Including YANG Example Instances in IETF Documents  . . . . .   3
     2.1.  Types of Example Validation . . . . . . . . . . . . . . .   5
       2.1.1.  Simple Validation Examples  . . . . . . . . . . . . .   5
       2.1.2.  Complex Examples with External References . . . . . .   6
     2.2.  Including Auxiliary YANG Modules for Examples . . . . . .   6
   3.  YANG Module Coverage by Examples  . . . . . . . . . . . . . .   8
     3.1.  Coverage Example  . . . . . . . . . . . . . . . . . . . .   9
     3.2.  Coverage Across Multiple Documents  . . . . . . . . . . .  11
   4.  Open Issues and Future Work . . . . . . . . . . . . . . . . .  11
   5.  Implementation  . . . . . . . . . . . . . . . . . . . . . . .  12
   6.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .  13
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .  13
   10. Informative References  . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   Although the YANG data modeling language has been in use for over a
   decade, there remains a lack of tooling to help YANG module authors
   analyze and validate their YANG modules and example instances.
   People defining or evaluating YANG modules have limited guidance on
   how to include, extract, test, and evaluate the impact of example
   data for those modules.  Example data instances are vital to
   illustrate how a module is intended to be used.  [RFC9907] provides
   guidelines for authors and reviewers of documents containing YANG
   data models, including recommendations for usage examples and
   validation of valid data instances.  The YANG data modeling language
   itself is specified in [RFC7950].  However, gaps still exist in
   defining conventions and tools that can automatically extract
   examples, validate them, and give authors feedback on what they might
   be missing in their modules.

Cardona & Claise         Expires 7 January 2027                 [Page 2]
Internet-Draft            YANG Module Coverage                 July 2026

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

   The objective of this document is to define guidelines that enable
   the development of tools which, given one or more IETF documents
   (RFCs or drafts), can extract YANG module examples, validate that
   they are correct, and analyze whether they sufficiently cover the
   module.  To achieve this, we address two main aspects:

   *  Guidelines for Including YANG Examples in RFCs: A clear method for
      authors to include example data instances of YANG modules in IETF
      documents in a way that tools can automatically extract and
      validate them.  In addition, we outline how tools can perform this
      extraction and validation, and we propose a method to include
      extra YANG modules (when necessary) for validating more complex
      examples without affecting the main normative content.

   *  Definition of YANG Module "Coverage": A new concept to measure how
      much of a YANG module's data nodes are exercised by the example
      instances in a document.  By analyzing the examples, a tool can
      inform authors which parts of their YANG module are covered and
      which are still missing from the examples.  A proof-of-concept
      implementation for computing such coverage is also considered.

   Scope: The proposals in this document focus on typical use cases.  It
   is expected that proof-of-concept tools will confirm the viability of
   these methods for moderately complex examples as this document
   progresses.  If such automatic validation proves infeasible in
   practice, the approach may need adjustment.  Extremely complex
   example scenarios (e.g., those involving schema mount or highly
   dynamic state) are outside the current scope and could be addressed
   in future work.

2.  Including YANG Example Instances in IETF Documents

   When authors include example YANG instances in an RFC or Internet-
   Draft, those example instances are RECOMMENDED to be formatted in a
   way that allows automatic extraction and validation by tools.

   Specifically, example instances SHOULD be enclosed as code blocks
   using the CODE BEGINS / CODE ENDS convention in the rendered
   document.  In RFCXML, this can be achieved with a sourcecode element
   that uses a name attribute and the markers attribute.  They should be
   given a file name that clearly identifies them as examples, analogous
   to how YANG modules are named (see [RFC9907]).  We propose that the

Cardona & Claise         Expires 7 January 2027                 [Page 3]
Internet-Draft            YANG Module Coverage                 July 2026

   name of valid example instances start with the prefix `yang/examples/
   valid-` and end with `.xml` for XML instances or `.json` for JSON
   instances.  This naming convention makes it easy for tools to
   identify which code snippets are YANG instance examples that can be
   parsed and validated.  The intent is not to replace the example-
   validation guidance in [RFC9907], but to make that guidance easier to
   apply automatically.  This convention tries to align itself with the
   repository layout used by the "Internet-Draft with YANG Modules"
   template [I-D-WITH-YANG-TEMPLATE].

   Each example file name SHOULD be unique within a document (and
   ideally unique across related documents being analyzed together).
   Tools may complain or error out if they encounter duplicate example
   file names, since that could indicate conflicting or repeated
   content.  For example, an XML instance might be included as:

   <CODE BEGINS> file "yang/examples/valid-interface-config.xml"
   <?xml version="1.0" encoding="UTF-8"?>
   <data> ... </data>
   <CODE ENDS>

   And a JSON instance as:

   <CODE BEGINS> file "yang/examples/valid-interface-config.json"
   {
     "interface": { ... }
   }
   <CODE ENDS>

   By following this approach, a tool can scan the RFCXML source or the
   rendered document for code blocks whose file names are under "yang/
   examples/", start with "valid-", and end in ".xml" or ".json",
   extract their contents, and validate them against the appropriate
   YANG modules.

Cardona & Claise         Expires 7 January 2027                 [Page 4]
Internet-Draft            YANG Module Coverage                 July 2026

   In cases where an included code snippet is not meant to represent a
   valid YANG instance (for instance, it might be pseudocode, a partial
   fragment, or intentionally invalid to illustrate an error), the
   author can indicate this so that automated validators skip it.  For
   example, an author might choose not to use the CODE BEGINS/CODE ENDS
   markers, might not place the snippet under "yang/examples/", or might
   not use the "valid-" prefix for such a snippet.  Without the markers
   or filename convention, the tool will know not to treat that snippet
   as a YANG instance example to be validated.  An author could also
   include an explicit note in the text indicating that a given snippet
   is not for validation.  Using these conventions strikes a balance
   between making examples machine-checkable and allowing flexibility
   for authors to include non-valid illustrative snippets when
   necessary.

2.1.  Types of Example Validation

   Not all example instances are the same in terms of validation.  Many
   YANG examples in documentation are simple and only involve the module
   defined in the document, but in more complex scenarios an example
   might span multiple modules or need knowledge of deviations,
   features, or other context.  For the latter, wrapping the example in
   an instance data file format (defined by [RFC9195]) can make explicit
   which modules and context are in use.  This approach can handle more
   complicated example validation at the cost of a bit more verbosity.
   (If a given example scenario is too complex to easily capture even
   with the instance-data file format - for example, requiring extensive
   setup or dynamic state - it is considered out of scope for automatic
   validation in this document.)  We distinguish between two categories
   of examples for validation purposes:

2.1.1.  Simple Validation Examples

   These are straightforward examples that instantiate YANG modules
   defined in the same document, with a self-contained context.  An
   extraction tool can load the YANG module(s) defined in the document
   (plus any standard modules they import) and then validate the example
   instance against those modules.  For instance, if a draft defines a
   YANG module example-interfaces and provides a small XML snippet
   configuring an interface, the tool will use the example-interfaces
   module (and any of its dependencies) to verify that the XML conforms
   to the schema.  In general, simple examples illustrate how to use the
   module(s) in the draft and can be validated with minimal additional
   information beyond what the document itself provides.

Cardona & Claise         Expires 7 January 2027                 [Page 5]
Internet-Draft            YANG Module Coverage                 July 2026

2.1.2.  Complex Examples with External References

   These are examples that require additional context or external
   modules beyond those defined in the current document.  For example,
   an instance data set may involve multiple modules (perhaps a module
   from this draft plus some from other RFCs), or it might describe
   operational state data that requires a specific datastore context or
   feature set.  For such cases, we propose that the example be
   presented as a self-contained YANG instance data file using the
   standard format defined in [RFC9195] (the YANG Instance Data File
   Format).  In practice, this means the example should be wrapped in
   the instance-data-set structure which includes the necessary metadata
   (such as module names, revisions, feature toggle states, and target
   datastore) for validation.

   For an XML-formatted complex example, the first element of the
   snippet should be <instance-data-set
   xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-instance-data">, with
   the content formatted according to [RFC9195].  Inside this element,
   sub-elements specify what YANG content schema the instance data
   conforms to (including module names, revision dates, features,
   deviations, and the intended datastore).  Similarly, for a JSON-
   formatted complex example, the top-level JSON object should have a
   single key "ietf-yang-instance-data:instance-data-set", whose value
   is an object providing the same kind of metadata and the actual data
   set.  By using the [RFC9195] instance-data-set wrapper, all the
   information needed to validate the instance is included within the
   text itself.  A validation tool like yanglint (with appropriate
   support for [RFC9195]) can read the instance-data-set, automatically
   load the indicated modules and their revisions, apply any stated
   deviations or feature enables, and then verify the embedded data
   content against the assembled schema.  Note that if a tool detects
   that an example instance uses the [RFC9195] instance data format, it
   will attempt to validate it accordingly - and the example instance
   will fail validation if it does not conform to the declared schema or
   constraints.

2.2.  Including Auxiliary YANG Modules for Examples

   Sometimes an example instance cannot be validated or understood
   without additional YANG definitions that are not part of the main
   module in the document.  A common case is the use of YANG deviations
   or vendor-specific augmentations to adapt a base module.  In
   principle, deviations are meant to be extraordinary measures (and
   their use is discouraged in final standards), but in practice they
   are sometimes used in industry deployments.

Cardona & Claise         Expires 7 January 2027                 [Page 6]
Internet-Draft            YANG Module Coverage                 July 2026

   To illustrate how a deviation or augmentation affects the data, an
   RFC might need to include a small auxiliary YANG module (for example,
   a module that contains deviation statements targeting the base
   module) purely for use in the example validation.  The challenge is
   to do this without confusing readers or tools and without
   "contaminating" the main normative content of the document.  We
   propose the following guidelines for including such auxiliary YANG
   modules in examples:

   *  Keep Auxiliary Modules Separate: Include the auxiliary module in a
      way that makes it clear that it is not a normative YANG module
      from the document.  This can be done with a dedicated directory
      (e.g. the file name starts with `auxiliary_modules/`), or a local
      meaninful extension.  Any example that requires this auxiliary
      module would need to reference reference it by its full path when
      running the validation tool.

   *  Clearly Identify the Module as Non-Normative: The auxiliary module
      should be clearly identified as an example-only, non-normative
      module.  This can be achieved through both its naming and its
      content.  For instance, the file name can include words like
      "example" or "dev" to signal its purpose.  In the module source
      itself, use a module name and namespace that indicate it is not an
      official module.  For example, use a namespace URI containing
      "example.com" or similar, and perhaps a module name ending in
      -example or with a clearly indicative name.

   *  Explain in the Narrative: In the text surrounding the code,
      explicitly state that this module is an auxiliary construct
      provided for the sake of the example.  For instance: "The
      following YANG module is an example showing how a deviation could
      be used for this scenario; it is not a normative part of this
      specification."  This clarification is important for human readers
      and reviewers to avoid any confusion.

   By following these practices, authors can include necessary YANG
   deviations or supplemental modules to support their examples while
   making it clear that these are not part of the official data model
   being defined.  Tools that extract and compile YANG modules from the
   document can be instructed to either ignore these example-only
   modules or handle them separately.  For example, a tool might compile
   them only in the context of validating the corresponding example, and
   not raise an error about their presence or treat them as missing
   normative modules in the draft.

Cardona & Claise         Expires 7 January 2027                 [Page 7]
Internet-Draft            YANG Module Coverage                 July 2026

3.  YANG Module Coverage by Examples

   Providing examples in YANG module documents is not just helpful for
   readers, but can also improve the quality of the module itself.  We
   introduce the concept of YANG module coverage as a way to measure how
   thoroughly the provided examples exercise the data model.

   By analogy to code coverage in software testing (which checks what
   fraction of code is executed by tests), YANG module coverage looks at
   what fraction of a module's data nodes are present in at least one of
   the example instances.  For the baseline metric, coverage is defined
   over terminal data nodes, that is, leaf and leaf-list nodes from the
   YANG module that have a value in one or more example instances.  A
   simple quantitative metric could be the percentage of the module's
   leaf and leaf-list nodes that appear in at least one example.

   For instance, if a YANG module defines 100 configurable or state leaf
   nodes, and the examples collectively include 45 of those leaves, one
   could say the example coverage is 45%. This number, while not telling
   the whole story, gives an indication of how much of the module's
   functionality is demonstrated by the examples.  Low coverage might
   suggest that important parts of the module are never shown in any
   example.  This could mean those parts are either less relevant or
   simply that the document might benefit from additional examples to
   cover them.

   Probably more helpful than the coverage percentage, we can also
   define an "uncovered-node tree" - essentially a view of the data
   model highlighting the nodes that were not covered by any example.
   This is perhaps the most direct way of showing the authors which
   portions of their module remain unused in the examples.  For example,
   a tool could output a tree or list of all leaf and leaf-list nodes
   not present in any example instance, indicating potential gaps in
   example coverage.

   This kind of feedback can help authors identify gaps and improve
   their documents.  If a particular feature or branch of the module has
   no example, the authors might choose to add one for completeness or
   clarity.  In some cases, it might reveal that certain parts of the
   module are hard to exemplify or not yet implemented, which could
   prompt re-thinking that part of the design or at least adding an
   explanation for why it's not covered by any example.

Cardona & Claise         Expires 7 January 2027                 [Page 8]
Internet-Draft            YANG Module Coverage                 July 2026

   Coverage works directly on the data nodes from the YANG module.  It
   should be as simple as possible, therefore, we will consider that any
   data leaf or leaf-list under a list is covered if there is at least
   an example with an instance of the list that includes it.  That is,
   for a list with 2 different leaves, one leaf covered under one key
   and another under another one will still yield a 100% coverage of the
   list leaves.

3.1.  Coverage Example

   Consider this simple YANG module:

   <CODE BEGINS> file "example-device@2026-06-25.yang"
   module example-device {
     yang-version 1.1;
     namespace "http://example.com/device";
     prefix "dev";

     description
       "This is a non-normative example module, provided only to
        illustrate coverage analysis in this document.";

     revision 2026-06-25 {
       description "Initial example revision.";
     }

     container device {
       description "Top-level device configuration.";

       leaf hostname {
         type string;
         description "The device hostname.";
       }
       leaf location {
         type string;
         description "Physical location of the device.";
       }
       leaf admin-state {
         type boolean;
         description "Administrative state of the device.";
       }

       list interface {
         key "name";
         description "List of device interfaces.";

         leaf name {
           type string;

Cardona & Claise         Expires 7 January 2027                 [Page 9]
Internet-Draft            YANG Module Coverage                 July 2026

           description "Interface name; the list key.";
         }
         leaf enabled {
           type boolean;
           description "Whether the interface is enabled.";
         }
         leaf other {
           type boolean;
           description "An additional example leaf.";
         }
       }
     }
   }
   <CODE ENDS>

   And this example instance:

   <CODE BEGINS> file "yang/examples/valid-device-config.xml"
   <device xmlns="http://example.com/device">
     <hostname>router1</hostname>
     <interface>
       <name>eth0</name>
       <enabled>true</enabled>
     </interface>
   </device>
   <CODE ENDS>

   Coverage analysis shows:

   *  Total terminal data nodes: 6 (hostname, location, admin-state,
      interface/name, interface/enabled, interface/other)

   *  Covered nodes: 3 (hostname, interface/name, interface/enabled)

   *  Coverage percentage: 50%

   Uncovered-node tree (missing nodes):

   device
   - location
   - admin-state
   - interface
     - other

                                  Figure 1

   This analysis helps authors identify that the 'location' and 'admin-
   state' leaves need examples.

Cardona & Claise         Expires 7 January 2027                [Page 10]
Internet-Draft            YANG Module Coverage                 July 2026

3.2.  Coverage Across Multiple Documents

   It is common that a YANG module defined in one document might be
   used, extended, or exemplified in another document.  Examples could
   be spread across multiple RFCs or drafts (for instance, a base YANG
   module in an RFC and a usage guide in a separate draft that provides
   additional examples).  While our primary focus is on coverage within
   a single document's scope (i.e. how well the examples in this
   document cover this document's module), one could imagine tooling
   that aggregates examples from multiple sources for a more holistic
   coverage analysis.  For example, if module A is defined in RFC X, and
   RFC Y (perhaps a companion or an applicability statement) provides
   additional examples for module A, a combined coverage analysis across
   X and Y would give a better picture of how module A is covered in
   total.  We will strive to define approaches that enable tooling to do
   this kind of multi-document coverage assessment automatically in the
   future.

   For the concept of YANG packages [I-D.ietf-netmod-yang-packages], the
   coverage across the entire package might be of interest.

   For the newly created ONSEN Working Group, the coverage across
   (service) abstractions might be of interest.

4.  Open Issues and Future Work

   The baseline metric in this document is intentionally limited to leaf
   and leaf-list coverage.  Feedback received on version -00 identified
   additional useful information that is not naturally represented by
   the baseline uncovered-node tree.

   *  Union member types: If a covered leaf is of type union, a future
      version can define how to report which union member types were
      exercised by the example instances.  The leaf itself may already
      be covered, while only some of its possible member types were
      used.  Reporting this properly requires an uncovered tree format
      beyond the YANG tree definition from [RFC8340].

   *  Enumeration values: If a covered leaf is of type enumeration, a
      future version can define whether tools should report which
      enumeration values were exercised by the example instances.
      Similar to the case of Union member types, we will need to expand
      the definition of YANG tree from [RFC8340] to show these values.

Cardona & Claise         Expires 7 January 2027                [Page 11]
Internet-Draft            YANG Module Coverage                 July 2026

   *  Presence containers: A future version can define whether
      instantiating a presence container counts as coverage
      independently from the leaves below it.  This is a separate
      question from the baseline leaf and leaf-list metric because a
      presence container can carry meaning by existing.

   *  Groupings: The proof-of-concept implementation already handles the
      schema nodes created by uses of a grouping.  Further work is
      needed to decide whether grouping-specific metrics are useful, and
      how they should be reported without confusing abstract grouping
      definitions with instantiated schema nodes.

   *  Modules without data nodes: A future version can define clearer
      reporting for modules that primarily contain groupings, typedefs,
      identities, extensions, RPCs, actions, or notifications, where the
      baseline data-node coverage metric may not apply.

5.  Implementation

   A proof-of-concept implementation has been developed in the yangson-
   coverage repository [YANGSON-COVERAGE].  The implementation uses
   Yangson [YANGSON] as a library for loading YANG modules and
   validating instance data, and then implements the coverage logic
   described in this document.

   Yangson already exposes validation counters for schema nodes and can
   print a complete schema tree annotated with those counters.  This is
   useful input, but it is not the report format defined here.  The
   proof of concept tracks covered leaves across validated examples and
   generates the uncovered-node tree described in this document: covered
   terminal nodes are removed, and parent nodes are kept only as
   context.

   The proof of concept also provides a command-line interface to reset
   coverage state, validate examples while accumulating coverage, and
   print the uncovered-node report.  It includes initial support for
   grouping-level reporting, while the exact grouping metrics remain
   future work.

   Other related tooling includes yanglint [YANGLINT], example
   validation scripts such as yang-validation [YANG-VALIDATION], the
   "Internet-Draft with YANG Modules" template [I-D-WITH-YANG-TEMPLATE],
   and the associated I-D-with-yang-tools repository
   [I-D-WITH-YANG-TOOLS].  These tools and templates support validation
   of YANG modules, tree generation, and validation of examples.

Cardona & Claise         Expires 7 January 2027                [Page 12]
Internet-Draft            YANG Module Coverage                 July 2026

6.  Conclusion

   By standardizing how YANG examples are included and validated, we
   make it easier for implementers and reviewers to trust that the
   examples in a specification are correct and that a sufficient range
   of scenarios is covered.  The concept of YANG module coverage, while
   exploratory, can further encourage authors to include more
   comprehensive examples and help pinpoint which parts of a data model
   might need additional illustration.  Together, these measures aim to
   improve the overall quality and usability of YANG modules in IETF
   documents.

   Ultimately, the success of these proposals will depend on tool
   support.  As a next step, developing proof-of-concept tools or
   integrations (for example, enhancements to existing YANG validators
   like yanglint, or new scripts to extract and analyze examples) will
   be crucial.  If moderately complex examples can be automatically
   extracted, validated, and measured for coverage with such tools, it
   will validate the approach.  On the other hand, if significant
   obstacles arise during implementation, the recommendations in this
   document may need to be refined.  Our hope is that these initial
   guidelines spark discussion and experimentation, leading to more
   robust support for YANG examples and better validation practices in
   the near future.

7.  IANA Considerations

   This document has no IANA actions.

8.  Security Considerations

   This document defines guidelines for including and validating YANG
   examples in IETF documents.  The recommendations do not introduce new
   security risks.  However, implementers of validation tools should be
   aware of potential security considerations when processing example
   data, auxiliary modules, or repository contents from untrusted
   sources, such as denial of service attacks through maliciously
   crafted large or complex examples.

9.  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>.

Cardona & Claise         Expires 7 January 2027                [Page 13]
Internet-Draft            YANG Module Coverage                 July 2026

   [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>.

   [RFC9195]  Lengyel, B. and B. Claise, "A File Format for YANG
              Instance Data", RFC 9195, DOI 10.17487/RFC9195, February
              2022, <https://www.rfc-editor.org/info/rfc9195>.

   [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>.

10.  Informative References

   [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>.

   [YANGSON]  CZ.NIC, "Yangson Documentation",
              <https://yangson.labs.nic.cz/>.

   [YANGLINT] CESNET, "libyang and yanglint Repository",
              <https://github.com/CESNET/libyang>.

   [I-D.ietf-netmod-yang-packages]
              Wilton, R., Rahman, R., Clarke, J., and J. Sterne, "YANG
              Packages", Work in Progress, Internet-Draft, draft-ietf-
              netmod-yang-packages-07, 2 March 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
              yang-packages-07>.

   [I-D-WITH-YANG-TEMPLATE]
              IETF OPS AD, ""Internet-Draft with YANG Modules" Template
              Repository",
              <https://github.com/IETF-OPS-AD/I-D-with-yang-template>.

   [I-D-WITH-YANG-TOOLS]
              IETF OPS AD, "I-D-with-yang-tools Repository",
              <https://github.com/IETF-OPS-AD/I-D-with-yang-tools>.

   [YANG-VALIDATION]
              Linutronix, "yang-validation Repository",
              <https://github.com/Linutronix/yang-validation>.

Cardona & Claise         Expires 7 January 2027                [Page 14]
Internet-Draft            YANG Module Coverage                 July 2026

   [YANGSON-COVERAGE]
              Camilo Cardona-Benoit Claise, "yang-coverage proof-of-
              concept Repository",
              <https://github.com/jccardonar/yangson-coverage/>.

Authors' Addresses

   Camilo Cardona
   NTT
   164-168, Carrer de Numancia
   08029 Barcelona Catalonia
   Spain
   Email: camilo@gin.ntt.net

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

Cardona & Claise         Expires 7 January 2027                [Page 15]