A Data Manifest for Contextualized Telemetry Data

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 4 September 2025.¶

Copyright Notice

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

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

Network platforms use Model-driven Telemetry (MDT), such as YANG-Push [RFC8641], to continuously stream information, including both counters and state information.¶

This document specifies what needs to be kept as metadata to ensure that the collected data can still be interpreted correctly throughout the collection and network analytics toolchain. When streaming YANG-structured data with YANG-Push [RFC8641], there is a semantic definition in the corresponding YANG module definition. This is the semantic information for the collected data nodes: While this semantic is absolutely required to correctly decode and interpret the data, understanding the network platform and collection environment contexts information is equally important to interpret the data.¶

One part of this information is the actual collection period, as opposed to the configured collection period. On some platforms, that period can be adjusted automatically by the platform, for instance to reduce the load incurred by sending the telemetry. To later exploit the collected data, getting this actual collection period is crucial. This document defines a YANG model augmenting the YANG-Push model [RFC8641] to expose the actual collection period in Section 4 .¶

This document introduces the data manifest, which is composed of two YANG data models, namely, the platform manifest and the data collection manifest, in order to keep the collected data exploitable by the data scientists and relevant tools.¶

The platform manifest contains information characterizing the platform streaming the telemetry information, while the data collection manifest contains the required information to characterize how and when the telemetry information was metered. The platform manifest is specified in Section 5. The data collection manifest is specified in Section 6.¶

The two proposed YANG modules for the data manifest do not expose any new information but rather define what should be exposed by a platform streaming or storing telemetry data. Some related YANG modules have been specified to retrieve the platform capabilities such as:¶

• "YANG Library" [RFC8525].¶
• "YANG Modules Describing Capabilities for Systems and Datastore Update Notifications" [RFC9196] for the platform capabilities regarding the production and export of telemetry data.¶
• [I-D.claise-netconf-metadata-for-collection], which is based on [RFC9196] to define the optimal settings to stream specific items (i.e., per path).¶

These related YANG modules are important to discover the capabilities before applying the telemetry configuration (such as on-change subscription). Some of their content is part of the context for the streamed data.¶

This document covers only metadata about the collection context for the telemetry. The collected data is likely to be transformed into usable indicators for the network. The list of such transformation operations applied to the data is often called data lineage. Supplying the data lineage for the computed indicators is out of scope of this document.¶

To retrieve the context in which a particular piece of data was collected, three elements are necessary: the time of data emission, the originating platform and the subscription through which the data arrived. The approach proposed in this document delegates the time retrieval to the database storing the collected telemetry and focusing on providing a way to match a platform and a subscription identifier to the collection context. This is consistent with most of the YANG modules for devices, which focus on describing the current state of the device, rather than the evolution of that state through time.¶

2. Terminology

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

Platform: equipment of the network able to produce telemetry.¶

Data manifest: The necessary data required to interpret a telemetry information.¶

Platform manifest: part of the data manifest that completely characterizes the platform producing the telemetry information¶

Data collection manifest: part of the data manifest that completely characterizes how and when the telemetry information was metered.¶

Datapoint: an instance of data collected via telemetry at a specific time.¶

Collector: software that receives the stream of telemetry.¶

3. Use Cases

4. The "ietf-yp-current-period" YANG module

As explained earlier, the collection period is crucial information for a posteriori interpretation of the collected telemetry. Some platforms will adjust the collection period depending on their capabilities and current load. The YANG module proposed in this section augments the "ietf-subscribed-notification" module to provide the "current-period" leaf. The value of this leaf indicates the current collection which might be different from the configured collection period.¶

Figure 1 contains the YANG tree diagram [RFC8340] of the "ietf-yp-current-period" module.¶

module: ietf-yp-current-period

  augment /sn:subscriptions/sn:subscription:
    +--rw current-period?   yp:centiseconds

The code of the "ietf-yp-current" YANG module is given below.¶

<CODE BEGINS> file "ietf-yp-current-period@2025-02-21.yang"

