| Internet-Draft | Telmetery Message | June 2025 |
| Elhassany & Graf | Expires 15 December 2025 | [Page] |
This document defines an extensible message schema in YANG to be used at the data collection to transform Network Telemetry messages into external systems such as Message Brokers. The extensible message schema enables a data collection to add metadata for the provenance of the operational network data.¶
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 15 December 2025.¶
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.¶
Nowadays network operators are using machine and human readable YANG [RFC7950] to model their configurations and obtain YANG modelled operational data from their networks.¶
Network operators organize their data in a Data Mesh [Deh22] where a Message Broker such as Apache Kafka [Kaf11] or RabbitMQ [Rab07] facilitates the exchange of messages among data processing components.¶
Today, subscribing to a YANG datastore, publishing a YANG modeled notifications message from the network and viewing the data in a time series database, manual labor is needed to perform data transformation to make a Message Broker and its data processing components with YANG notifications interoperable.¶
Even though YANG is intented to ease data management, this promise has not yet been fulfilled for Network Telemetry [RFC9232].¶
An Architecture for YANG-Push to Message Broker Integration [I-D.ietf-nmop-yang-message-broker-integration] defined an architecture for integrating YANG-Push with Message Brokers for a Data Mesh architecture. How the notification messages at a YANG-Push Receiver is being transformed to the Message Broker is being described in Section Section 4.5 of [I-D.ietf-nmop-yang-message-broker-integration], however the produced message format left unspecified.¶
The message could be published as it was received from the network to their organization's Message Broker. However, this approach is insufficient for correct human and automated understanding of the data generated by the network. This insufficiency stems from not presenting a holistic picture along with the data generated by the network. In particular, when a data consumer in the data mesh consumes a YANG message from their organization's Message Broker, they cannot answer simple questions such as:¶
Section 7.2 of [I-D.ietf-opsawg-collected-data-manifest] describes the content of a Data Manifest and how it is being mapped to the collected Network Telemetry data. The "ietf-telemetry-message" YANG module defined in this document makes use of the platform-details grouping defined in Section 5.2 of [I-D.ietf-opsawg-collected-data-manifest] for the network node and the data collection.¶
This document defines a standard YANG envelope message to carry with the collected Network Telemetry notifications the provenance and metadata information for a YANG data exchanged in Message Brokers for a Data Mesh architecture.¶
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.¶
The terms "Subscriber", "Publisher", and "Receiver" are used as defined in [RFC8639].¶
The term "Network Telemetry" is used as defined in [RFC9232]. This document uses the term export and collection to distinguish between the data export and collection.¶
The term "Message Broker" is used as defined in [I-D.ietf-nmop-yang-message-broker-integration].¶
The term "Data Manifest" is used as defined in [I-D.ietf-opsawg-collected-data-manifest]. The term provenance is used in general to describe the origin, history, and authenticity of an asset which then is described in a manifest.¶
In addition, this document reuses the terms "Notification Metadata" and "Notification Envelope" defined in [I-D.netana-netconf-notif-envelope] for the use in Message Broker environment:¶
Notification Metadata: Additional data describing the context of a notification that is sent in each message, e.g. which node generated the messsage or at which time the notification was published.¶
Notification Envelope: YANG structure encapsulating the payload of a notification, allowing the inclusion of metadata.¶
This document defines two YANG modules, an extensible YANG module for Network Telemetry messages defined in Figure 3 and a YANG-Push extension defined in Figure 4.¶
The extensible YANG module for Network Telemetry messages defines an envelope message schema which adds two provenance and two metadata categories to the collected Network Telemetry data.¶
The YANG-Push extension adds YANG-Push specific subscription metadata to the Network Telemetry protocol provenance of the envelope.¶
module: ietf-telemetry-message
+--ro message
+--ro network-node-manifest {network-node-manifest}?
| +--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 telemetry-message-metadata
| +--ro node-export-timestamp? yang:date-and-time
| +--ro collection-timestamp yang:date-and-time
| +--ro session-protocol
| | telemetry-session-protocol-type
| +--ro export-address inet:host
| +--ro export-port? inet:port-number
| +--ro collection-address? inet:host
| +--ro collection-port? inet:port-number
+--ro data-collection-manifest {data-collection-manifest}?
| +--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 network-operator-metadata
| +--ro labels* [name]
| +--ro name string
| +--ro (value)
| +--:(string-choice)
| | +--ro (string-choice)?
| | +--:(string-value)
| | +--ro string-value? string
| +--:(anydata-choice)
| +--ro (anydata-choice)?
| +--:(anydata-values)
| +--ro anydata-values? <anydata>
+--ro payload? <anydata>
module: ietf-yang-push-telemetry-message
augment /tm:message/tm:telemetry-message-metadata:
+--ro yang-push-subscription
+--ro id? sn:subscription-id
+--ro (filter-spec)?
| +--:(subtree-filter)
| | +--ro subtree-filter? <anydata>
| +--:(xpath-filter)
| +--ro xpath-filter? yang:xpath1.0
+--ro (target)?
| +--:(stream)
| | +--ro stream? string
| +--:(datastore)
| +--ro datastore? identityref
+--ro transport? sn:transport
+--ro encoding? sn:encoding
+--ro purpose? string
+--ro (update-trigger)?
| +--:(periodic)
| | +--ro periodic!
| | +--ro period? yp:centiseconds
| | +--ro anchor-time? yang:date-and-time
| +--:(on-change)
| +--ro on-change!
| +--ro dampening-period? yp:centiseconds
| +--ro sync-on-start? boolean
+--ro module-version* [module-name]
| +--ro module-name yang:yang-identifier
| +--ro revision? rev:revision-date
| +--ro revision-label? ysver:version
+--ro yang-library-content-id? string
<CODE BEGINS> file "ietf-telemetry-message@2025-06-10.yang"
module ietf-telemetry-message {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-telemetry-message";
prefix tm;
import ietf-yang-types {
prefix yang;
reference
"RFC 6991: Common YANG Data Types";
}
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types";
}
import ietf-platform-manifest {
prefix p-mf;
reference
"draft-ietf-opsawg-collected-data-manifest: A Data Manifest for
Contextualized Telemetry Data";
}
organization
"IETF Draft";
contact
"Author: Ahmed Elhassany
<mailto:ahmed.elhassany@swisscom.com>
Thomas Graf
<mailto:thomas.graf@swisscom.com>";
description
"This YANG module defines an extensible message schema to be used at
the data collection to transform Network Telemetry messages into
external systems such as Message Brokers.
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-06-10 {
description
"Initial revision.";
reference
"RFC XXXX";
}
identity session-protocol {
description
"Base identity to represent session protocols.";
}
identity yp-push {
base session-protocol;
description
"YANG-Push in RFC 8640 or RFC 8641 or RFC 8650.";
reference
"RFC 8640, RFC 8641, RFC 8650: YANG-Push Events and Notifications
for Datastores.";
}
identity netconf {
base session-protocol;
description
"NETCONF RPC as described in RFC 6241.";
reference
"RFC 6241: NETCONF RPC.";
}
identity restconf {
base session-protocol;
description
"RESTCONF HTTP as described in RFC 8040.";
reference
"RFC 8040.";
}
feature network-node-manifest {
description
"This feature indicates the network node manifest support.";
}
feature data-collection-manifest {
description
"This feature indicates the data collection manifest support.";
}
typedef telemetry-notification-event-type {
type enumeration {
enum log {
description
"Collector is reporting the event as it arrived from the
network element.";
}
enum update {
description
"Collector has updated an entry inside its local cache.
This could be triggered by an event from the network for
instance interface operational status changed or an internal
event in the collector, such as a timer triggered to referesh
old enteries.";
}
enum delete {
description
"Collector has deleted an entry from its local cache.";
}
}
description
"Type of event reported by the collector.";
}
typedef telemetry-session-protocol-type {
type identityref {
base session-protocol;
}
description
"Network Telemetry protocol used to deliver the notification
between the network node and the data collection.";
}
container message {
config false;
description
"Telemetry message used within the Data Mesh";
container network-node-manifest {
if-feature "network-node-manifest";
description
"Contains the Data Manifest about the network node that
exported Network Telemetry data.";
uses p-mf:platform-details;
}
container telemetry-message-metadata {
description
"contains the session information about the session between the
collector and the network node.";
leaf node-export-timestamp {
type yang:date-and-time;
description
"Timestamp when the Network Telemetry data has been exported
from network element.";
}
leaf collection-timestamp {
type yang:date-and-time;
mandatory true;
description
"Timestamp when the data collection collected the Network
Telemetry data from the network element.";
}
leaf session-protocol {
type telemetry-session-protocol-type;
mandatory true;
description
"Session protocol used to collect the Network Telemetry data
from the network node.";
}
leaf export-address {
type inet:host;
mandatory true;
description
"Network node IP address from where the Network Telemetry data
was exported from.";
}
leaf export-port {
type inet:port-number;
description
"Network node transport port number from where the Network
Telemetry data was exported.";
}
leaf collection-address {
type inet:host;
description
"Data collection IP address at which the Network Telemetry
data was collected.";
}
leaf collection-port {
type inet:port-number;
description
"Data collection transport port number at which the Network
Telemetry data was collected.";
}
}
container data-collection-manifest {
if-feature "data-collection-manifest";
description
"Contains the Data Manifest of the data collection which
collected the Network Telemetry data.";
uses p-mf:platform-details;
}
container network-operator-metadata {
description
"Network operator specific metadata added by the Network
Telemetry data collection.";
list labels {
key "name";
description
"Abritrary labels assinged by the data collection.";
leaf name {
type string {
length "1..max";
}
description
"Label name.";
}
choice value {
mandatory true;
description
"label value";
choice string-choice {
description
"String value";
leaf string-value {
type string;
description
"String value";
}
}
choice anydata-choice {
description
"YANG anydata value";
anydata anydata-values {
description
"anydata yang";
}
}
}
}
}
anydata payload {
description
"Message or notification received from network element.";
}
}
}
<CODE ENDS>
<CODE BEGINS> file "ietf-yang-push-telemetry-message@2025-06-10.yang"
module ietf-yang-push-telemetry-message {
yang-version 1.1;
namespace
"urn:ietf:params:xml:ns:yang:ietf-yang-push-telemetry-message";
prefix yptm;
import ietf-subscribed-notifications {
prefix sn;
reference
"RFC 8639: Subscription to YANG Notifications";
}
import ietf-telemetry-message {
prefix tm;
reference
"draft-netana-nmop-message-broker-telemetry-message: Extensible
YANG Model for Network Telemetry Messages";
}
import ietf-yang-push {
prefix yp;
reference
"RFC 8641: Subscription to YANG Notifications for Datastore
Updates";
}
import ietf-yang-types {
prefix yang;
reference
"RFC 6991: Common YANG Data Types";
}
import ietf-datastores {
prefix ds;
reference
"RFC 8342: Network Management Datastore Architecture (NMDA)";
}
import ietf-yang-revisions {
prefix rev;
reference
"draft-ietf-netmod-yang-module-versioning: Updated YANG Module
Revision Handling";
}
import ietf-yang-semver {
prefix ysver;
reference
"draft-ietf-netmod-yang-semver: YANG Semantic Versioning";
}
organization
"IETF Draft";
contact
"Author: Ahmed Elhassany
<mailto:ahmed.elhassany@swisscom.com>
Thomas Graf
<mailto:thomas.graf@swisscom.com>";
description
"Adds YANG-Push specific subscription metadata to the data
collection protocol provenance of the ietf-telemetry-message
envelope.
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-06-10 {
description
"Initial revision.";
reference
"RFC XXXX";
}
augment "/tm:message/tm:telemetry-message-metadata" {
description
"Augments telemetry-message-metadata with YANG-Push specific
subscription metadata";
container yang-push-subscription {
config false;
description
"YANG-Push specific subscription metadata";
leaf id {
type sn:subscription-id;
description
"This references the affected subscription.";
}
choice filter-spec {
description
"The content filter specification for this request.";
anydata subtree-filter {
description
"Event stream evaluation criteria or the parameter
identifies the port of the target datastore encoded in the
syntax of a subtree filter as defined in RFC 6241,
Section 6.";
reference
"RFC 6241: Network Configuration Protocol (NETCONF),
Section 6.";
}
leaf xpath-filter {
type yang:xpath1.0;
description
"Event stream evaluation criteria or porting of the target
datastore encoded in the syntax of an XPath 1.0
expression";
reference
"XML Path Language (XPath) Version 1.0
(https://www.w3.org/TR/1999/REC-xpath-19991116)
RFC 7950: The YANG 1.1 Data Modeling Language,
Section 10";
}
}
choice target {
description
"Identifies the source of information against which a
subscription is being applied as well as specifics on the
subset of information desired from that source.";
case stream {
leaf stream {
type string;
description
"Indicates the event stream to be considered for this
subscription.";
}
}
case datastore {
leaf datastore {
type identityref {
base ds:datastore;
}
description
"Datastore from which to retrieve data.";
}
}
}
leaf transport {
type sn:transport;
description
"For a configured subscription, this leaf specifies the
transport used to deliver messages destined for all
receivers of that subscription.";
}
leaf encoding {
type sn:encoding;
description
"The type of encoding for notification messages. For a
dynamic subscription, if not included as part of an
'establish-subscription' RPC, the encoding will be populated
with the encoding used by that RPC. For a configured
subscription, if not explicitly configured, the encoding
will be the default encoding for an underlying transport.";
}
leaf purpose {
type string;
description
"Open text allowing a configuring entity to embed the
originator or other specifics of this subscription.";
}
choice update-trigger {
description
"Defines necessary conditions for sending an event record to
the subscriber.";
case periodic {
container periodic {
presence "indicates a periodic subscription";
description
"The publisher is requested to notify periodically the
current values of the datastore as defined by the
selection filter.";
leaf period {
type yp:centiseconds;
description
"Duration of time which should occur between periodic
push updates, in one hundredths of a second.";
}
leaf anchor-time {
type yang:date-and-time;
description
"Designates a timestamp before or after which a series
of periodic push updates are determined. The next
update will take place at a whole multiple interval
from the anchor time. For example, for an anchor time
is set for the top of a particular minute and a period
interval of a minute, updates will be sent at the top
of every minute this subscription is active.";
}
}
}
case on-change {
container on-change {
presence "indicates an on-change subscription";
description
"The publisher is requested to notify changes in values
in the datastore subset as defined by a selection
filter.";
leaf dampening-period {
type yp:centiseconds;
default "0";
description
"Specifies the minimum interval between the assembly of
successive update records for a single receiver of a
subscription. Whenever subscribed objects change, and
a dampening period interval (which may be zero) has
elapsed since the previous update record creation for
a receiver, then any subscribed objects and properties
which have changed since the previous update record
will have their current values marshalled and placed
into a new update record.";
}
leaf sync-on-start {
type boolean;
default "true";
description
"When this object is set to false, it restricts an
on-change subscription from sending push-update
notifications. When false, pushing a full selection
per the terms of the selection filter MUST NOT be done
for this subscription. Only updates about changes,
i.e. only push-change-update notifications are sent.
When true (default behavior), in order to facilitate a
receiver's synchronization, a full update is sent when
the subscription starts using a push-update
notification. After that, push-change-update
notifications are exclusively sent unless the publisher
chooses to resync the subscription via a new
push-update notification.";
}
}
}
}
list module-version {
key "module-name";
config false;
description
"List of yang-push-module-version grouping. The revision is
not configurable.";
leaf module-name {
type yang:yang-identifier;
config false;
description
"This references the YANG module name.";
}
leaf revision {
type rev:revision-date;
config false;
description
"This references the YANG module revision of the sent
notification message.";
}
leaf revision-label {
type ysver:version;
description
"This references the YANG module semantic version of the
sent notification message.";
}
}
leaf yang-library-content-id {
type string;
config false;
description
"Contains the YANG library content identifier RFC 8525
information.";
}
}
}
}
<CODE ENDS>
This document registers the following two namespace URIs in the IETF XML Registry [RFC3688]:¶
This document registers the following two YANG modules in the YANG Module Names registry [RFC3688]:¶
This section is modeled after the template described in Section 3.7 of [I-D.ietf-netmod-rfc8407bis].¶
The "ietf-telemetry-message" and "ietf-yang-push-telemetry-message" YANG modules defines two data models that are designed to be accessed via YANG-based management protocols, such as NETCONF [RFC6141] and RESTCONF [RFC8040]. These protocols have to use a secure transport layer (e.g., SSH [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and have to use mutual authentication.¶
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.¶
There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., "config true", which is the default). All writable data nodes are likely to be reasonably sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) and delete operations to these data nodes without proper protection or authentication can have a negative effect on network operations. The following subtrees and data nodes have particular sensitivities/vulnerabilities:¶
"There are no particularly sensitive writable data nodes."¶
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. Specifically, the following subtrees and data nodes have particular sensitivities/ vulnerabilities:¶
"There are no particularly sensitive readable data nodes."¶
This section provides pointers to existing open source implementations of this draft. Note to the RFC-editor: Please remove this before publishing.¶
An open source Network Telemetry data collection implemented "ietf-telemetry-message" and "ietf-yang-push-telemetry-message" .¶
The open source code can be accessed here: [Netgauze_Github].¶
Figure 5 provides an example of a JSON encoded, [RFC7951], Network Telemetry message.¶
========== NOTE: '\' line wrapping per RFC 8792) ===========
{
"ietf-telemetry-message:message": {
"network-node-manifest": {},
"telemetry-message-metadata": {
"session-protocol": "yp-push",
"node-export-timestamp": "2025-05-22T07:28:22.381856022Z",
"collection--timestamp": "2025-05-22T07:28:23.481855122Z",
"export-address": "192.168.100.3",
"export-port": 57914,
"ietf-yang-push-telemetry-message:yang-push-subscription": {
"datastore": "ietf-datastores:operational",
"encoding": "ietf-subscribed-notifications:encode-json",
"id": 12345678,
"module-version": [
{
"module-name": "vrouter-loopback",
"revision": "2024-04-22"
}
],
"on-change": {
"sync-on-start": true
},
"purpose": "send notifications",
"transport": "ietf-udp-notif-transport:udp-notif",
"xpath-filter": "/state/vrf/l3vrf/interface/loopback/enabled",
"yang-library-content-id": "3625735881"
}
},
"data-collection-manifest": {
"name": "netgauze-collector@leo-rocky",
"os-type": "Rocky Linux",
"os-version": "8.10",
"software-flavor": "debug",
"software-version": "0.6.2 (cbd74215)",
"vendor": "NetGauze"
},
"network-operator-metadata": {
"labels": [
{
"name": "nkey",
"string-value": "unknown"
},
{
"name": "pkey",
"string-value": "unknown"
}
]
},
"payload": {
"ietf-yp-notification:envelope": {
"contents": {
"ietf-subscribed-notifications:subscription-started": {
"encoding": "ietf-subscribed-notifications:encode-json",
"id": 12345678,
"ietf-distributed-notif:message-publisher-ids": [
0
],
"ietf-yang-push-revision:module-version": [
{
"module-name": "vrouter-loopback",
"revision": "2024-04-22"
}
],
"ietf-yang-push-revision:yang-library-content-id": \
"3625735881",
"ietf-yang-push:datastore": "ietf-datastores:operational",
"ietf-yang-push:datastore-xpath-filter": \
"/state/vrf/l3vrf/interface/loopback/enabled",
"ietf-yang-push:on-change": {
"sync-on-start": true
},
"purpose": "send notifications",
"transport": "ietf-udp-notif-transport:udp-notif"
}
},
"event-time": "2025-03-04T07:31:36.806021107+00:00",
"hostname": "daisy-ietf-ipf-zbl1843-r-daisy-58",
"sequence-number": 48
}
}
}
}
The authors would like to thank Rob Wilton, Alex Huang Feng Benoit Claise and Leonardo Rodoni for their review and valuable comments.¶