draft-ietf-nmop-message-broker-telemetry-message-01.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<!-- If further character entities are required then they should be added to the DOCTYPE above.
     Use of an external entity file is not recommended. -->
<rfc category="info"
     docName="draft-ietf-nmop-message-broker-telemetry-message-01"
     ipr="trust200902" obsoletes="" submissionType="IETF" updates=""
     version="3" xml:lang="en" xmlns:xi="http://www.w3.org/2001/XInclude"
     xmlns:ns2="http://www.w3.org/2000/svg"
     xmlns:ns="http://www.w3.org/1999/xlink">
  <front>
    <title
    abbrev="Telmetery Message">Extensible YANG Model for Network
     Telemetry Messages</title>

    <seriesInfo name="Internet-Draft"
                value="draft-ietf-nmop-message-broker-telemetry-message-01"/>

    <author fullname="Ahmed Elhassany" initials="A" surname="Elhassany">
      <organization>Swisscom</organization>

      <address>
        <postal>
          <street>Binzring 17</street>

          <city>Zuerich 8045</city>

          <region/>

          <code/>

          <country>Switzerland</country>
        </postal>

        <phone/>

        <email>ahmed.elhassany@swisscom.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Thomas Graf" initials="T." surname="Graf">
      <organization>Swisscom</organization>

      <address>
        <postal>
          <street>Binzring 17</street>

          <city>Zuerich 8045</city>

          <region/>

          <code/>

          <country>Switzerland</country>
        </postal>

        <phone/>

        <email>thomas.graf@swisscom.com</email>

        <uri/>
      </address>
    </author>

    <date day="02" month="July" year="2025"/>

    <area>General</area>

    <workgroup>NMOP</workgroup>

    <keyword>keyword</keyword>

    <abstract>
      <t>This document defines an extensible message schema in YANG to
      be used at data collection to transform Network Telemetry
      messages into external systems such as Message Brokers.
      The extensible message schema enables data collectors to add
      metadata for the provenance of the operational network data.</t>
    </abstract>
  </front>

  <middle>
    <section>
      <name>Introduction</name>

      <t>Nowadays network operators are using machine and human
      readable <xref target="RFC7950">YANG</xref> to model their
      configurations and obtain YANG modelled operational data from
      their networks.</t>
    
      <t>Network operators organize their data in a <xref
      target="Deh22">Data Mesh</xref> where a Message Broker such as
      <xref target="Kaf11">Apache Kafka</xref> or <xref
      target="Rab07">RabbitMQ</xref> facilitates the exchange of
      messages among data processing components.</t>
    
      <t>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.</t>

      <t>Even though YANG is intended to ease data management, this
      promise has not yet been fulfilled for <xref target="RFC9232">
      Network Telemetry</xref>.</t>

      <t><xref target="I-D.ietf-nmop-yang-message-broker-integration">An
      Architecture for YANG-Push to Message Broker Integration</xref>
      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 <xref
      section="4.5" sectionFormat="of"
      target="I-D.ietf-nmop-yang-message-broker-integration"/>, however 
      the produced message format left unspecified.</t>
    
      <t>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:</t>
    
      <ul>
        <li>Which network operating system collected the data?</li>

        <li>To which network platform belongs the network node?</li>    

        <li>What is the subscribed xpath, sub-tree filter and its
        schema reference?</li>  
    
        <li>When did a data collector received the data?</li>
    
        <li>What additional metadata is necessary for a consumer to make
        sense of the data?</li>
      </ul>

      <t><xref section="7.2" sectionFormat="of"
      target="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 <xref section="5.2"
      sectionFormat="of"
      target="I-D.ietf-opsawg-collected-data-manifest"/> for the
      network node and the data collector.</t>
      
      <t>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 exchange between between
			Message Broker producers and consumers as described in
			Section 4.5 and 4.6 <xref
      target="I-D.ietf-nmop-yang-message-broker-integration"/>. The
			described YANG model fascilitates <xref
			target="RFC7951">JSON</xref> and <xref
			target="RFC9254">CBOR</xref> serialization.</t>
    </section>
    
    <section>
      <name>Conventions and Definitions</name>

      <t>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 <xref target="RFC2119"/>
      <xref target="RFC8174"/> when, and only when, they appear in all
      capitals, as shown here.</t>

      <section>
          <name>Terminology</name>
    
        <t>The terms "Subscriber", "Publisher", and "Receiver" are
        used as defined in <xref target="RFC8639"/>.</t>
  
        <t>The term "Network Telemetry" is used
        as defined in <xref target="RFC9232"/>. This document uses the
        term export and collection to distinguish between the
        data export and collection.</t>

        <t>The term "Message Broker" is used
        as defined in <xref
        target="I-D.ietf-nmop-yang-message-broker-integration"/>.</t>

        <t>The term "Data Manifest" is used
        as defined in <xref
         target="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.</t> 
 
        <t>In addition, this document reuses the terms "Notification
         Metadata" and "Notification Envelope" defined in <xref
         target="I-D.ietf-netconf-notif-envelope"/> for the use in
         Message Broker environment:</t>

        <t>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.</t>

        <t>Notification Envelope: YANG structure encapsulating the
        payload of a notification, allowing the inclusion of metadata.
        </t>
      </section>
    </section>

    <section>
      <name>YANG Modules</name>

      <t>This document defines two YANG modules, an extensible YANG
      module for Network Telemetry messages defined in <xref
      target="ietf-telemetry-message-module"/> and a YANG-Push extension
      defined in <xref
      target="ietf-yang-push-telemetry-message-module"/>.</t>

      <t>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.</t>

      <t>The YANG-Push extension adds YANG-Push specific subscription
      metadata to the Network Telemetry protocol provenance of the
      envelope.</t>

      <dl>
        <dt>Network Node Manifest:</dt>

        <dd>The OPTIONAL "network-node-manifest" container in <xref
        target="ietf-telemetry-message-module"/> contains the Data
        Manifest about the network node that exported Network Telemetry
        data. It adds information such as the node name, address, and
        software version. Each leaf is OPTIONAL.
        </dd>
      </dl>

      <dl>
        <dt>Network Telemetry Protocol Metadata:</dt>

        <dd>The "telemetry-message-metadata" container in <xref
        target="ietf-telemetry-message-module"/> contains the Network
        Telemetry session information between the collector and the
        network node. It adds fields such as the Network Telemetry
        protocol name, the IP addresses and ports of that transport
        session and the time the event was exported at the network node
        and received at the data collector. Apart from the
        collection-timestamp, session-protocol and remote-address leafs
        all other leafs are OPTIONAL.  These Network Telemetry session
        informations allow a network operator to troubleshoot and
        measure delay and loss related issues. Moreover, this document
        also defines with <xref
        target="ietf-yang-push-telemetry-message-module"/> an extension
        specific to YANG-Push that includes YANG-Push subscription
        information relevant to the Network Telemetry session
        information.</dd>
      </dl>

      <dl>
        <dt>Data Collection Manifest:</dt>

        <dd>The OPTIONAL "data-collection-manifest" container in <xref
        target="ietf-telemetry-message-module"/> contains the Data
        Manifest of the data collector which collected the Network
        Telemetry data. The data type is the same as the previous
        category but specific to the collector node.</dd>
      </dl>

      <dl>
        <dt>Network Operator Metadata:</dt>

        <dd>The OPTIONAL "labels" list in the "network-operator-metadata"
        container in <xref target="ietf-telemetry-message-module"/>
        contains the operator specific metadata. Some operators enrich
        the collected data with specific information. For instance: type
        of the network node (provider or provider edge node) or which
        operational unit the node is operated by. For this purpose the
        document defines a generic metadata map with key/values that can
        be used freely by the network operator.</dd>
      </dl>

      <figure anchor="ietf-telemetry-message-tree"
      title="YANG tree diagram for 'ietf-telemetry-message' module.">
      