module ietf-yp-current-period {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-yp-current-period";
  prefix yp-cp;

  import ietf-subscribed-notifications {
    prefix sn;
    reference
      "RFC 8639: A YANG Data Model for Subscriptions to
       Event Notifications";
  }
  import ietf-yang-push {
    prefix yp;
    // RFC Ed.: remove revision-date, needed here because last
    // version on the server is not the ratified one
    revision-date 2019-09-09;
    reference
      "RFC 8641: Subscriptions to YANG Datastores.";
  }

  organization
    "IETF OPSAWG (Operations and Management Area) Working Group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/opsawg/>
     WG List:  <mailto:opsawg@ietf.org>
     Author:   Benoit Claise   <mailto:benoit.claise@huawei.com>
     Author:   Jean Quilbeuf   <mailto:jean.quilbeuf@huawei.com>
     Author:   Diego R. Lopez  <diego.r.lopez@telefonica.com>
     Author:   Ignacio Dominguez
     <ignacio.dominguezmartinez@telefonica.com>
     Author:   Thomas Graf     <thomas.graf@swisscom.com>";
  description
    "This module augments ietf-subscribed-notification and
     ietf-yang-push with the current-period statistics reporting the
     actual collection period, as opposed to the configured one.

     Copyright (c) 2025 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).
     This version of this YANG module is part of RFC XXXX; see the
     RFC itself for full legal notices.  ";

  revision 2025-02-21 {
    description
      "Initial revision";
    reference
      "RFC xxxx: A Data Manifest for Contextualized Telemetry Data";
  }

  augment "/sn:subscriptions/sn:subscription" {
    description
      "Adds current period statistics";
    leaf current-period {
      when '../yp:periodic';
      type yp:centiseconds;
      description
        "Period during two successive data collections, in the
         current state. Might differ from the configured period
         when the platform might increase the period
         automatically when it is overloaded.";
    }
  }
}


<CODE ENDS>

5. Platform Manifest

module: ietf-platform-manifest
  +--ro platforms
     +--ro platform* [id]
        +--ro id                  string
        +--ro name?               string
        +--ro vendor?             string
        +--ro vendor-pen?         uint32
        +--ro software-version?   string
        +--ro software-flavor?    string
        +--ro os-version?         string
        +--ro os-type?            string
        +--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 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

<CODE BEGINS> file "ietf-platform-manifest@2025-02-21.yang"

module ietf-platform-manifest {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-platform-manifest";
  prefix p-mf;

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

  organization
    "IETF OPSAWG (Operations and Management Area) Working Group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/opsawg/>
     WG List:  <mailto:opsawg@ietf.org>
     Author:   Benoit Claise   <mailto:benoit.claise@huawei.com>
     Author:   Jean Quilbeuf   <mailto:jean.quilbeuf@huawei.com>
     Author:   Diego R. Lopez  <diego.r.lopez@telefonica.com>
     Author:   Ignacio Dominguez
                          <ignacio.dominguezmartinez@telefonica.com>
     Author:   Thomas Graf     <thomas.graf@swisscom.com>";
  description
    "This module describes the platform information to be used as
     context of data collection from a given network element. The
     contents of this model must be streamed along with the data
     streamed from the network element so that the platform context
     of the data collection can be retrieved later.

     The data content of this model should not change except on
     upgrade or patching of the device.

     Copyright (c) 2022 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).
     This version of this YANG module is part of RFC XXXX; see the
     RFC itself for full legal notices.  ";

  revision 2025-02-21 {
    description
      "Initial revision";
    reference
      "RFC xxxx: A Data Manifest for Contextualized Telemetry Data";
  }

  grouping platform-details {
    description
      "This grouping contains the information about a particular
       platform, as stored in the YANG catalog.";
    leaf name {
      type string {
        length "1..1023";
      }
      description
        "Model of the platform from which data is collected.";
    }
    leaf vendor {
      type string {
        length "1..1023";
      }
      description
        "Organization that implements that platform.";
    }
    leaf vendor-pen {
      type uint32;
      description
        "Vendor's registered Private Enterprise Number";
      reference
        "RFC9371: Registration Procedures for Private Enterprise
         Numbers (PENs)";
    }
    leaf software-version {
      type string {
        length "1..1023";
      }
      description
        "Name of the version of software. With respect to most
         network device appliances, this will be the operating system
         version. But for other YANG module implementation, this
         would be a version of appliance software. Ultimately, this
         should correspond to a version string that will be
         recognizable by the consumers of the platform.";
    }
    leaf software-flavor {
      type string {
        length "1..1023";
      }
      description
        "A variation of a specific version where YANG model support
         may be different.  Depending on the vendor, this could be a
         license, additional software component, or a feature set.";
    }
    leaf os-version {
      type string {
        length "1..1023";
      }
      description
        "Version of the operating system using this module. This is
         primarily useful if the software implementing the module is
         an application that requires a specific operating system
         version.";
    }
    leaf os-type {
      type string {
        length "1..1023";
      }
      description
        "Type of the operating system using this module. This is
         primarily useful if the software implementing the module is
         an application that requires a specific operating system
         type.";
    }
  }

  container platforms {
    config false;
    description
      "Top container including all platforms in scope. If this model
       is hosted on a single device, it should contain a single entry
       in the list. At the network level, it should contain an entry
       for every monitored platform.";
    list platform {
      key "id";
      description
        "Contains information about the platform that allows
         identifying and understanding the individual data collection
         information.";
      leaf id {
        type string {
          length "1..1023";
        }
        description
          "Identifies a given platform on the network, for instance
           the 'sysName' of the platform. The 'id' has to be unique
           within the network scope at every point in time. The same
           id can point to different platform if they are not
           simultaneously part of the network, e.g., when a device
           associated to a particular id is replaced.";
      }
      uses platform-details;
      uses yanglib:yang-library-parameters;
    }
  }
}


<CODE ENDS>

6. Data Collection Manifest

module: example-collection-manifest
  +--ro data-collections
     +--mp data-collection* [platform-id]
        +--ro platform-id    -> /p-mf:platforms/p-mf:platform/p-mf:id
        +--ro streams/
        |  +--ro stream* [name]
        |     +--ro name           string
        |     +--ro description?   string
        +--ro filters/
        |  +--ro stream-filter* [name]
        |  |  +--ro name             string
        |  |  +--ro (filter-spec)?
        |  |     +--:(stream-subtree-filter)
        |  |     +--:(stream-xpath-filter)
        |  |        +--ro stream-xpath-filter?   yang:xpath1.0
        |  |                {xpath}?
        |  +--ro selection-filter* [filter-id]
        |     +--ro filter-id        string
        |     +--ro (filter-spec)?
        |        +--:(datastore-subtree-filter)
        |        +--:(datastore-xpath-filter)
        |           +--ro datastore-xpath-filter?   yang:xpath1.0
        |                   {sn:xpath}?
        +--ro subscriptions/
          +--ro subscription* [id]
             +--ro id                  subscription-id
             +--ro (target)
             |  +--:(stream)
             |  |  +--ro (stream-filter)?
             |  |  |  +--:(by-reference)
             |  |  |  |  +--ro stream-filter-name
             |  |  |  |          stream-filter-ref
             |  |  |  +--:(within-subscription)
             |  |  |     +--ro (filter-spec)?
             |  |  |        +--:(stream-subtree-filter)
             |  |  |        +--:(stream-xpath-filter)
             |  |  |           +--ro stream-xpath-filter?
             |  |  |                   yang:xpath1.0 {xpath}?
             |  |  +--ro stream             stream-ref
             |  +--:(datastore)
             |     +--ro datastore             identityref
             |     +--ro (selection-filter)?
             |        +--:(by-reference)
             |        |  +--ro selection-filter-ref
             |        |          selection-filter-ref
             |        +--:(within-subscription)
             |           +--ro (filter-spec)?
             |              +--:(datastore-subtree-filter)
             |              +--:(datastore-xpath-filter)
             |                 +--ro datastore-xpath-filter?
             |                         yang:xpath1.0 {sn:xpath}?
             +--ro stop-time?          yang:date-and-time
             +--ro encoding?           encoding
             +--ro receivers
             |  +--ro receiver* [name]
             |     +--ro name                      string
             |     +--ro sent-event-records?
             |     |       yang:zero-based-counter64
             |     +--ro excluded-event-records?
             |     |       yang:zero-based-counter64
             |     +--ro state                     enumeration
             +--ro (update-trigger)?
             |  +--:(periodic)
             |  |  +--ro periodic!
             |  |     +--ro period         centiseconds
             |  |     +--ro anchor-time?   yang:date-and-time
             |  +--:(on-change) {on-change}?
             |     +--ro on-change!
             |        +--ro dampening-period?   centiseconds
             |        +--ro sync-on-start?      boolean
             |        +--ro excluded-change*    change-type
             +--ro current-period?     yp:centiseconds