<sourcecode type="yangtree"><![CDATA[
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>
]]></sourcecode></figure>

<figure title="ietf-yang-push-telemetry-message tree">
  <artwork>
<![CDATA[
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
]]></artwork>
</figure>


      <figure anchor="ietf-telemetry-message-module"
      title="YANG 'ietf-telemetry-message' module.">

<sourcecode name="ietf-telemetry-message@2025-06-10.yang" type="yang"
markers="true"><![CDATA[
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
     data collection to transform Network Telemetry messages towards
     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 collector.";
  }

  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. This can be obtained in YANG-Push from
           event-time defined in draft-ietf-netconf-notif-envelope or
           in IPFIX from the export time in the message header as
           defined in RFC 7011 or in BMP from the timestamp in The
           per-peer header as defined in RFC 7854.";
      }
      leaf collection-timestamp {
        type yang:date-and-time;
        mandatory true;
        description
          "Timestamp when the data collector 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 collector IP address at which the Network Telemetry
           data was collected.";
      }
      leaf collection-port {
        type inet:port-number;
        description
          "Data collector 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 collector 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 assigned by the data collector.";
        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.";
    }
  }
}
]]></sourcecode>
</figure>

      <figure anchor="ietf-yang-push-telemetry-message-module"
      title="YANG 'ietf-yang-push-telemetry-message' module.">