module example-collection-manifest {
  yang-version 1.1;
  namespace "http://example.com/example-data-collection-manifest";
  prefix d-mf;

  import ietf-platform-manifest {
    prefix p-mf;
    reference
      "RFC XXXX: Title to be completed";
  }
  import ietf-yang-schema-mount {
    prefix yangmnt;
    reference
      "RFC8528: YANG Schema Mount";
  }

  organization
    "IETF OPSAWG (Operations and Management Area) Working Group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/opsawg/>
     WG List:  <mailto:opsawg@ietf.org>
     Author:   Benoit Claise   <mailto:benoit.claise@huawei.com>
     Author:   Jean Quilbeuf   <mailto:jean.quilbeuf@huawei.com>
     Author:   Diego R. Lopez  <diego.r.lopez@telefonica.com>
     Author:   Ignacio Dominguez
                          <ignacio.dominguezmartinez@telefonica.com>
     Author:   Thomas Graf     <thomas.graf@swisscom.com>";
  description
    "This module describes the context of data collection from a
     given network element. The contents of this model must be
     streamed along with the data streamed from the network
     element so that the context of the data collection can
     be retrieved later.

     This module must be completed with
     ietf-platform-manifest
     to capture the whole context of a data collection session.

     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) 2025 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).
     This version of this YANG module is part of RFC XXXX; see the
     RFC itself for full legal notices.  ";

  revision 2025-02-21 {
    description
      "Initial revision";
    reference
      "RFC XXXX: A Data Manifest for Contextualized Telemetry Data";
  }

  container data-collections {
    config false;
    description
      "Contains the configuration and statistics for the collected
       data, per node in the network.";
    list data-collection {
      key "platform-id";
      description
        "Defines the information for each collected object";
      leaf platform-id {
        type leafref {
          path "/p-mf:platforms/p-mf:platform/p-mf:id";
        }
        description
          "Identifier of the platform collecting the data. This
           identifier is the same as the one in the platform
           manifest.";
      }
      yangmnt:mount-point "yang-push-collection" {
        description
          "This mount point MUST mount the following modules and their
           dependencies:
             * ietf-subscribed-notifications
             * ietf-yang-push
             * ietf-yp-current-period.
           This mount point MUST NOT mount any other modules.";
        reference
          "RFC8639: Subscription to YANG Notifications
           RFC8641: Subscription to YANG Notifications for datastore
           updates";
      }
    }
  }
}

7. Data Manifest and the Collected Data

This section focuses on relating the collected data to the data manifest. As this document specifically focuses on giving context on data collected via streamed telemetry, it is assumed that a streaming telemetry system is available. Another premise of this document is the storage of the collected data into a database for later exploitation. It is assumed that such a database exists and can be used for storing the data manifest.¶

8. Example

Figure 4 shows an example of both a Platform manifest and corresponding data collection manifests. The list of YANG modules in the yang-library container is kept empty for brevity.¶