<sourcecode name="ietf-yang-push-telemetry-message@2025-06-10.yang"
type="yang" markers="true"><![CDATA[
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.";
      }
    }
  }
}
]]></sourcecode>
</figure>
    </section>

    <section>
      <name>Use Cases</name>

      <section>
        <name>Data Chain Troubleshooting</name>

        <t>In a distributed system like a data chain described in <xref
				target="I-D.ietf-nmop-yang-message-broker-integration"/>, a
				single system component could introduce a new issue after a 
				software upgrade of a system component . Thanks to the network
				node and the data collection manifest, the data engineer is able
				to identify wherever a software upgrade has been performed on
				a network node or on a data collector and its impact on the
				telemetry messages. Such an upgrade could have a potential
				impact on the YANG schema of the exported YANG-Push Notification
				which is identifable through the "yang-library-content-id" and
				"revision" and "revision-label" defined in <xref
				target="I-D.ietf-netconf-yang-notifications-versioning"/>
				and transformed at the data collectors as part of Network
				Telemetry protocol metadata or the YANG schema id when being
				produced to the message broker as described in <xref
				section="4.5"
				target="I-D.ietf-nmop-yang-message-broker-integration"/>.</t>
      </section>

      <section>
        <name>Data Product Service Level Objective</name>

        <t>For <xref section="3.5"
				target="I-D.ietf-nmop-network-anomaly-architecture">Service
				Disruption Detection</xref> in Network Anomaly Detection,
				operational Network Telemetry data needs to to be consumeable
				as a <xref section="4.7"
				target="I-D.ietf-nmop-yang-message-broker-integration">YANG data
				consumer</xref> within the defined time to ensure a holistic
				view of the network. To measure the delay and loss between the
				data export on the network node, the data collectors and
				the YANG data consumer, sequence numbers and timestamps are
				required. With "hostname" and "sequence-number"
        defined in <xref section="3.4"
				target="I-D.ietf-netconf-notif-envelope"/> each message is
				uniquely identifiably and with "event-time" and 
				"observation time" defined in section 3.4 and 3.5 of <xref
				target="I-D.ietf-netconf-notif-envelope"/> and "collection-time"
				defined in this document and the timestamp when the data arrived
				at the YANG data consumer, the loss and delay for a given
				network node and message can be deducted. Metadata introduced in
				this document help a data engineer to determine a common
				denominator and identify the system component causing the delay
				and loss.</t>
				
				<t>Certain collection protocol types such as polling or push
				based and subscriptions types, such as on-change or periodical,
				have different data delay characteristics. Push based on-change
				subscriptions are expected to export messages almost instantly
				where polling based subscriptions observe changes depending on
				their polling interval much later. With the Network Telemetry
				protocol metadata introduced by this document, based on the
				update-trigger informations, a YANG data consumer can define
				for a given YANG-Push subscription id a lower service Level
				objective than for another. Therefore adjust the detection
				to be more real-time than without this information.</t>
      </section>
    </section>

    <section>
      <name>IANA Considerations</name>
      <t>This document registers the following two namespace URIs in the
    <xref target="RFC3688">IETF XML Registry</xref>:</t>

      <ul>
        <li>URI: urn:ietf:params:xml:ns:yang:ietf-telemetry-message</li>
        <li>Registrant Contact: The IESG.</li>
        <li>XML: N/A; the requested URI is an XML namespace.</li>
      </ul>

      <t/>

      <ul>
        <li>URI: urn:ietf:params:xml:ns:yang:ietf-yang-push-telemetry-message</li>
        <li>Registrant Contact: The IESG.</li>
        <li>XML: N/A; the requested URI is an XML namespace.</li>
      </ul>

      <t>This document registers the following two YANG modules in the
    <xref target="RFC3688">YANG Module Names registry</xref>:</t>

      <ul>
        <li>Name: ietf-telemetry-message</li>
        <li>Namespace: 
      urn:ietf:params:xml:ns:yang:ietf-telemetry-message</li>
        <li>Prefix: tm</li>
        <li>Reference: RFC XXXX</li>
      </ul>

      <t/>

      <ul>
        <li>Name: ietf-yang-push-telemetry-message</li>
        <li>Namespace: 
      urn:ietf:params:xml:ns:yang:ietf-yang-push-telemetry-message</li>
        <li>Prefix: yptm</li>
        <li>Reference: RFC XXXX</li>
      </ul>
    </section>

    <section>
      <name>Security Considerations</name>
      <t>This section is modeled after the template described in
      <xref section="3.7" sectionFormat="of"
      target="I-D.ietf-netmod-rfc8407bis"/>.</t>

      <t>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 <xref target="RFC6141"/> and
      RESTCONF <xref target="RFC8040"/>. These protocols have to use a
      secure transport layer (e.g., SSH <xref target="RFC4252"/>, TLS
      <xref target="RFC8446"/>, and QUIC <xref target="RFC9000"/>) and
      have to use mutual authentication.</t>

      <t>The Network Configuration Access Control Model (NACM) <xref
      target="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.
      </t>

      <t>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:</t>

      <t>"There are no particularly sensitive writable data nodes."</t>

      <t>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:</t>

      <t>"There are no particularly sensitive readable data nodes."</t>
    </section>

    <section>
      <name>Implementation status</name>
      <t>This section provides pointers to existing open source
      implementations of this draft. Note to the RFC-editor: Please
      remove this before publishing.</t>

      <section>
        <name>Netgauze</name>
        <t>An open source Network Telemetry data collection implemented 
        "ietf-telemetry-message" and "ietf-yang-push-telemetry-message"
        .</t>

        <t>The open source code can be accessed here: <xref
        target="Netgauze_Github"/>.</t>

        <t><xref target="netgauze_message_example_json_fig"/>
        provides an example of a JSON encoded, <xref target="RFC7951"/>,
        Network Telemetry message.</t>

        <figure anchor="netgauze_message_example_json_fig"
                title="JSON Network Telemetry Example">
          <artwork><![CDATA[
{
  "ietf-telemetry-message:message": {
    "network-node-manifest": {
      "name": "pe1",
      "vendor": "open source",
      "software-version": "1.1.2"
    },
    "telemetry-message-metadata": {
      "node-export-timestamp": "2024-02-14T12:10:10.10+01:00",
      "collection-timestamp": "2024-02-14T12:10:10.12+01:00",
      "session-protocol": "yp-push",
      "export-address": "192.168.1.100",
      "export-port": 123,
      "collection-address": "192.168.1.1",
      "collection-port": 9991,
      "ietf-yang-push-telemetry-message:yang-push-subscription": {
        "id": 89,
        "xpath-filter": "/ietf-interfaces:interfaces",
        "datastore": "ietf-datastores:operational",
        "transport": "ietf-udp-notif-transport:udp-notif",
        "encoding": "ietf-subscribed-notifications:encode-json",
        "module-version": [
          {
            "module-name": "ietf-interfaces",
            "revision": "2018-02-20",
            "revision-label": "2.0.0"
          }
        ],
        "yang-library-content-id": "abc"
      }
    },
    "data-collection-manifest": {
      "name": "collector-1",
      "vendor": "open source",
      "software-version": "2.1.0"
    },
    "network-operator-metadata": {
      "labels": [
        {
          "name": "platform-name",
          "string-value": "name"
        }
      ]
    },
    "payload": {
      "ietf-yang-push:push-update": {
        "id": 89,
        "datastore-contents": {
          "ietf-interfaces:interfaces": {
            "interface": [
              {
                "name": "eth0",
                "oper-status": "down"
              }
            ]
          }
        }
      }
    }
  }
}
          ]]></artwork>
        </figure>
      </section>
    </section>
  </middle>

  <back>
    <references>
      <name>References</name>

      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4252.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6141.xml"/>
        
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6991.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8342.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8639.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8641.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9232.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-nmop-yang-message-broker-integration.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-notif-envelope.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-opsawg-collected-data-manifest.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-netmod-yang-module-versioning.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-netmod-yang-semver.xml"/>
     </references>

     <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3444.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7951.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9254.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-netmod-rfc8407bis.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-nmop-network-anomaly-architecture.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-yang-notifications-versioning.xml"/>

        <reference anchor="Deh22"
                   target="https://www.oreilly.com/library/view/data-mesh/9781492092384/">
          <front>
            <title>Data Mesh</title>

            <author fullname="Zhamak Dehghani" initials="Z."
                    surname="Dehghani"/>

            <date month="March" year="2022"/>
          </front>

          <seriesInfo name="ISBN" value="9781492092391"/>

          <refcontent>O'Reilly Media</refcontent>
        </reference>

        <reference anchor="Rab07" target="https://rabbitmq.com/">
          <front>
            <title>RabbitMQ</title>

            <author fullname="VMware"/>

            <date month="February" year="2007"/>
          </front>

          <refcontent>Mozilla Public License</refcontent>
        </reference>

        <reference anchor="Kaf11" target="https://kafka.apache.org/">
          <front>
            <title>Apache Kafka</title>

            <author fullname="Neha Narkhede" initials="N." surname="Narkhede"/>

            <date month="January" year="2011"/>
          </front>

          <refcontent>Apache Software Foundation</refcontent>
        </reference>

        <reference anchor="Netgauze_Github"
                   target="https://github.com/NetGauze/NetGauze/pull/213">
          <front>
            <title>Netgauze open source Network Telemetry Data
            Collection</title>
   
            <author/>
   
            <date/>
          </front>
        </reference>
      </references>
    </references>

    <section anchor="Acknowledgements" numbered="false">
      <name>Acknowledgements</name>

      <t>The authors would like to thank Rob Wilton, Alex Huang Feng,
      Benoit Claise, Leonardo Rodoni, Reshad Rahman, Dan Voyer and
			Paolo Lucente for their review and valuable comments.</t>
    </section>
  </back>
</rfc>