{
  "ietf-platform-manifest:platforms": {
    "platform": [
      {
        "id": "PE1",
        "name": "PE1",
        "vendor": "ACME",
        "vendor-pen": 32473,
        "software-version": "3.14",
        "os-version": "2.79",
        "os-type": "ACME OS",
      }
    ]
  },
  "example-collection-manifest:data-collections": {
    "data-collection": [
      {
        "platform-id": "PE1",
        "ietf-subscribed-notifications:subscriptions": {
          "subscription": [
            {
              "id": 4242,
              "ietf-yang-push:datastore":
                                       "ietf-datastores:operational",
              "ietf-yang-push:datastore-xpath-filter":
                     "/ietf-interfaces:interfaces/interface/enabled",

              "ietf-yang-push:on-change": {},
              "receivers": {
                "receiver": [
                  {
                    "name": "yp-collector",
                    "state": "active"
                  }
                ]
              }
            },
            {
              "id": 4243,
              "ietf-yang-push:datastore":
                                       "ietf-datastores:operational",
              "ietf-yang-push:datastore-xpath-filter":
        "/ietf-interfaces:interfaces/interface/statistics/in-octets",
              "ietf-yang-push:periodic": {
                "period": 10000
              },
           "ietf-yp-current-period:current-period": 20000,
              "receivers": {
                "receiver": [
                  {
                    "name": "yp-collector",
                    "state": "active"
                  }
                ]
              }
            }
          ]
        }
      }
    ]
  }
}

Figure 4 contains the data collection manifest for two XPaths subscriptions. With the data collection manifest for the first one, with subscription identifier 4242, the exact semantics of the collected path, here the administrative status of the network interfaces, can be obtained by looking up the module in the yang-library of the corresponding platform manifest, in order to obtain the exact revision of ietf-interfaces used at collection time. Also, the "on-change" container indicates that data will be sent only if there is a change, thus not receiving data indicates that the administrative status of the interface did not change.¶

The other example of data collection manifest, with subscription identifier 4243, shows how a periodic subscription is reported. In that example, the 'current-period' indicates that the requested period of 10s (1000 centiseconds) could not be attained and is now of 20s, for instance because the device is overloaded.¶

Appendix D gives the command line for validating this example using [yanglint].¶

9. Security Considerations

The YANG modules specified in this document define a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446].¶

The Network Configuration Access Control Model (NACM) [RFC8341] 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.¶

Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability:¶

• ietf-plaftorm-manifest:platforms/platform contains details about the platform that an attacker could use to find the known vulnerabilities of the platform.¶

As the present approach reuses an existing telemetry system, the security considerations lie with the new content divulged in the new manifests. Appropriate access control filters must be associated to the corresponding leafs and containers, as well as the databases storing them.¶

The integrity and provenance of the data of the collection manifest can be ensured by a signing mechanism such as [I-D.lopez-opsawg-yang-provenance].¶

10. IANA Considerations

RFC Ed.: replace XXXX with actual RFC number and remove this note.¶

IANA is requested to register the following URIs in the "ns" subregistry within the "IETF XML Registry" [RFC3688]:¶

 URI: urn:ietf:params:xml:ns:yang:ietf-platform-manifest
 Registrant Contact:  The IESG.
 XML: N/A; the requested URI is an XML namespace.

 URI: urn:ietf:params:xml:ns:yang:ietf-yp-current-period
 Registrant Contact:  The IESG.
 XML: N/A; the requested URI is an XML namespace.

IANA is requested to register the following YANG modules in the "YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry.¶

 Name: ietf-platform-manifest
 Maintained by IANA?  N
 Namespace: urn:ietf:params:xml:ns:yang:ietf-platform-manifest
 Prefix: p-mf
 Reference: RFC XXXX

 Name: ietf-yp-current-period
 Maintained by IANA?  N
 Namespace: urn:ietf:params:xml:ns:yang:ietf-yp-current-period
 Prefix: yp-cp
 Reference: RFC XXXX

Appendix B. An Example of Use Based on MDT

In this example, the goal is to collect the administrative status and number of received bytes for the interfaces of a fictional ACME device, and store the result in a time-series database. The metrics are collected using YANG-Push, which is configured by specifying their XPaths and when they should be collected (periodically or on-change). More precisely, the Xpaths to collect are "ietf-interfaces:interfaces/interface/enabled" on every change and "ietf-interfaces:interfaces/interface/statistics/in-octets" every 100 milliseconds. The paths here are referring to the YANG module from [RFC8343]. The configuration of YANG push is out of scope for this document. Since they don’t have the same trigger, each of the path must be collected in its own subscription. Figure 5 presents an example for such a collection.¶

     +------------+                +--------+
     |   MDT      |--------------> |  TSDB  |
     | Collector  |                +--------+
     +------------+
          ^
          |
          |
      +---------+
      | Device  |
      +---------+

In the scenario depicted in Figure 5, the collector receives YANG-push data from the device and stores it into a TSDB. This section first presents a version without data manifest and then how to enrich it with the data manifest.¶

Examples rely on the notation from [I-D.kll-yang-label-tsdb] to represent how the data is stored in the TSDB. Without the data manifest, the result of the collection would be stored as showed in Figure 6. The "host" label indicates the devices from which the data is collected and the YANG keys are included as well. Here the interface "eth0" is enabled and received 1234 octets. In that case, the value is stored, without any way to know how the value was obtained.¶

 * Metric: interfaces_interface_enabled
 * Value: True
 * Labels:
   - host: "PE1"
   - interfaces_interface_name: "eth0"
--
 * Metric: interfaces_interface_statistics_in_octets
 * Value: 1234
 * Labels:
   - host: "PE1"
   - interfaces_interface_name: "eth0"

An option for keeping the data manifest with the data is to store it directly into the TSDB. In that case, the collector can subscribe to the data exported by the module presented in this document and store it as other metrics. For the platform manifest, assuming the platform identifier is "PE1", the collector subscribes to the path "ietf-platform-manifest:platforms/platform[id=PE1]". For the data collection manifests, the collector subscribes to the path "ietf-data-collection-manifest:data-collections/data-collection[platform-id="PE1"]/yang-push-collection/subscriptions/subscription[id=X]" where X is the subscription identifier of existing subscriptions. With the approach from [I-D.kll-yang-label-tsdb], the corresponding subtrees would be split into a set of datapoints, one per leaf. Figure 7 shows two examples of storing leaves in a TSDB. The first leaf is the vendor PEN number, which is part of the platform manifest. The second leaf is the Xpath filter used for subscription to the interface status.¶

 * Metric: platforms_platform_vendor_pen
 * Value: 32473
 * Labels:
   - host: "PE1"
   - platforms_platform_id: "PE1"
--
 * Metric: data_collections_data_collection_yang_push_collection_
           subscriptions_subscription_datastore_xpath_filter
 * Value: "ietf-interfaces:interfaces/interface/enabled"
 * Labels:
   - host: "PE1"
   - data_collections_data_collection_platform_id: "PE1"
   - data_collections_data_collection_yang_push_collection_
     subscriptions_subscription_id: 4242

In the labels, the "host" might be different from the "platforms_platform_id" in case the collector is the one assembling it, i.e. for devices that do not natively support the data manifest. In that case, the value of this label could be the hostname of the collector. The host value does not matter for retrieving the data manifest as the platform identifier is the meaningful field.¶

In this example, retrieving the platform manifest associated to a collected datapoint is done by looking for datapoints that have the label "platforms_platform_id" equal to the value of the host for that collected datapoint. In order to link a datapoint with the corresponding data collection manifest, an additional label for the subscription identifier is required. For instance, the same datapoints as in Figure 6 could be stored as in Figure 8.¶

 * Metric: interfaces_interface_enabled
 * Value: True
 * Labels:
   - host: "PE1"
   - interfaces_interface_name: "eth0"
   - data_collections_data_collection_yang_push_subscriptions_
     subscription_id: 4242
--
 * Metric: interfaces_interface_statistics_in_octets
 * Value: 1234
 * Labels:
   - host: "PE1"
   - interfaces_interface_name: "eth0"
   - data_collections_data_collection_yang_push_subscriptions_
     subscription_id: 4243

From the "interfaces_interface_enabled" datapoint, one can retrieve the corresponding data collection manifest by looking for datapoints that have the label data_collections_data_collection_yang_push_collection_subscriptions_subscription_id equal to 4242.¶

Various optimizations could be done, such as relying on on-change subscription to modify only the leaves that changed. In that way, the amount of data needed for updating and storing the data manifest in the TSDB would be limited.¶

Appendix C. Generating YANG Tree Diagrams

This section provides the files needed to generate the YANG tree diagram [RFC8340] from Figure 3. The diagram was obtained using yanglint [yanglint] version 2.1.80, using the YANG Schema Mount [RFC8528]. It was manually edited to remove parts irrelevant to this document such as data nodes from imported modules, notifications and RPCs.¶

In order to get a tree diagram involving YANG Schema Mount with yanglint, two data files are required, in addition to the YANG module, its dependencies and the YANG modules to be mounted. The first required file the extension data, containing the YANG library to use at the mount point, this file is provided below as "data-collection-extension-data.xml". The second required file is the YANG library to use at the top-level context, this file is provided below as "data-collection-toplevel-yanglib.xml". The following command was used to obtain the YANG Tree diagram (before manual edition).¶

        yanglint -f tree \
        -x data-collection-extension-data.xml \
        -Y data-collection-toplevel-yanglib.xml \
        example-collection-manifest@2025-02-21.yang

<CODE BEGINS> file "data-collection-extension-data.xml"

<yang-library xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library"
              xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
  <module-set>
    <name>mountee-set</name>
    <module>
      <name>ietf-subscribed-notifications</name>
      <revision>2019-09-09</revision>
      <namespace>
        urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications
      </namespace>
      <feature>xpath</feature>
    </module>
    <module>
      <name>ietf-yang-push</name>
      <revision>2019-09-09</revision>
      <namespace>
        urn:ietf:params:xml:ns:yang:ietf-yang-push
      </namespace>
      <feature>on-change</feature>
    </module>
    <module>
      <name>ietf-yp-current-period</name>
      <revision>2025-02-21</revision>
      <namespace>
        urn:ietf:params:xml:ns:yang:ietf-yp-current-period
      </namespace>
    </module>
    <module>
      <name>ietf-datastores</name>
      <revision>2018-02-14</revision>
      <namespace>
        urn:ietf:params:xml:ns:yang:ietf-datastores
      </namespace>
    </module>
    <module>
      <name>ietf-yang-library</name>
      <revision>2019-01-04</revision>
      <namespace>
        urn:ietf:params:xml:ns:yang:ietf-yang-library
      </namespace>
    </module>
    <import-only-module>
      <name>ietf-inet-types</name>
      <revision>2013-07-15</revision>
      <namespace>
        urn:ietf:params:xml:ns:yang:ietf-inet-types
      </namespace>
    </import-only-module>
    <import-only-module>
      <name>ietf-interfaces</name>
      <revision>2018-02-20</revision>
      <namespace>
        urn:ietf:params:xml:ns:yang:ietf-interfaces
      </namespace>
    </import-only-module>
    <import-only-module>
      <name>ietf-ip</name>
      <revision>2018-02-22</revision>
      <namespace>
        urn:ietf:params:xml:ns:yang:ietf-ip
      </namespace>
    </import-only-module>
    <import-only-module>
      <name>ietf-netconf-acm</name>
      <revision>2018-02-14</revision>
      <namespace>
        urn:ietf:params:xml:ns:yang:ietf-netconf-acm
      </namespace>
    </import-only-module>
    <import-only-module>
      <name>ietf-network-instance</name>
      <revision>2019-01-21</revision>
      <namespace>
        urn:ietf:params:xml:ns:yang:ietf-network-instance
      </namespace>
    </import-only-module>
    <import-only-module>
      <name>ietf-restconf</name>
      <revision>2017-01-26</revision>
      <namespace>
        urn:ietf:params:xml:ns:yang:ietf-restconf
      </namespace>
    </import-only-module>
    <import-only-module>
      <name>ietf-yang-patch</name>
      <revision>2017-02-22</revision>
      <namespace>
        urn:ietf:params:xml:ns:yang:ietf-yang-patch
      </namespace>
    </import-only-module>
    <import-only-module>
      <name>ietf-yang-types</name>
      <revision>2023-01-23</revision>
      <namespace>
        urn:ietf:params:xml:ns:yang:ietf-yang-types
      </namespace>
    </import-only-module>
  </module-set>
  <schema>
    <name>test-schema</name>
    <module-set>mountee-set</module-set>
  </schema>
  <datastore>
    <name>ds:running</name>
    <schema>test-schema</schema>
  </datastore>
  <datastore>
    <name>ds:operational</name>
    <schema>test-schema</schema>
  </datastore>
  <content-id>2</content-id>
</yang-library>
<modules-state xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
  <module-set-id>2</module-set-id>
</modules-state>
<schema-mounts
  xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount">
  <mount-point>
    <module>example-collection-manifest</module>
    <label>yang-push-collection</label>
    <shared-schema/>
  </mount-point>
</schema-mounts>


<CODE ENDS>

<CODE BEGINS> file "data-collection-toplevel-yanglib.xml"

<yang-library xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library"
              xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
    <module-set>
        <name>main-set</name>
        <module>
            <name>ietf-datastores</name>
            <revision>2018-02-14</revision>
            <namespace>
                urn:ietf:params:xml:ns:yang:ietf-datastores
            </namespace>
        </module>
        <module>
            <name>ietf-yang-library</name>
            <revision>2019-01-04</revision>
            <namespace>
                urn:ietf:params:xml:ns:yang:ietf-yang-library
            </namespace>
        </module>
        <module>
            <name>ietf-yang-schema-mount</name>
            <revision>2019-01-14</revision>
            <namespace>
                urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount
            </namespace>
        </module>
        <module>
            <name>example-collection-manifest</name>
            <revision>2025-02-21</revision>
            <namespace>
               http://example.org/example-collection-manifest
            </namespace>
        </module>
        <module>
            <name>ietf-platform-manifest</name>
            <revision>2025-02-21</revision>
            <namespace>
                urn:ietf:params:xml:ns:yang:ietf-platform-manifest
            </namespace>
        </module>
        <import-only-module>
            <name>ietf-inet-types</name>
            <revision>2013-07-15</revision>
            <namespace>
                urn:ietf:params:xml:ns:yang:ietf-inet-types
            </namespace>
        </import-only-module>
        <import-only-module>
            <name>ietf-yang-types</name>
            <revision>2023-01-23</revision>
            <namespace>
                urn:ietf:params:xml:ns:yang:ietf-yang-types
            </namespace>
        </import-only-module>
    </module-set>
    <schema>
        <name>main-schema</name>
        <module-set>main-set</module-set>
    </schema>
    <datastore>
        <name>ds:running</name>
        <schema>main-schema</schema>
    </datastore>
    <datastore>
        <name>ds:operational</name>
        <schema>main-schema</schema>
    </datastore>
    <content-id>1</content-id>
</yang-library>
<modules-state
  xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
  <module-set-id>2</module-set-id>
</modules-state>


<CODE ENDS>

Appendix D. Validating the Example

This section provides the command line for validating the example in Figure 4 using [yanglint]. The files "data-collection-extension-data.xml" and "data-collection-toplevel-yanglib.xml" are provided in the previous section. The file "manifests-example.json" in the one from Figure 4.¶

yanglint -e -x data-collection-extension-data.xml \
        -Y data-collection-toplevel-yanglib.xml \
        manifests-example.json

Authors' Addresses