A YANG Data Model for Performance Monitoring (PM) Collection
draft-yoon-bpm-pm-collection-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Bin Yeong Yoon , Youngkil You | ||
| Last updated | 2026-11-02 | ||
| Replaces | draft-yoon-ippm-collection-measure | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Yang Validation | 0 errors, 0 warnings | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-yoon-bpm-pm-collection-00
BPM Working Group B. Y. Yoon
Internet-Draft ETRI
Intended status: Standards Track Y. You
Expires: 7 May 2027 woori-net
3 November 2026
A YANG Data Model for Performance Monitoring (PM) Collection
draft-yoon-bpm-pm-collection-00
Abstract
This document specifies a YANG data model for the collection of
Performance Monitoring (PM) data, based on the collection
requirements of the performance management function defined in ITU-T
G.7710. The model processes raw performance data sampled at a
network node and produces structured data that can be retrieved by
clients via pull-based mechanisms or delivered via push-based
mechanisms such as YANG-Push. This document does not define new
performance metrics; the base metrics are those of the IPPM
framework, and the model specifies the collection and exposure of the
operationally important subset.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://binyeongyoon-ietf.github.io/ietf-pm-streaming/draft-yoon-bpm-
pm-collection.html. Status information for this document may be
found at https://datatracker.ietf.org/doc/draft-yoon-bpm-pm-
collection/.
Source for this draft and an issue tracker can be found at
https://github.com/binyeongyoon-ietf/ietf-pm-streaming.
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/.
Yoon & You Expires 7 May 2027 [Page 1]
Internet-Draft PM Collection YANG November 2026
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 7 May 2027.
Copyright Notice
Copyright (c) 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. PM Processing Pipeline in a Network Element . . . . . . . 3
1.2. Relationship to the IETF Performance Metric Framework . . 6
1.3. Motivation and Scope . . . . . . . . . . . . . . . . . . 8
1.4. Requirements Language . . . . . . . . . . . . . . . . . . 9
2. PM parameters . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1. Types . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1. Parameter Identities . . . . . . . . . . . . . . . . 11
2.2. Profiles . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1. Naming . . . . . . . . . . . . . . . . . . . . . . . 12
2.3. Measurement Method Metadata . . . . . . . . . . . . . . . 13
3. Periodic Collection . . . . . . . . . . . . . . . . . . . . . 14
3.1. Interval Timing . . . . . . . . . . . . . . . . . . . . . 14
3.1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Collection Types . . . . . . . . . . . . . . . . . . . . 18
3.2.1. Counts . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.2. Snapshot . . . . . . . . . . . . . . . . . . . . . . 22
3.2.3. Tidemarks . . . . . . . . . . . . . . . . . . . . . . 22
4. Collection Interval Data Validity . . . . . . . . . . . . . . 23
4.1. Suspect Interval Flag . . . . . . . . . . . . . . . . . . 23
4.2. Interval Status and the Meaning of Zero . . . . . . . . . 24
4.3. Coverage, Elapsed Time, and Interval Timestamps . . . . . 24
4.4. Retained Interval Data . . . . . . . . . . . . . . . . . 25
5. Thresholding . . . . . . . . . . . . . . . . . . . . . . . . 25
5.1. Periodic Thresholding . . . . . . . . . . . . . . . . . . 25
Yoon & You Expires 7 May 2027 [Page 2]
Internet-Draft PM Collection YANG November 2026
5.2. Non-Periodic Thresholding . . . . . . . . . . . . . . . . 26
6. Data Access . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.1. Example Module . . . . . . . . . . . . . . . . . . . . . 26
6.2. Pull-Based Polling . . . . . . . . . . . . . . . . . . . 28
6.3. Periodic Events . . . . . . . . . . . . . . . . . . . . . 30
6.4. Threshold Events . . . . . . . . . . . . . . . . . . . . 32
6.4.1. Periodic Threshold Events . . . . . . . . . . . . . . 33
6.4.2. Non-Periodic Threshold Events . . . . . . . . . . . . 35
7. YANG Data Model . . . . . . . . . . . . . . . . . . . . . . . 36
8. YANG Data Trees . . . . . . . . . . . . . . . . . . . . . . . 60
9. Manageability Considerations . . . . . . . . . . . . . . . . 62
10. Security Considerations . . . . . . . . . . . . . . . . . . . 63
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 65
12.1. Normative References . . . . . . . . . . . . . . . . . . 65
12.2. Informative References . . . . . . . . . . . . . . . . . 66
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68
1. Introduction
Performance Monitoring (PM) data generated by a Network Element (NE)
undergoes a systematic processing pipeline that transforms raw
observations into actionable operational insights. Traditionally, PM
data has been managed through pull-based mechanisms such as SNMP
polling, but the increasing scale and dynamic nature of modern
networks require a more efficient, streaming-oriented approach.
This document distinguishes three functional stages of the PM
processing pipeline -- Sampling, Collection, and Reporting -- and
defines a YANG data model [RFC7950] for the Collection stage,
referred to in this document as the PM collection model.
The Collection-stage data and notifications defined in this model can
be retrieved by clients via pull-based mechanisms (e.g., NETCONF get-
data operations) or delivered via push-based subscription mechanisms.
When push-based delivery is used, the IETF subscribed- notifications
framework [RFC8639], its YANG Push extension for datastore updates
[RFC8641], and the NETCONF binding for dynamic subscriptions
[RFC8640] are applicable. These three specifications together are
referred to in the remainder of this document as the push-based
subscription mechanisms.
1.1. PM Processing Pipeline in a Network Element
The PM processing pipeline considered in this document comprises the
following three stages, as illustrated in Figure 1. Stage 2
(Collection) is the scope of this document.
Yoon & You Expires 7 May 2027 [Page 3]
Internet-Draft PM Collection YANG November 2026
+----------------+ +==================+ +----------------+
| Stage 1 | | Stage 2 | | Stage 3 |
| Sampling |--->| Collection |--->| Reporting |
| | | (this document) | | |
| - Physical | | - Counts | | - YANG-Push |
| layer | | - Snapshot | | RFC 8639/ |
| - OWAMP/TWAMP/ | | - Tidemarks | | 8640/8641 |
| STAMP/IOAM | | - Thresholding | | - OS/NDT/ |
| - Sensors | | | | AI APP |
| | | | | |
+----------------+ +==================+ +----------------+
raw samples processed PM data delivery
Figure 1: PM Processing Pipeline
Stage 1 -- Sampling. This stage observes signals or protocol
behaviours to produce raw samples. It encompasses direct observation
of physical-layer signals as well as various OAM-based techniques.
As examples of active measurement protocols that may be used in this
stage, OWAMP [RFC4656], TWAMP [RFC5357], and STAMP [RFC8762] inject
synthetic probe packets to measure one-way or round-trip delay,
packet loss, and delay variation, while In-situ OAM (IOAM) [RFC9197]
records performance data directly within user packets as they
traverse the network.
The Stage 1 sampling techniques above fall into the measurement
method categories defined by the IPPM framework [RFC7799]. Active
methods such as OWAMP [RFC4656], TWAMP [RFC5357], and STAMP [RFC8762]
generate and inject synthetic test traffic. Hybrid methods such as
IOAM [RFC9197] augment or observe existing user traffic in transit.
Passive methods, such as direct observation of physical-layer signals
and the reading of protocol counters (for example interface packet
counters), draw solely from traffic and signals already present,
without generating test packets. Environmental sensor readings (for
example temperature or voltage) are not classified by this axis,
because no packet or signal observation is involved.
Yoon & You Expires 7 May 2027 [Page 4]
Internet-Draft PM Collection YANG November 2026
The Collection stage defined in this document is method-agnostic: the
counts, snapshot, and tidemarks collection types apply identically to
samples produced by any of these methods, and the model neither
performs nor prescribes the Stage 1 measurement. However, because
the operational meaning of a value depends on how it was measured --
for example, an active delay measurement reflects the experience of
synthetic probes, whereas a hybrid measurement reflects that of real
user traffic -- the measurement method is retained as metadata so
that a client can interpret, filter, and aggregate collected values
correctly. How this metadata is modelled is described in
Section 2.3.
Stage 2 -- Collection. This stage processes raw samples into
summarised statistics over defined intervals and manages their
retention. Historically, PM collection mechanisms based on SNMP MIBs
used the performance-history textual conventions defined in
[RFC3593], with the high-capacity variants in [RFC3705]. The
Collection stage modelled in this document follows the common
equipment management function requirements of ITU-T G.7710 and
supports three collection types -- Counts, Snapshot, and Tidemarks --
together with threshold evaluation and the associated periodic and
non-periodic events.
Stage 3 -- Reporting. This stage delivers Collection-stage data and
notifications to external management systems or controllers. While
traditional pull-based retrieval remains available, this document
assumes the push-based subscription mechanisms introduced above
([RFC8639], [RFC8641], [RFC8640]). The role of the Collection-stage
models defined here is to provide the data structures that those
mechanisms carry. Typical clients of this Reporting stage include
operations systems (OS), network digital twins (NDT), and AI-driven
applications (AI APP), as illustrated in Figure 2.
Yoon & You Expires 7 May 2027 [Page 5]
Internet-Draft PM Collection YANG November 2026
+------+ +-----+ +--------+
| OS | | NDT | ... | AI APP |
+---+--+ +--+--+ +----+---+
| | |
| PM data and notifications
| via YANG-Push (RFC 8639/8640/8641)
| | |
+---+--------+-------------+---+
| NE |
| +-----------------------+ |
| | EMF / Collection | |
| | (this document) | |
| +-----------------------+ |
+------------------------------+
OS: Operations System
NDT: Network Digital Twins
APP: Application
Figure 2: Network Architecture for PM Collection
The YANG data model specified in this document is implemented within
the Equipment Management Function (EMF) of an NE, as defined in ITU-T
G.7710. It is exposed at the NE's management interface and is
consumed by remote clients such as operations systems (OS), Physical
Network Controllers (PNCs), network digital twins (NDT), and AI-
driven applications. Throughout this document the term "client"
refers to any such consumer of the PM collection interface,
regardless of whether it acts as a controller, an analytics engine,
or an operator-facing management system.
The tree diagrams in this document use the notation defined in
[RFC8340].
1.2. Relationship to the IETF Performance Metric Framework
The three-stage pipeline described above aligns with the framework
for performance metric development given in [RFC6390]. The
Collection stage modelled in this document corresponds to the
Computed Performance Metrics described in Section 5.3 of [RFC6390]:
the Counts and Tidemarks collection types are temporal aggregations
(Section 5.3.1 of [RFC6390]) of base metrics over a collection
interval, while the Snapshot collection type is a sampled value
organised as a singleton in the sense of Section 5.6 of [RFC6390] and
the IPPM framework [RFC2330].
Figure 3 summarises how the three collection types map onto the
result organization of the IPPM framework.
Yoon & You Expires 7 May 2027 [Page 6]
Internet-Draft PM Collection YANG November 2026
+--------------------------------------------------------------------+
| Collection: counts | snapshot | tidemarks |
| |
| +--------------+ +-------------------------------------------+ |
| | Snapshot | | Computed Performance Metrics | |
| | | | (RFC 6390 Sec 5.3 / 5.3.1 aggregation) | |
| | singleton | | | |
| | | | +---------------+ +----------------+ | |
| | (directly | | | Counts | | Tidemarks | | |
| | sampled) | | | statistic | | statistic | | |
| | | | | (sum) | | (min / max) | | |
| | | | | | | | | |
| +--------------+ | +---------------+ +----------------+ | |
| +-------------------------------------------+ |
| |
+--------------------------------------------------------------------+
RFC 2330 Sec 11 / RFC 6390 Sec 5.6 organize results as:
singleton = elementary "atomic" value -> Snapshot
sample = a set of singletons (one interval)
statistic = value computed from a sample -> Counts, Tidemarks
Figure 3: Collection types mapped to RFC 6390 Computed
Performance Metrics and the RFC 2330 result organization
The base metrics aggregated by this model are produced in Stage 1
(Sampling) and are expected to be specified following the Performance
Metric Specification of Section 5.4 of [RFC6390]. This document does
not define or redefine those base metrics, nor does it introduce new
performance metrics or parameters; it identifies the operationally
important subset (counts, snapshot, and tidemarks) and defines the
YANG structures that compute, retain, and expose their aggregated
values over the configured collection intervals. The acceptable
ranges of sampling and collection intervals, and the required timing
accuracy called for in Section 5.4.2 of [RFC6390], are determined by
the parameter profiles defined in this document, rather than being
fixed by the YANG model itself.
Except where [RFC6390] is explicitly referenced, this document uses
the term "Sampling" for the Stage 1 activity described above and
"Collection" for the Stage 2 activity. A collection interval (YANG
node collection-interval) is the window over which sampled values are
aggregated within the Collection stage; it is distinct from the
sampling interval at which raw values are produced.
Yoon & You Expires 7 May 2027 [Page 7]
Internet-Draft PM Collection YANG November 2026
1.3. Motivation and Scope
The legacy SNMP-based collection conventions [RFC3593] [RFC3705] and
the associated pull-based polling architecture limit real-time
visibility and flexible interval design at the scale of modern
networks. The push-based subscription mechanisms [RFC8639] [RFC8640]
[RFC8641] provide an efficient and scalable alternative for streaming
management data, but those specifications define only the
subscription and notification mechanisms themselves and do not
prescribe the structure of the PM data being carried. A standardised
YANG data model is therefore needed at the Collection stage to bridge
low-level measurement data and high-level streaming subscriptions,
since existing YANG models tend to focus on static configuration or
simple state data and do not offer the structures required to express
counts, snapshot, and tidemarks collection together with profile-
based parameter grouping and threshold semantics.
A further motivation concerns which performance information to
collect and in what form. The IETF performance metric framework
[RFC6390] provides methods for defining and computing metrics, but
the space of possible computed metrics is effectively unbounded (for
example, averages, variances, or percentiles could all be derived).
ITU-T G.7710 [G7710] instead reflects several decades of operational
experience by fixing a deliberately small set of collection forms and
parameters: gauge measurements are limited to snapshots (an
instantaneous value) and tidemarks (the maximum and minimum), and
counts to a simple accumulation, rather than general statistical
aggregations; and the collected parameters are confined to an
operational set such as ES, SES, BBE, BBC, and UAS for maintenance
and quality-of-service purposes. The collection types are themselves
defined as the form in which results are stored, independent of the
collection interval. This document adopts that operationally-
validated minimal set, rather than attempting to enumerate all
statistically possible metrics, so that the resulting YANG model
expresses what network operators actually need to retain and expose
for fault management, maintenance, and SLA evaluation. This is also
why the model is parameter-agnostic in structure: it standardises the
collection forms (counts, snapshot, tidemarks) and leaves the
specific parameters to be referenced from [G7710] and related
Recommendations.
Yoon & You Expires 7 May 2027 [Page 8]
Internet-Draft PM Collection YANG November 2026
The scope of this document is therefore limited to the Collection
stage. Within that scope, this document specifies YANG data models
that enable: (a) flexible processing of performance metrics beyond
simple counts, including Snapshot and Tidemarks; (b) configurable
sampling and collection intervals that are not restricted to the
legacy 15-minute or 24-hour windows; and (c) data and notification
structure that supports flexible delivery of processed PM data to
management systems, compatible with both pull-based retrieval and
push-based subscription mechanisms.
The Collection-stage data and notifications defined here are
compatible with the existing YANG-Push framework ([RFC8639],
[RFC8640], [RFC8641]) for push-based delivery as well as with
traditional pull-based retrieval via NETCONF or RESTCONF; this
document does not define any new subscription or notification
mechanism, only the pm-threshold-events notification content, carried
over those existing mechanisms.
1.4. Requirements Language
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.
2. PM parameters
2.1. Types
Performance monitoring (PM) in networks encompasses a wide variety of
parameters that reflect operational health, service quality,
reliability, and environmental conditions. These parameters are used
across many technologies, network layers, and functional domains to
enable fault management, SLA compliance, trend analysis, predictive
maintenance, and operational optimization.
PM parameter types include but are not limited to:
* Classical transport and packet layer metrics: such as errored
seconds (ES), severely errored seconds (SES), unavailable seconds
(UAS), background block errors (BBE), background block counts
(BBC), delay, jitter, and packet loss, as defined in standards
like ITU-T G.7710, and others.
* Layer-specific metrics:
Yoon & You Expires 7 May 2027 [Page 9]
Internet-Draft PM Collection YANG November 2026
- Physical layer: optical power levels, laser bias current, loss
of signal
- Data link layer: Ethernet frame errors, FCS errors
- Network layer: dropped packets, route flaps
- Transport/Service layers: MPLS LSP statistics, OTN TCM/BIP
counters
* Network environment parameters: including temperature, humidity,
fan speed, voltage, and airflow. These are essential for
equipment safety, energy management, and predictive failure
analysis.
* Energy and sustainability metrics: such as power consumption,
energy efficiency indicators, and cooling utilization, aligned
with emerging sustainability standards and operational efficiency
goals.
* Security and integrity parameters: such as pointer justification
events (PJE), synchronization loss, or intrusion anomaly flags.
* Application-aware or SLA metrics: such as service availability,
throughput consistency, and application-layer latency.
* Mobile network-specific metrics: including radio link failures,
handover success/failure rates, RRC connection setup time, PDCP
discard rate, and throughput per bearer. These metrics are
critical for monitoring the performance of RAN, core, and edge
network components in 4G/5G mobile environments.
These parameters may be grouped flexibly within the YANG model using
parameter profiles that reflect shared characteristics, purpose, or
applicable network domains. The architecture supports extension
through identity-based typing to accommodate future parameter
definitions introduced by standard bodies like ITU-T, IEEE, IETF,
MEF, and TM Forum.
Yoon & You Expires 7 May 2027 [Page 10]
Internet-Draft PM Collection YANG November 2026
The data model defined in this document is parameter-agnostic: it
specifies how performance parameters are collected, aggregated, and
exposed, rather than defining the parameters themselves. Each
performance parameter is expected to be specified following the
Performance Metric Specification template of Section 5.4.4 of
[RFC6390] (metric name, description, method of measurement or
calculation, units, measurement point, and measurement timing). The
parameters listed above are illustrative and are not themselves
defined by this document; the specification of any such parameter is
left to the relevant standards body.
2.1.1. Parameter Identities
This module defines the base identity performance-parameter. The key
of each pm-parameter entry is an identityref whose base is this
identity. Specific parameters are defined as identities derived from
it in other modules; parameters of specific network technologies are
defined in the same way in other documents, by the relevant standards
body. Identity-based typing lets a server validate the parameters a
client configures and lets clients interpret collected values
consistently across vendors.
2.2. Profiles
+--rw parameter-profile* [name]
+--rw name profile-names
+--rw pm-parameter* [name]
+--rw name identityref
Figure 4: Parameter Profile Subtree
The YANG model defines the concept of a parameter profile to
logically group performance parameters that are commonly measured
together for a specific operational purpose. Each parameter profile
is represented as a list entry keyed by a name of type profile-names
(a string conforming to the format defined in the model). These
profiles serve as named collections of performance parameters and are
intended to facilitate streamlined configuration, management, and
reporting of measurement data across network elements and management
systems.
The use of parameter profiles improves operational efficiency by
allowing operators, applications, and controllers to activate or
reference a coherent set of parameters using a single profile
identifier. For example, a maintenance profile may group the error
counters of an interface that are monitored together for fault
detection, and a QoS profile may group delay, jitter, and loss
parameters used in service quality reporting. Parameter profiles
Yoon & You Expires 7 May 2027 [Page 11]
Internet-Draft PM Collection YANG November 2026
support role-based access control, operational alignment, and
measurement policy abstraction, enabling network operators and
analytics systems to tailor data collection and reporting according
to the needs of different users and services.
By modeling profiles as list entries keyed by a structured name
(profile-names type), the YANG design ensures extensibility and
vendor interoperability, allowing future profiles to be defined
without changes to the core data structures. This approach promotes
consistent configuration and integration across multi-vendor
environments and supports dynamic service assurance use cases where
parameter sets may vary by service type, SLA, or operational context.
2.2.1. Naming
Parameter profiles are named to reflect their operational purpose,
origin, applicable network domain, and, optionally, the primary
collection interval. This naming structure supports clarity,
modularity, and automation across diverse network and service layers.
The naming follows this format:
<source>-<network>-<purpose>[-<characteristic>]
Where:
* <source>: Standards body or organization
- Examples: itu, ieee, ietf, example, vendorX
* <network>: Network domain or layer
- Examples: transport, access, core, ip, mpls, ethernet, otn,
wdm, flexo
* <purpose>: Intended use or function
- Examples: maintenance, qos, availability, sla, compliance,
analytics
* <characteristic> (optional): Optional qualifying information
- Examples: 15min, 24hr, high-priority
Examples:
* example-ip-qos-15min
Yoon & You Expires 7 May 2027 [Page 12]
Internet-Draft PM Collection YANG November 2026
* example-ip-qos-24hr
* example-mobile-availability-24hr
* vendorx-otn-sla
Note: profile names that begin with ietf- are reserved for profiles
that IETF actually defines; placeholder examples in this document use
example- to avoid implying IETF endorsement of profiles not yet
specified.
The 15-minute interval provides granular, real-time monitoring,
allowing network operators to quickly detect and address short-term
issues such as spikes in latency or packet loss. It is particularly
useful for ensuring compliance with Service-Level Agreements (SLAs)
and for managing highly dynamic networks where rapid changes can
occur. In contrast, the 24-hour interval is used for long-term
performance monitoring and trend analysis, helping operators
understand overall network health, detect slow-developing issues, and
plan for future capacity needs. This longer interval offers a
broader view of the network's performance over a full day, making it
ideal for strategic planning and infrastructure maintenance.
Together, these intervals enable both immediate responses to network
conditions and long-term network optimization.
2.3. Measurement Method Metadata
Each pm-parameter entry MAY carry an optional measurement-method leaf
that records the IPPM measurement method [RFC7799] by which the
parameter's Stage 1 samples are produced. The leaf is an identityref
whose base identity is measurement-method, with the derived
identities active, passive, and hybrid corresponding to the
categories of [RFC7799].
+--rw pm-parameter* [name]
+--rw name identityref
+--rw measurement-method? identityref
+--rw sampling-interval* [id]
...
Figure 5: measurement-method leaf within pm-parameter
Yoon & You Expires 7 May 2027 [Page 13]
Internet-Draft PM Collection YANG November 2026
The leaf is optional for three reasons. First, it preserves backward
compatibility with servers and configurations that do not populate
it. Second, some parameters (for example environmental sensor values
such as temperature or voltage) are not meaningfully classified by
the active/passive/hybrid axis. Third, the Collection stage operates
independently of the measurement method, so the leaf conveys
interpretation metadata rather than affecting collection behaviour.
The measurement method corresponds to the "method of measurement or
calculation" element of the Performance Metric Specification template
in Section 5.4.4 of [RFC6390]. Carrying it alongside the collected
value lets a client (a) interpret the value in the correct
operational context, (b) keep homogeneous data sets when comparing or
aggregating values across network elements, and (c) reason about the
intrusiveness of the measurement, since active methods inject
synthetic traffic while passive methods do not.
Because the leaf resides within pm-parameter, the method information
is inherited by every sampling interval, collection interval, and
collection type beneath that parameter, and is therefore associated
with the corresponding value both in pull-based retrieval and in
push-based notifications, without requiring any per-notification tag.
3. Periodic Collection
3.1. Interval Timing
+--rw sampling-interval* [id]
+--rw id string
+--rw interval-value? uint32
+--rw unit? time-interval-unit
+--rw collection-interval* [id]
+--rw id string
+--rw interval-value? uint32
+--rw unit? time-interval-unit
Figure 6: Sampling and Collection Intervals Subtree
Interval timing parameters are key components of network performance
monitoring, offering standardized definitions for the time-related
aspects of sampling, collection, and reporting performance data.
These parameters apply to the three main collection types for network
equipment: counts, snapshot, and tidemarks. They include the
sampling interval, collection interval, and uniform time, all of
which support consistent, accurate, and systematic performance
monitoring and management.
Yoon & You Expires 7 May 2027 [Page 14]
Internet-Draft PM Collection YANG November 2026
Sampling interval defines the period at which network performance
data is collected at consistent, predetermined time points. It
ensures the continuous and timely capture of performance metrics,
enabling accurate assessments of network conditions. The sampled
values are the input of the Collection stage, so collection is always
performed on the samples of a sampling interval: in the model, a
collection interval exists only within a sampling interval entry.
Collection interval specifies the duration over which sampled
performance data is aggregated or statistically processed. It helps
manage large volumes of data by summarizing it into meaningful
indicators for analysis, anomaly detection, and resource management.
Both interval values are positive.
Uniform time is a fixed, predefined point within each collection
interval at which a snapshot is taken. It enables a consistent and
instantaneous view of network performance across intervals, without
requiring data aggregation. This approach facilitates quick
diagnostics and synchronization across monitoring systems.
The acceptable ranges of sampling and collection intervals, and the
timing accuracy required for a given parameter, are not fixed by this
YANG model. As noted in Section 5.4.2 of [RFC6390], these
constraints are part of the specification of each performance metric;
in this document they are determined by the parameter profile in use,
and a server advertises the intervals it supports as part of its
capabilities.
3.1.1. Use Cases
The hierarchical design of the ietf-pm-collection YANG module, where
a performance parameter can be associated with one or more sampling
intervals and each sampling interval can be associated with multiple
collection intervals and collection types, supports a wide range of
operational objectives. A key benefit of this structure is that,
even when the sampling interval is fixed, different collection
intervals can be used to derive distinct operational views of the
same parameter. The collection type is selected to match the
semantics of the monitored parameter: counts for cumulative event
parameters, tidemarks for varying parameters where extremes are
operationally significant, and snapshot for point-in-time operating
state.
In a Network Operations Center (NOC), the number of lost packets can
be sampled every second and processed with multiple collection
intervals using the counts collection type. A 1-minute collection
interval supports rapid fault indication, enabling fast recognition
of service degradation. A 15-minute collection interval supports
Yoon & You Expires 7 May 2027 [Page 15]
Internet-Draft PM Collection YANG November 2026
routine maintenance monitoring and aligns with established
operational practice. A 24-hour collection interval supports daily
QoS reporting and provides a broader view of service quality over
time.
For latency monitoring in a NOC, a parameter may be sampled every 500
milliseconds and processed using the tidemarks collection type. A
1-minute collection interval helps detect short-lived delay spikes.
A 30-minute collection interval helps identify recurring burst
patterns that affect path stability. A 24-hour collection interval
provides a daily worst-case view of path quality, supporting
operational assessment of persistent delay behavior.
For digital twin applications, packet delay variation (PDV) may be
sampled every 100 milliseconds and processed using the tidemarks
collection type. A 1-minute collection interval provides a
synchronization stability envelope that helps the digital twin remain
closely aligned with the physical network. A 5-minute collection
interval supports feedback-loop tuning by capturing short-term
variation patterns that influence control adjustments. A 1-hour
collection interval supports model calibration by providing longer-
span information about the range of delay variation observed in
operation.
Environmental monitoring also benefits from the same hierarchical
timing structure. For example, temperature may be sampled every 10
seconds and processed using the snapshot collection type. A 1-minute
collection interval supports a current operating state check. A
15-minute collection interval supports periodic baseline comparison.
A 24-hour collection interval supports daily fleet-wide correlation
at a common observation point, helping operators compare equipment
behavior across systems and sites.
Similar timing structures can also support AI/ML pipelines, where
short, medium, and long collection intervals applied to the same
sampled parameter provide feature sets for anomaly detection, trend
analysis, and model training within a single analytics application.
Yoon & You Expires 7 May 2027 [Page 16]
Internet-Draft PM Collection YANG November 2026
These examples show that the same sampling interval can support
multiple operational purposes when paired with different collection
intervals, and that the collection type should match the semantics of
the monitored parameter. The hierarchical list structure, where
parameters contain multiple sampling intervals and each sampling
interval defines one or more collection intervals and collection
types, supports operational flexibility, avoids configuration
duplication, and enables fine-grained control of measurement
strategies. The use cases summarized in Table 1 are consistent with
the collection types defined in Section 3.2, where counts represent
cumulative event occurrences, snapshot represents point-in-time
values, and tidemarks represent interval extremes.
Yoon & You Expires 7 May 2027 [Page 17]
Internet-Draft PM Collection YANG November 2026
+================+=======+==========+===========+==============+
| Client (param) | Samp. | Coll. | Type | Purpose |
| | | interval | | |
+================+=======+==========+===========+==============+
| NOC (loss) | 1s | 1min | counts | Rapid fault |
| | | | | alert |
+----------------+-------+----------+-----------+--------------+
| | 1s | 15min | counts | Maintenance |
+----------------+-------+----------+-----------+--------------+
| | 1s | 24hr | counts | Daily QoS |
| | | | | report |
+----------------+-------+----------+-----------+--------------+
| NOC (latency) | 500ms | 1min | tidemarks | Delay spike |
| | | | | detect |
+----------------+-------+----------+-----------+--------------+
| | 500ms | 30min | tidemarks | Burst |
| | | | | pattern obs. |
+----------------+-------+----------+-----------+--------------+
| | 500ms | 24hr | tidemarks | Daily worst- |
| | | | | case |
+----------------+-------+----------+-----------+--------------+
| Digital Twin | 100ms | 1min | tidemarks | Sync |
| | | | | stability |
+----------------+-------+----------+-----------+--------------+
| (PDV) | 100ms | 5min | tidemarks | Feedback |
| | | | | tuning |
+----------------+-------+----------+-----------+--------------+
| | 100ms | 1hr | tidemarks | Model |
| | | | | calibration |
+----------------+-------+----------+-----------+--------------+
| NOC (temp) | 10s | 1min | snapshot | State check |
+----------------+-------+----------+-----------+--------------+
| | 10s | 15min | snapshot | Periodic |
| | | | | baseline |
+----------------+-------+----------+-----------+--------------+
| | 10s | 24hr | snapshot | Fleet-wide |
| | | | | daily |
+----------------+-------+----------+-----------+--------------+
Table 1: Use cases by sampling interval, collection
interval, and collection type
3.2. Collection Types
Yoon & You Expires 7 May 2027 [Page 18]
Internet-Draft PM Collection YANG November 2026
+--rw collection-types
+--rw counts!
| +--rw transient-condition-config
| | +--rw transient-threshold? uint32
| +--rw standing-condition-config
| | +--rw standing-threshold? uint32
| | +--rw reset-threshold? uint32
| +--ro collection-value? uint32
+--rw snapshot!
| +--rw uniform-time-config
| | +--rw offset-value? uint32
| | +--rw unit? time-interval-unit
| +--rw threshold-config
| | +--rw high-threshold? uint32
| | +--rw low-threshold? uint32
| +--ro collection-value? uint32
+--rw tidemarks!
+--rw threshold-config
| +--rw high-threshold? uint32
| +--rw low-threshold? uint32
+--ro high-collection-value? uint32
+--ro low-collection-value? uint32
Figure 7: Collection Types Subtree
The collection types establish a focused and efficient framework for
network performance monitoring by specifying three core collection
types: counts, snapshot, and tidemarks.
Each collection type is a presence container. The presence of the
counts, snapshot, or tidemarks container in a collection-interval
entry indicates that the server collects that collection type for the
parameter over that interval; its absence indicates that it does not.
A client therefore selects the collection types of a parameter by
creating the corresponding containers, and a profile can restrict a
parameter to a subset of the three types (for example, counts only
for a QoS profile).
This intentional limitation supports key objectives such as
implementation simplicity, operational efficiency, and cross-vendor
interoperability. It emphasizes real-time network monitoring,
favoring instantaneous or interval-based metrics over complex
statistical calculations. The counts and snapshot collection types
provide immediate operational data without incurring the processing
overhead associated with metrics like averages and variances. These
statistical measures require significant aggregation logic, which can
vary across implementations and devices. By keeping computation
within network elements minimal, the approach reduces both processing
Yoon & You Expires 7 May 2027 [Page 19]
Internet-Draft PM Collection YANG November 2026
and memory overhead, maintaining lightweight implementations. It
establishes a clear separation between raw data collection (handled
by network elements) and deeper analysis (delegated to external
management systems). This separation not only simplifies device
requirements but also enables more consistent and flexible analytics
in centralized systems, which are better equipped to apply
standardized analytical frameworks.
Limiting collection types also contributes to energy efficiency by
reducing the operational burden on Network Elements (NEs), while
offloading data analysis to external management applications.
Despite the simplicity, the selected collection types offer
sufficient expressiveness to support comprehensive performance
monitoring without excessive resource use. They are specifically
optimized for the NE-to-client interface -- referred to as the
Southbound Interface (SBI) from a controller perspective (e.g.,
between a Physical Network Controller (PNC) and an NE), or
equivalently as the northbound management interface from the NE's
perspective -- to ensure as follows:
* Lightweight to implement
* Consistently supported across vendors
* Efficient for transport and storage in network management systems
The collection types are applicable to a wide range of monitored
objects, including both network topology elements (e.g., links,
tunnels) and physical equipment parameters (e.g., temperature,
voltage).
In terms of the performance metric framework of [RFC6390], the three
collection types correspond to the following operations, as
summarised in Table 2.
Yoon & You Expires 7 May 2027 [Page 20]
Internet-Draft PM Collection YANG November 2026
+============+=========================+=======================+
| Collection | operation | Note |
| type | | |
+============+=========================+=======================+
| counts | Temporal aggregation | Resets at the end of |
| | (Section 5.3.1): | each interval |
| | cumulative sum over the | |
| | collection interval | |
+------------+-------------------------+-----------------------+
| snapshot | Sampled value at a | Organised as a |
| | uniform time within the | singleton |
| | interval | (Section 5.6 of |
| | | [RFC6390]; [RFC2330]) |
+------------+-------------------------+-----------------------+
| tidemarks | Temporal aggregation | High and low values |
| | (Section 5.3.1): | retained per interval |
| | minimum and maximum | |
| | over the interval | |
+------------+-------------------------+-----------------------+
Table 2: Collection Types Mapped to RFC 6390
The counts and tidemarks types are computed (aggregated) metrics in
the sense of Section 5.3 of [RFC6390], whereas the snapshot type is a
directly sampled value rather than an aggregation.
3.2.1. Counts
The counts collection type in network performance monitoring tracks
the cumulative occurrences of specific events over a defined
collection interval, such as 15 minutes or 24 hours. This method
captures how frequently certain network activities, like errors or
transmission issues, occur, providing a historical view of recurring
problems. Counts reset at the end of each interval, ensuring that
every period starts with a fresh count for accurate monitoring.
Yoon & You Expires 7 May 2027 [Page 21]
Internet-Draft PM Collection YANG November 2026
The primary purpose of counts is to identify trends and patterns in
network behavior over time, helping operators detect anomalies or
areas where issues frequently arise. This collection type is
particularly useful for long-term analysis, enabling preventive
maintenance and optimizing network performance. Unlike instantaneous
values, counts focus on aggregation over time, making it easier to
understand the persistence or recurrence of faults. The data
gathered through counts helps in fault management and planning by
highlighting repeated errors, congestion, or performance degradation
that may affect service delivery. As a result, counts provide
network operators with actionable insights for troubleshooting and
capacity planning, ensuring smooth operation and reliability across
the network.
3.2.2. Snapshot
Snapshot is an instantaneous value taken at a specific point in time.
It captures the instantaneous value of specific performance
parameters at a regular, predefined point (uniform time) within each
time interval. Snapshot provides a "momentary view" of network
conditions, allowing operators to observe the network's status at
specific intervals. The data from these uniform-time snapshots is
then aggregated and analyzed to understand the immediate state across
the entire network. By taking snapshots simultaneously across all
network elements, operators can correlate data between different
parts of the network. Snapshots are collected at pre-determined
uniform times within fixed collection intervals. The uniform time
and fixed intervals can be configured based on the needs of the
network.
3.2.3. Tidemarks
The tidemarks collection type records the maximum (high tidemarks)
and minimum (low tidemarks) values that a performance parameter
reaches during a specified collection interval. This approach
captures the extreme values and performance fluctuations,
highlighting the best and worst conditions that occur within the
monitoring period. Tidemarks provide deeper insights by capturing
performance spikes or drops that may go unnoticed in average or
cumulative data, enabling precise troubleshooting of intermittent or
extreme conditions. For instance, while the average error rate over
a period may appear acceptable, a high tidemark could reveal
intermittent spikes in errors that require attention. Conversely, a
low tidemark may expose periods of severely degraded signal quality
or throughput.
Yoon & You Expires 7 May 2027 [Page 22]
Internet-Draft PM Collection YANG November 2026
4. Collection Interval Data Validity
The collection types above summarise the samples that were available
during a collection interval. When some of the expected Stage 1
samples are missing -- because of telemetry loss, partial node
support, a state reset, an equipment restart, a change of interval
timing, or suspension of collection -- the summarised value is still
a valid number, but it does not carry the same meaning as a value
computed over a complete interval. In particular, a numeric zero
computed from no valid samples must not be mistaken for a measured
zero. This section defines the metadata that lets a client tell
these cases apart. The metadata is part of the Collection stage
rather than of any delivery mechanism, so it applies identically to
pull-based retrieval and to push-based delivery.
+--rw collection-interval* [id]
+--rw id string
...
+--ro interval-data-status
| +--ro suspect-interval-flag? boolean
| +--ro interval-status? interval-status
| +--ro suspect-reason* identityref
| +--ro expected-sample-count? uint64 {coverage-counters}?
| +--ro received-sample-count? uint64 {coverage-counters}?
| +--ro elapsed-time? uint32
| +--ro interval-start-time? yang:date-and-time
| +--ro interval-end-time? yang:date-and-time
+--rw collection-types
...
Figure 8: Interval Data Status Subtree
4.1. Suspect Interval Flag
The suspect-interval-flag follows the suspect interval flag of ITU-T
G.7710. It is initialised to "false" at the start of each collection
interval and is set to "true" whenever the data stored for the
interval may be unreliable: when one or more periodic samples are
missing, when collection state is reset, when the equipment restarts
during the interval, when interval timing is changed, or when
collection is suspended. A client that reads or receives a value
together with a suspect flag of "true" knows that the value should be
treated with caution.
For the snapshot collection type the initialisation is inverted: the
flag is set to "true" at the start of the interval to indicate that
no snapshot has yet been taken, and is cleared to "false" once the
single snapshot has been taken at the uniform time.
Yoon & You Expires 7 May 2027 [Page 23]
Internet-Draft PM Collection YANG November 2026
4.2. Interval Status and the Meaning of Zero
The optional interval-status leaf refines the boolean flag into three
cases: "complete" (all expected samples were available), "partial"
(some samples were missing but at least one valid sample was
collected), and "unavailable" (no valid sample was collected).
Whenever interval-status is not "complete", the suspect-interval-flag
is "true". The optional suspect-reason leaf-list carries zero or
more reasons, when known, drawn from an extensible set of identities
(telemetry loss, partial node support, state reset, restart, time
adjustment, measurement suspension, measurement boundary, and
outage).
To remove the ambiguity between a measured zero and an absent value,
a server MUST NOT instantiate the collection-value leaf (the
collection-value of counts and snapshot, or the high and low
collection values of tidemarks) for an interval whose interval-status
is "unavailable". Because these leaves are optional, their absence
is the natural encoding of "no data", and a collection-value that is
present and zero is therefore always a measured zero. For a
"partial" interval the value is reported together with the coverage
counters described below, and a partial counts value is interpreted
as a lower bound on the true count for the interval.
4.3. Coverage, Elapsed Time, and Interval Timestamps
When the server implements the coverage-counters feature, the
expected-sample-count and received-sample-count leaves report how
many Stage 1 samples were expected (for a complete interval,
approximately the collection interval divided by the sampling
interval) and how many valid samples were actually collected, so that
a client can gauge the coverage of a partial interval. These sample
counts apply to any sampled parameter and are most meaningful for
periodically sampled (gauge) parameters such as tidemarks; they are
not defined by ITU-T G.7710 and generalize its coverage notion for
this model. The elapsed-time leaf gives the number of seconds of the
interval that have been processed by the measurement -- not the sum
of available time, since it advances during unavailable time as well.
The interval-start-time and interval-end-time leaves record when the
interval began and ended; interval-end-time is the end-of-interval
timestamp and is the authoritative measurement time, to be used for
correlation in preference to the notification envelope eventTime.
Yoon & You Expires 7 May 2027 [Page 24]
Internet-Draft PM Collection YANG November 2026
4.4. Retained Interval Data
This model distinguishes the current interval from retained
intervals. The current interval is the interval in progress; its
value (the collection-value of counts and snapshot, or the high and
low values of tidemarks) and its interval-data-status are always
available and are read or delivered as the interval advances. A
retained interval is a completed interval whose result the server
keeps for a bounded time after the interval ends.
This model does not require a server to retain completed intervals.
When results are delivered as each interval ends, retention of past
results is a client-side concern. When a server does retain
completed intervals, the number it keeps bounds both how many
completed intervals a client may read back and how long a reporting
period may be.
The validity metadata that describes an interval -- the suspect flag,
the sample coverage, the elapsed time, and the start and end
timestamps -- is carried in interval-data-status and accompanies the
value whether the interval is the current interval or a retained one,
so it is independent of how the data is delivered.
5. Thresholding
5.1. Periodic Thresholding
Periodic threshold events are triggered when the counts or gauge
value reaches a pre-defined threshold during periodic collection of
the counts, snapshot, and tidemarks collection types for performance
parameters.
The counts collection type has two types of threshold reporting
methods: transient and standing condition methods. The transient
condition method treats each collection interval separately. As soon
as a threshold is reached or crossed in a collection interval for a
given performance parameter, a threshold report (TR) is generated.
The standing condition method is optional. The standing condition is
raised, and a TR (Threshold Report) is generated, when the set
threshold is reached or crossed. The standing condition is cleared,
and a reset threshold report (RTR) is generated at the end of the
period when the current value is below or equal to the reset
threshold, provided that there was no unavailable time during that
period. In the terms of Section 4, this "no unavailable time"
condition is expressed by the suspect-interval-flag: an RTR is not
generated for an interval whose suspect-interval-flag is set.
Yoon & You Expires 7 May 2027 [Page 25]
Internet-Draft PM Collection YANG November 2026
For the gauge collection types ("snapshot" and "tidemarks"), an
overflow condition is determined and an out-of-range report is
generated as soon as the gauge value reaches or crosses the high
threshold. An underflow condition is determined and an out-of-range
report is generated as soon as the gauge value is at or below the low
threshold.
5.2. Non-Periodic Thresholding
Non-periodic threshold events are triggered regardless of the
collection types (counts, snapshot, or tidemarks). The following
parameters are used for non-periodic events.
* BUT (Begin Unavailable Time): The event marking the start of a
period when a network element or connection is unavailable.
* EUT (End Unavailable Time): The event marking the end of a period
when a network element or connection was unavailable.
* CSES (Consecutive Severely Errored Seconds): A sequence of
severely errored seconds (SES) detected consecutively within a
specified time interval. The reporting metrics include BUT, EUT,
and the count of errors during that period.
6. Data Access
Clients can access PM parameter values produced by the counts,
snapshot, and tidemarks collection types using either pull-based
retrieval or push-based subscription mechanisms. This section
provides practical examples for both access patterns. This document
does not define any new retrieval operation or subscription
mechanism; the examples below use only standard NETCONF operations
and YANG-Push RPCs and notifications. The data retrieved or
delivered is used for maintenance and Quality of Service (QoS)
monitoring in networks.
6.1. Example Module
The examples in this document use the example module shown in
Figure 9. It defines two example parameters: "ex:lost-packets", an
event parameter used with the counts collection type, and "ex:one-
way-delay", a gauge parameter measured with IOAM [RFC9197] and used
with the snapshot and tidemarks collection types. Parameters of
specific network technologies are defined in other documents in the
same way.
Yoon & You Expires 7 May 2027 [Page 26]
Internet-Draft PM Collection YANG November 2026
module example-pm-parameters {
yang-version 1.1;
namespace "urn:example:pm-parameters";
prefix ex;
import ietf-pm-collection {
prefix pm-co;
reference
"RFC XXXX: A YANG Data Model for Performance Monitoring (PM)
Collection";
}
organization
"Example organization";
contact
"Example contact";
description
"This module defines example performance parameters, derived
from the performance-parameter base identity of
ietf-pm-collection, for use in the examples of this
document only. It is not intended for implementation.
Parameters of specific network technologies are defined in
other documents in the same way.";
revision 2026-10-29 {
description
"Initial revision.";
reference
"RFC XXXX: A YANG Data Model for Performance Monitoring (PM)
Collection";
}
identity lost-packets {
base pm-co:performance-parameter;
description
"Example event parameter: the number of packets lost in
each sampling interval. It is used with the counts
collection type.";
}
identity one-way-delay {
base pm-co:performance-parameter;
description
"Example gauge parameter: the mean one-way delay, in
microseconds, of the packets measured with In situ OAM
(IOAM) in each sampling interval. It is used with the
snapshot and tidemarks collection types.";
reference
Yoon & You Expires 7 May 2027 [Page 27]
Internet-Draft PM Collection YANG November 2026
"RFC 9197: Data Fields for In Situ Operations,
Administration, and Maintenance (IOAM)";
}
}
Figure 9: Example Module Used in the Examples
6.2. Pull-Based Polling
The operational state data defined in this document can be retrieved
by clients using standard NETCONF or RESTCONF operations, providing a
pull-based access pattern analogous to traditional SNMP polling.
In traditional SNMP-based PM collection, a management system
periodically issues GET or GET-BULK requests to retrieve counter
values from the agent's MIB, such as the performance-history MIBs
defined in [RFC3593] and [RFC3705]. The YANG data model defined here
provides equivalent data structures accessible via NETCONF <get-data>
operations [RFC8526] against the operational datastore [RFC8342], or
via RESTCONF HTTP GET requests, at any polling interval chosen by the
client.
The collection-value leaf (config false) in the counts collection
type, and the corresponding value leaves in snapshot and tidemarks,
are read-only operational state nodes that reflect the current
accumulated or instantaneous PM values within the active collection
interval. These leaves are the YANG equivalents of SNMP counter and
gauge objects in classical PM MIBs.
Figure 10 shows a NETCONF <get-data> request that retrieves the
current count of the ex:lost-packets parameter (see Section 6.1) in
the example-ip-qos-15min profile, sampled every second over a
15-minute collection interval. A client may issue this request at
any time to read the in-progress counter value, or at the end of each
collection interval to collect the final result, replicating the
behavior of a traditional SNMP polling cycle.
Yoon & You Expires 7 May 2027 [Page 28]
Internet-Draft PM Collection YANG November 2026
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="401">
<get-data
xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
<datastore>ds:operational</datastore>
<subtree-filter>
<pm-periodic-collection
xmlns="urn:ietf:params:xml:ns:yang:ietf-pm-collection"
xmlns:ex="urn:example:pm-parameters">
<parameter-profile>
<name>example-ip-qos-15min</name>
<pm-parameter>
<name>ex:lost-packets</name>
<sampling-interval>
<id>1s</id>
<collection-interval>
<id>15min</id>
<collection-types>
<counts>
<collection-value/>
</counts>
</collection-types>
</collection-interval>
</sampling-interval>
</pm-parameter>
</parameter-profile>
</pm-periodic-collection>
</subtree-filter>
</get-data>
</rpc>
Figure 10: Pull-Based Polling Request Example (NETCONF get-data)
Figure 11 shows the corresponding reply, in which the server returns
the current count of 7 accumulated during the collection interval in
progress. This is equivalent to the value that a classical SNMP GET
would retrieve from a performance-history MIB object.
Yoon & You Expires 7 May 2027 [Page 29]
Internet-Draft PM Collection YANG November 2026
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="401">
<data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda">
<pm-periodic-collection
xmlns="urn:ietf:params:xml:ns:yang:ietf-pm-collection"
xmlns:ex="urn:example:pm-parameters">
<parameter-profile>
<name>example-ip-qos-15min</name>
<pm-parameter>
<name>ex:lost-packets</name>
<sampling-interval>
<id>1s</id>
<collection-interval>
<id>15min</id>
<collection-types>
<counts>
<collection-value>7</collection-value>
</counts>
</collection-types>
</collection-interval>
</sampling-interval>
</pm-parameter>
</parameter-profile>
</pm-periodic-collection>
</data>
</rpc-reply>
Figure 11: Pull-Based Polling Reply Example (NETCONF get-data)
6.3. Periodic Events
The YANG-Push subscription model, as defined in [RFC8641], enables
clients to subscribe to periodically collected PM data from network
elements. This model supports dynamic subscription establishment,
modification, and termination for real-time streaming of PM data.
Clients can specify subscription parameters including the target
datastore (operational), encoding format (XML/JSON), and filtering
criteria to receive only relevant performance metrics. The
subscription mechanism allows for configurable update periods,
enabling both high-frequency monitoring and long-term trend analysis
(e.g., 24-hour intervals). Network elements generate periodic event
notifications containing the requested PM data, which clients can
process for real-time monitoring, historical analysis, or triggering
automated responses based on performance thresholds.
Figure 12 shows a periodic subscription [RFC8641] to the operational
datastore for the ex:lost-packets parameter in the example-ip-qos-
15min profile. The XPath filter selects the 15-minute collection
Yoon & You Expires 7 May 2027 [Page 30]
Internet-Draft PM Collection YANG November 2026
interval entry, sampled every second, including its collection values
and interval data status. The period is expressed in centiseconds:
90000 (900 seconds), so that an update is sent once per collection
interval.
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="101">
<establish-subscription
xmlns=
"urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"
xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push"
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
<yp:datastore>ds:operational</yp:datastore>
<yp:datastore-xpath-filter
xmlns:pm-co="urn:ietf:params:xml:ns:yang:ietf-pm-collection"
xmlns:ex="urn:example:pm-parameters">
/pm-co:pm-periodic-collection/
parameter-profile[name='example-ip-qos-15min']/
pm-parameter[name='ex:lost-packets']/
sampling-interval[id='1s']/
collection-interval[id='15min']
</yp:datastore-xpath-filter>
<encoding>encode-xml</encoding>
<yp:periodic>
<yp:period>90000</yp:period>
<yp:anchor-time>2026-07-01T00:00:00Z</yp:anchor-time>
</yp:periodic>
</establish-subscription>
</rpc>
Figure 12: Periodic Event Subscription Example
Figure 13 shows the resulting "push-update" notification [RFC8641]
for the subscription, whose identifier returned by the server is 39.
It reports the counts collection value of the ex:lost-packets
parameter in the example-ip-qos-15min profile, sampled every second
and aggregated over a 15-minute interval. The collected value (10)
represents the total number of lost packets in that period. The
accompanying interval-data-status shows that the interval is complete
and not suspect, so the value is a fully measured result.
Yoon & You Expires 7 May 2027 [Page 31]
Internet-Draft PM Collection YANG November 2026
<notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2026-07-01T00:15:00Z</eventTime>
<push-update xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push">
<id>39</id>
<datastore-contents>
<pm-periodic-collection
xmlns="urn:ietf:params:xml:ns:yang:ietf-pm-collection"
xmlns:ex="urn:example:pm-parameters">
<parameter-profile>
<name>example-ip-qos-15min</name>
<pm-parameter>
<name>ex:lost-packets</name>
<sampling-interval>
<id>1s</id>
<collection-interval>
<id>15min</id>
<interval-value>15</interval-value>
<unit>minute</unit>
<interval-data-status>
<suspect-interval-flag
>false</suspect-interval-flag>
<interval-status>complete</interval-status>
</interval-data-status>
<collection-types>
<counts>
<collection-value>10</collection-value>
</counts>
</collection-types>
</collection-interval>
</sampling-interval>
</pm-parameter>
</parameter-profile>
</pm-periodic-collection>
</datastore-contents>
</push-update>
</notification>
Figure 13: Periodic Update Notification Example (push-update)
6.4. Threshold Events
Threshold event subscriptions enable clients to receive immediate
notifications when performance metrics cross predefined thresholds,
providing proactive monitoring capabilities. The threshold events
defined in this document are carried in the "pm-threshold-events"
YANG notification; they are events, not datastore data. A client
therefore receives them by subscribing to an event stream, such as
Yoon & You Expires 7 May 2027 [Page 32]
Internet-Draft PM Collection YANG November 2026
the "NETCONF" event stream, using subscribed notifications [RFC8639],
rather than by a YANG-Push datastore subscription [RFC8641].
6.4.1. Periodic Threshold Events
+--ro counts-transient
| +--ro event-type? enumeration
| +--ro event-occurred? boolean
| +--ro event-time? yang:date-and-time
+--ro counts-standing
| +--ro event-type? enumeration
| +--ro event-occurred? boolean
| +--ro event-time? yang:date-and-time
+--ro snapshot
| +--ro event-type? enumeration
| +--ro event-occurred? boolean
| +--ro event-time? yang:date-and-time
+--ro tidemarks
+--ro event-type? enumeration
+--ro event-occurred? boolean
+--ro event-time? yang:date-and-time
Figure 14: Periodic Threshold Events Subtree
When a performance parameter exceeds or falls below configured
thresholds for the periodic collection types of counts, snapshot, and
tidemarks, the network element generates event-driven notifications
containing the threshold crossing event type and occurrence time
(parameter values at the time of the event can be read from the
operational datastore if needed). This mechanism supports four types
of threshold events, reported in the "counts-transient", "counts-
standing", "snapshot", and "tidemarks" containers: transient
threshold crossings of counts, standing threshold reports (TR and
RTR) of counts, and out-of-range crossings of snapshot and tidemarks
values. These events enable rapid response to network performance
degradation and automated fault management. The threshold event
subscription complements periodic subscriptions by providing real-
time alerts for critical performance issues that require immediate
attention.
Figure 15 shows an example of the NETCONF request to subscribe to all
pm-threshold-events notifications in the ietf-pm-collection model on
the "NETCONF" event stream. No datastore and no period are given,
because event notifications are sent when the events occur.
Yoon & You Expires 7 May 2027 [Page 33]
Internet-Draft PM Collection YANG November 2026
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="202">
<establish-subscription
xmlns=
"urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
<stream>NETCONF</stream>
<stream-xpath-filter
xmlns:pm-co="urn:ietf:params:xml:ns:yang:ietf-pm-collection">
/pm-co:pm-threshold-events
</stream-xpath-filter>
<encoding>encode-xml</encoding>
</establish-subscription>
</rpc>
Figure 15: Threshold Event Subscription Example
Figure 16 reports a high-OOR-event threshold crossing for the
tidemarks collection type of the ex:one-way-delay parameter in the
example-ip-qos-15min profile, with 1-second sampling and 15-minute
collection interval. It shows the event type, occurrence, and
timestamp as defined in the YANG model.
Yoon & You Expires 7 May 2027 [Page 34]
Internet-Draft PM Collection YANG November 2026
<notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2026-07-01T00:05:23Z</eventTime>
<pm-threshold-events
xmlns="urn:ietf:params:xml:ns:yang:ietf-pm-collection"
xmlns:ex="urn:example:pm-parameters">
<periodic-events>
<parameter-profile>
<name>example-ip-qos-15min</name>
<pm-parameter>
<name>ex:one-way-delay</name>
<sampling-interval>
<id>1s</id>
<interval-value>1</interval-value>
<unit>second</unit>
<collection-interval>
<id>15min</id>
<interval-value>15</interval-value>
<unit>minute</unit>
<event-types>
<tidemarks>
<event-type>High-OOR-event</event-type>
<event-occurred>true</event-occurred>
<event-time>2026-07-01T00:05:23Z</event-time>
</tidemarks>
</event-types>
</collection-interval>
</sampling-interval>
</pm-parameter>
</parameter-profile>
</periodic-events>
</pm-threshold-events>
</notification>
Figure 16: Threshold Event Notification Example
6.4.2. Non-Periodic Threshold Events
Yoon & You Expires 7 May 2027 [Page 35]
Internet-Draft PM Collection YANG November 2026
+--ro non-periodic-events
+--ro BUT-event
| +--ro event-occurred? boolean
| +--ro event-time? yang:date-and-time
+--ro EUT-event
| +--ro event-occurred? boolean
| +--ro event-time? yang:date-and-time
| +--ro duration? uint32
+--ro CSES-event
+--ro event-occurred? boolean
+--ro start? yang:date-and-time
+--ro end? yang:date-and-time
+--ro duration? uint32
+--ro error-count? uint32
Figure 17: Non-Periodic Threshold Events Subtree
Non-periodic threshold event subscriptions provide immediate
notifications for critical network availability and error conditions
that occur independently of regular collection intervals. These
subscriptions monitor for specific events such as BUT, EUT, and CSES
that indicate significant network performance degradation or service
interruptions. When these events occur, the network element
generates immediate notifications containing event details, timing
information, and duration data. This subscription type enables
proactive network management by providing real-time awareness of
critical network conditions that require immediate operator attention
or automated intervention. Non-periodic threshold events complement
periodic monitoring by capturing exceptional conditions that may not
be detected through regular interval-based collection.
7. YANG Data Model
The YANG module for PM collection is defined below. It imports ietf-
yang-types [RFC6991].
<CODE BEGINS> file "ietf-pm-collection@2026-10-29.yang"
module ietf-pm-collection {
yang-version 1.1;
namespace
"urn:ietf:params:xml:ns:yang:ietf-pm-collection";
prefix pm-co;
import ietf-yang-types {
prefix yang;
reference "RFC 6991: Common YANG Data Types";
}
Yoon & You Expires 7 May 2027 [Page 36]
Internet-Draft PM Collection YANG November 2026
organization
"IETF Benchmarking & Performance Measurements (bpm)
Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/bpm/>
Editor: Bin Yeong Yoon <mailto:byyun@etri.re.kr>";
description
"This YANG module defines a data model for the collection of
performance monitoring (PM) data in network equipment, based
on ITU-T G.7710. It specifies three core collection types:
counts (cumulative events), snapshot (instantaneous values),
and tidemarks (extreme values).
The module enables proactive network monitoring through
configurable sampling and collection intervals, supporting
both high-frequency real-time monitoring and long-term trend
analysis. It provides threshold event notifications for both
periodic collection and non-periodic events (BUT, EUT,
CSES).
The module defines the base identity 'performance-parameter'
from which the identities of specific performance parameters
are derived in other modules, and the 'collection-type'
typedef used by other modules to refer to the three
collection types.
The collected data can be retrieved by clients via
pull-based mechanisms (e.g., NETCONF get-data) or delivered
via push-based subscription mechanisms (e.g., YANG-Push).
The design supports AI-driven applications, network digital
twins, and dynamic network environments by enabling multiple
simultaneous views of the same performance parameter with
different temporal resolutions.
Copyright (c) 2026 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Revised BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC
itself for full legal notices.";
Yoon & You Expires 7 May 2027 [Page 37]
Internet-Draft PM Collection YANG November 2026
revision 2026-10-29 {
description
"Initial revision.";
reference
"RFC XXXX: A YANG Data Model for Performance Monitoring (PM)
Collection";
}
/*
* TYPEDEFs
*/
typedef profile-names {
type string {
pattern '[a-zA-Z][a-zA-Z0-9_-]*-[a-zA-Z][a-zA-Z0-9_-]*-'
+ '[a-zA-Z][a-zA-Z0-9_-]*(-[a-zA-Z][a-zA-Z0-9_-]*)?';
}
description
"Parameter profile name following the format:
<source>-<network>-<purpose>[-<characteristic>]
Where:
- <source>: Standards body or organization
(e.g., itu, ieee, ietf)
- <network>: Network domain or layer
(e.g., transport, access, core)
- <purpose>: Intended use or function
(e.g., maintenance, qos, availability)
- <characteristic>: Optional qualifying information
(e.g., 15min, 24hr, high-priority)
Examples:
- example-ip-qos-15min
- example-ip-qos-24hr
- example-mobile-availability-24hr";
}
typedef time-interval-unit {
type enumeration {
enum millisecond {
description "Time interval in milliseconds.";
}
enum second {
description "Time interval in seconds.";
}
enum minute {
description "Time interval in minutes.";
}
enum hour {
Yoon & You Expires 7 May 2027 [Page 38]
Internet-Draft PM Collection YANG November 2026
description "Time interval in hours.";
}
enum day {
description "Time interval in days.";
}
}
description "Units for expressing time intervals.";
}
typedef collection-type {
type enumeration {
enum counts {
description
"Counts collection type: cumulative number of events
over the collection interval.";
}
enum snapshot {
description
"Snapshot collection type: instantaneous value taken at
the uniform time within the collection interval.";
}
enum tidemarks {
description
"Tidemarks collection type: maximum and minimum values
reached during the collection interval.";
}
}
description
"The three collection types. Used by other modules,
for example to advertise which collection types a server
supports for a parameter.";
reference
"ITU-T G.7710";
}
typedef interval-status {
type enumeration {
enum complete {
description
"The collection interval is complete: all expected
samples for the interval were available, so the
collected value represents a fully measured
interval.";
}
enum partial {
description
"The collection interval is partial: some expected
samples were missing (e.g., telemetry loss or partial
Yoon & You Expires 7 May 2027 [Page 39]
Internet-Draft PM Collection YANG November 2026
node support), but at least one valid sample was
collected. A partial 'counts' value is a lower bound
on the true count for the interval.";
}
enum unavailable {
description
"The collection interval is unavailable: no valid
sample was collected for the interval. In this case
the corresponding collection-value leaf is not
instantiated, so a reported value is never mistaken
for a measured zero.";
}
}
description
"Validity status of a collection interval. It
distinguishes a fully measured interval from one computed
over an incomplete set of samples, so that a client can
interpret the collected value correctly.";
}
/*
* FEATURES
*/
feature coverage-counters {
description
"Indicates that the server reports per-interval sample
coverage counters (expected-sample-count and
received-sample-count) within interval-data-status.";
}
/*
* PERFORMANCE PARAMETER IDENTITY
*/
identity performance-parameter {
description
"Base identity for performance monitoring parameters. The
key of each pm-parameter entry is an identity derived from
this base. Specific parameters are defined as derived
identities in other modules, for example modules that
define the parameters of specific network technologies.";
}
/*
* EVENT IDENTITIES
*/
identity periodic-events {
description
"Base identity for periodic event notifications.";
Yoon & You Expires 7 May 2027 [Page 40]
Internet-Draft PM Collection YANG November 2026
}
identity counts-transient {
base periodic-events;
description
"Notification for transient threshold events of the counts
collection type.";
}
identity counts-standing {
base periodic-events;
description
"Notification for standing threshold events of the counts
collection type.";
}
identity snapshot {
base periodic-events;
description
"Notification for threshold events of the snapshot
collection type.";
}
identity tidemarks {
base periodic-events;
description
"Notification for threshold events of the tidemarks
collection type.";
}
identity non-periodic-events {
description
"Base identity for non-periodic event notifications.";
}
identity but {
base non-periodic-events;
description
"Notification for Begin Unavailable Time (BUT) events.";
}
identity eut {
base non-periodic-events;
description
"Notification for End Unavailable Time (EUT) events.";
}
identity cses {
Yoon & You Expires 7 May 2027 [Page 41]
Internet-Draft PM Collection YANG November 2026
base non-periodic-events;
description
"Notification for Consecutive Severely Errored Seconds
(CSES) events.";
}
/*
* MEASUREMENT METHOD IDENTITIES (RFC 7799)
*/
identity measurement-method {
description
"Base identity for the IPPM measurement method (RFC 7799)
by which the Stage 1 samples of a performance parameter
are produced.";
reference
"RFC 7799: Active and Passive Metrics and Methods (with
Hybrid Types In-Between)";
}
identity active {
base measurement-method;
description
"Active measurement method: dedicated synthetic test
traffic is generated and injected to observe network
behaviour, e.g., OWAMP (RFC 4656), TWAMP (RFC 5357),
STAMP (RFC 8762).";
reference
"RFC 7799, Section 3.4";
}
identity passive {
base measurement-method;
description
"Passive measurement method: observation relies solely on
traffic and signals already present, e.g., reading
protocol counters or observing physical-layer signals,
without generating test packets.";
reference
"RFC 7799, Section 3.6";
}
identity hybrid {
base measurement-method;
description
"Hybrid measurement method: existing user traffic is
augmented or observed in transit to obtain measurements,
e.g., IOAM (RFC 9197).";
reference
Yoon & You Expires 7 May 2027 [Page 42]
Internet-Draft PM Collection YANG November 2026
"RFC 7799, Section 3.8";
}
/*
* SUSPECT-REASON IDENTITIES
*/
identity suspect-reason {
description
"Base identity for the reason a collection interval is
marked suspect (see suspect-interval-flag).";
reference
"ITU-T G.7710";
}
identity telemetry-loss {
base suspect-reason;
description
"One or more expected samples were lost in transit from
the Stage 1 sampling source.";
}
identity partial-node-support {
base suspect-reason;
description
"Some nodes or resources contributing to the parameter did
not report samples for the interval.";
}
identity state-reset {
base suspect-reason;
description
"Collection state was reset during the interval, so the
accumulated result does not cover the whole interval.";
}
identity restart {
base suspect-reason;
description
"The equipment or collection function restarted during
the interval.";
}
identity time-adjustment {
base suspect-reason;
description
"Interval timing changed during the interval, for example
due to a change of the sampling interval, reconfiguration,
or a clock adjustment, so the interval does not contain the
Yoon & You Expires 7 May 2027 [Page 43]
Internet-Draft PM Collection YANG November 2026
expected number of samples.";
}
identity measurement-suspended {
base suspect-reason;
description
"Data collection was intentionally suspended for part or
all of the interval, so the interval does not cover
continuous measurement. This corresponds to the
case in which the interval belongs to a period during
which the measurement is suspended or resumed, for
example administrative disabling of the PM function, a
planned maintenance window, or reconfiguration of the
measurement. It denotes an intentional pause of
collection, as distinct from unintended sample loss
(telemetry-loss), a counter reset (state-reset), or an
equipment or function restart (restart).";
reference
"ITU-T G.7710: suspect interval flag set when the
measurement is suspended or resumed";
}
identity measurement-boundary {
base suspect-reason;
description
"The interval is the first or last interval of the
measurement and does not cover the full nominal period,
because the measurement did not start or stop on an
interval boundary. The value is otherwise valid, but the
interval is partial.";
reference
"ITU-T G.7710: suspect interval flag set for the first or
last interval of the measurement";
}
identity outage {
base suspect-reason;
description
"A fault or outage condition (e.g., equipment or power
failure, or resource unavailability) prevented the
measurement from being performed for part or all of the
interval, so a snapshot or tidemark may contain no data or
the periodical gauge measurements were not possible. This
is distinct from telemetry-loss, in which the measurement
was performed but samples were lost in transit.";
reference
"ITU-T G.7710: suspect interval flag set when a snapshot or
tidemark contains no data due to outage conditions";
Yoon & You Expires 7 May 2027 [Page 44]
Internet-Draft PM Collection YANG November 2026
}
/*
* COMMON GROUPINGS
*/
grouping threshold-config {
description
"Common threshold configuration for the snapshot and
tidemarks collection types (high and low thresholds).";
leaf high-threshold {
type uint32;
description
"High threshold that triggers alerts when exceeded.";
}
leaf low-threshold {
type uint32;
description
"Low threshold that triggers alerts when performance
falls below acceptable levels.";
}
}
grouping transient-threshold-config {
description
"Threshold configuration for transient conditions.
Transient thresholds only support high threshold crossings
and report immediately when the count value reaches or
crosses the configured transient threshold value.
Transient thresholds do not support low threshold
(underflow) conditions, unlike the snapshot and tidemarks
collection types, which support both high and low
thresholds.";
leaf transient-threshold {
type uint32;
description
"Transient threshold that triggers alerts when exceeded.
Transient thresholds report immediately when the count
value reaches or crosses this threshold value.";
}
}
grouping event-state-info {
description
"Common event state information for all event types.";
leaf event-occurred {
type boolean;
description
"Indicates whether a threshold crossing or performance
Yoon & You Expires 7 May 2027 [Page 45]
Internet-Draft PM Collection YANG November 2026
event has occurred.";
}
leaf event-time {
type yang:date-and-time;
description
"Precise timestamp of when the event occurred.";
}
}
grouping oor-event-type {
description
"Common out-of-range event type definition.";
leaf event-type {
type enumeration {
enum High-OOR-event {
description "High OOR threshold exceeded.";
}
enum Low-OOR-event {
description "Low OOR threshold crossed.";
}
}
description
"Specifies whether the high or low OOR threshold was
crossed.";
}
}
grouping triggered-oor-event-info {
description
"Combined threshold event type and event information.";
uses oor-event-type;
uses event-state-info;
}
grouping count-transient-event-type {
description
"Transient threshold event type definition for the counts
collection type. Transient thresholds report immediately
when the count value reaches or crosses a configured
threshold value.";
leaf event-type {
type enumeration {
enum Threshold-Crossed-Event {
description
"Threshold crossing event generated when count value
reaches or crosses the configured threshold value.";
}
}
Yoon & You Expires 7 May 2027 [Page 46]
Internet-Draft PM Collection YANG November 2026
description
"Specifies that a threshold crossing event occurred.";
}
}
grouping triggered-count-transient-event-info {
description
"Combined transient threshold event type and event
information for the counts collection type. Transient
thresholds are independent threshold mechanisms that
report immediately when count values cross configured
threshold values.";
uses count-transient-event-type;
uses event-state-info;
}
grouping time-interval-config {
description "Common time interval configuration.";
leaf interval-value {
type uint32;
description "Numeric value for the interval.";
}
leaf unit {
type time-interval-unit;
description "Time unit for the interval value.";
}
}
grouping interval-data-status {
description
"Validity and coverage metadata for a collection interval,
aligned with the suspect interval flag. It lets a
client tell a fully measured interval from an incomplete
one, and a measured zero from an absent value.";
reference
"ITU-T G.7710";
leaf suspect-interval-flag {
type boolean;
default false;
description
"Set to 'false' at the start of a collection interval and
set to 'true' when the data stored for the interval may
be unreliable, for example when periodic samples are
missing, when collection state is reset, when the
equipment restarts, when interval timing changes, or
when collection is suspended.
For the snapshot collection type the initialization is
Yoon & You Expires 7 May 2027 [Page 47]
Internet-Draft PM Collection YANG November 2026
inverted: G.7710 initializes the flag to 'true' at the
start of the interval to indicate that no snapshot has
yet been taken, and clears it to 'false' once the single
snapshot has been taken at the uniform time.";
reference
"ITU-T G.7710";
}
leaf interval-status {
type interval-status;
description
"Validity status of the interval (complete, partial, or
unavailable). When this leaf is not 'complete', the
suspect-interval-flag is 'true'.";
}
leaf-list suspect-reason {
type identityref {
base suspect-reason;
}
description
"Zero or more reasons the interval is suspect. Present
only when known.";
}
leaf expected-sample-count {
if-feature coverage-counters;
type uint64;
description
"Number of Stage 1 samples expected during the collection
interval, i.e., the number a complete interval would
collect for the configured sampling interval (for
periodically sampled parameters, approximately the
collection interval divided by the sampling interval).
This is a sample-based coverage indicator that applies
to any sampled parameter and is most meaningful for
periodically sampled (gauge) parameters such as
tidemarks. It is not defined by ITU-T G.7710, which
indicates counter coverage through 'elapsed-time' and
marks incompleteness with the suspect-interval-flag; the
sample counts generalize that notion for this model.";
}
leaf received-sample-count {
if-feature coverage-counters;
type uint64;
description
"Number of valid Stage 1 samples actually collected
during the collection interval. Together with
expected-sample-count it gives the interval coverage: a
value equal to expected-sample-count indicates full
coverage, a smaller value a partial interval, and zero
Yoon & You Expires 7 May 2027 [Page 48]
Internet-Draft PM Collection YANG November 2026
an unavailable interval (no valid sample).";
}
leaf elapsed-time {
type uint32;
units "seconds";
description
"Elapsed time since the start of the current collection
interval. This is the number of seconds of the interval
that have been processed by the measurement, not the sum
of available time; it advances during unavailable time
as well and falls short of the nominal interval only
when the measurement itself could not run (e.g., a
boundary interval, a clock adjustment, or an outage).";
}
leaf interval-start-time {
type yang:date-and-time;
description
"Timestamp marking the start of the collection interval
to which this status applies.";
}
leaf interval-end-time {
type yang:date-and-time;
description
"Timestamp marking the end of the collection interval to
which the reported values apply. This is the
end-of-interval timestamp. It is the authoritative
measurement time for the interval and should be used for
correlation in preference to the notification envelope
eventTime, which reflects when the notification was
generated rather than the measurement interval boundary.
It is present once the interval has completed.";
reference
"ITU-T G.7710";
}
}
/*
* COLLECTION TYPE GROUPINGS
*
* Each collection type is a presence container. The presence
* of the container in a collection-interval entry indicates
* that the server collects that collection type for the
* parameter over that interval; its absence indicates that it
* does not. This lets a profile select, for example, the
* counts collection type only.
*/
grouping count-collection-gr {
description
Yoon & You Expires 7 May 2027 [Page 49]
Internet-Draft PM Collection YANG November 2026
"Counts collection type for cumulative event tracking over
a collection interval. Supports transient and standing
threshold reporting.";
container counts {
presence
"Enables the counts collection type for this collection
interval.";
description
"Contains counts collection values and configuration.";
container transient-condition-config {
description
"Configuration for transient threshold conditions.
Transient thresholds report immediately when the
count value reaches or crosses the configured
transient threshold value. Transient thresholds do
not support low threshold (underflow) conditions,
unlike the snapshot and tidemarks collection types,
which support both high and low thresholds.";
uses transient-threshold-config;
}
container standing-condition-config {
must "not(standing-threshold and reset-threshold) or "
+ "standing-threshold >= reset-threshold" {
error-message
"Standing threshold must be >= reset threshold.";
}
description
"Configuration for standing condition monitoring.
When both thresholds are set, standing-threshold
must be greater than or equal to reset-threshold
(hysteresis).";
leaf standing-threshold {
type uint32;
description
"Threshold value that triggers standing condition
alerts.";
}
leaf reset-threshold {
type uint32;
description
"Reset threshold value that clears standing
conditions.";
}
}
leaf collection-value {
type uint32;
config false;
description
Yoon & You Expires 7 May 2027 [Page 50]
Internet-Draft PM Collection YANG November 2026
"Current cumulative count value for the collection
interval.";
}
}
}
grouping snapshot-collection-gr {
description
"Snapshot collection type for instantaneous values at the
uniform time within each collection interval. Supports
high/low OOR threshold reporting.";
container snapshot {
presence
"Enables the snapshot collection type for this collection
interval.";
description
"Contains snapshot configuration and values.";
container uniform-time-config {
description
"Configuration of the uniform time: the fixed offset
from the start of the collection interval at which the
single snapshot is taken. Taking snapshots at the same
uniform time across network elements lets their values
be correlated.";
leaf offset-value {
type uint32;
description
"Numeric value of the offset, measured from the start
of the collection interval, at which the snapshot is
taken.";
}
leaf unit {
type time-interval-unit;
description
"Time unit for the uniform-time offset.";
}
}
container threshold-config {
description
"Configuration for snapshot threshold monitoring.";
uses threshold-config;
}
leaf collection-value {
type uint32;
config false;
description
"Current instantaneous snapshot value.";
}
Yoon & You Expires 7 May 2027 [Page 51]
Internet-Draft PM Collection YANG November 2026
}
}
grouping tidemarks-collection-gr {
description
"Tidemarks collection type for maximum and minimum values
over the collection interval. Supports high/low OOR
threshold reporting.";
container tidemarks {
presence
"Enables the tidemarks collection type for this
collection interval.";
description
"Contains tidemarks values and threshold
configuration.";
container threshold-config {
description
"Configuration for tidemarks threshold monitoring.";
uses threshold-config;
}
leaf high-collection-value {
type uint32;
config false;
description
"Current maximum value recorded during the collection
interval.";
}
leaf low-collection-value {
type uint32;
config false;
description
"Current minimum value recorded during the collection
interval.";
}
}
}
grouping collection-types-gr {
description
"Grouping for the three core collection types (counts,
snapshot, tidemarks).";
container collection-types {
description
"Container for the counts, snapshot, and tidemarks
collection types. Each collection type is a presence
container; a collection type is collected for this
collection interval only when its container is
present.";
Yoon & You Expires 7 May 2027 [Page 52]
Internet-Draft PM Collection YANG November 2026
uses count-collection-gr;
uses snapshot-collection-gr;
uses tidemarks-collection-gr;
}
}
/*
* EVENT GROUPINGS
*/
grouping counts-transient-event-gr {
description
"Transient threshold events for the counts collection
type. Transient thresholds are independent threshold
mechanisms that report immediately when count values
cross configured threshold values.";
container counts-transient {
description
"Contains information about transient threshold events
for counts.";
uses triggered-count-transient-event-info;
}
}
grouping counts-standing-event-gr {
description
"Standing condition events for the counts collection
type.";
container counts-standing {
description
"Contains information about standing threshold events
for counts.";
leaf event-type {
type enumeration {
enum Threshold-Report {
description
"Threshold Report (TR) generated when the count
value reaches or exceeds the standing-threshold
configured in standing-condition-config.";
}
enum Reset-Threshold-Report {
description
"Reset Threshold Report (RTR) generated at the end
of the period when the count value is at or below
the reset-threshold (G.7710 standing condition
clear). An RTR is not generated for an interval
whose suspect-interval-flag is set (equivalent to
the G.7710 'no unavailable time' condition).";
}
Yoon & You Expires 7 May 2027 [Page 53]
Internet-Draft PM Collection YANG November 2026
}
description
"Specifies the type of standing threshold event that
occurred. A Threshold-Report
(TR) is generated when the collection-value reaches
or exceeds the standing-threshold. A
Reset-Threshold-Report (RTR) is generated at the end
of the period when the collection-value is at or
below the reset-threshold.";
}
uses event-state-info;
}
}
grouping snapshot-events-gr {
description
"Threshold events for the snapshot collection type.";
container snapshot {
description
"Contains snapshot threshold event information.";
uses triggered-oor-event-info;
}
}
grouping tidemarks-events-gr {
description
"Threshold events for the tidemarks collection type.";
container tidemarks {
description
"Contains tidemarks threshold event information.";
uses triggered-oor-event-info;
}
}
/*
* COLLECTION INTERVAL STRUCTURES
*/
grouping periodic-collection-intervals {
description
"Hierarchical structure for periodic collection timing
and collection types.";
list sampling-interval {
key "id";
description
"List of sampling intervals defining data collection
frequency.";
leaf id {
type string;
Yoon & You Expires 7 May 2027 [Page 54]
Internet-Draft PM Collection YANG November 2026
description
"Unique identifier for this sampling interval
configuration.";
}
leaf interval-value {
type uint32 {
range "1..max";
}
default 1;
description
"Numeric value for the sampling interval.";
}
leaf unit {
type time-interval-unit;
default second;
description "Time unit for the sampling interval value.";
}
list collection-interval {
key "id";
description
"List of collection intervals defining aggregation
periods.";
leaf id {
type string;
description
"Unique identifier for this collection interval
configuration.";
}
leaf interval-value {
type uint32 {
range "1..max";
}
default 15;
description
"Numeric value for the collection interval.";
}
leaf unit {
type time-interval-unit;
default minute;
description
"Time unit for the collection interval value.";
}
container interval-data-status {
config false;
description
"Operational validity and coverage status of this
collection interval (see the interval-data-status
grouping). In push-based delivery this status
Yoon & You Expires 7 May 2027 [Page 55]
Internet-Draft PM Collection YANG November 2026
accompanies each streamed record; in pull-based
retrieval it is read alongside the collection
value.";
uses interval-data-status;
}
uses collection-types-gr;
}
}
}
grouping non-periodic-events-gr {
description
"Grouping for non-periodic performance event parameters
(BUT, EUT, CSES).";
container BUT-event {
description "Begin Unavailable Time (BUT) event.";
uses event-state-info;
}
container EUT-event {
description "End Unavailable Time (EUT) event.";
uses event-state-info;
leaf duration {
type uint32;
units "seconds";
description
"Total duration of unavailability in seconds.";
}
}
container CSES-event {
description
"Consecutive Severely Errored Seconds (CSES) event.";
leaf event-occurred {
type boolean;
description
"Indicates whether a CSES event was generated.";
}
leaf start {
type yang:date-and-time;
description
"Timestamp indicating when the CSES period began.";
}
leaf end {
type yang:date-and-time;
description
"Timestamp indicating when the CSES period ended.";
}
leaf duration {
type uint32;
Yoon & You Expires 7 May 2027 [Page 56]
Internet-Draft PM Collection YANG November 2026
units "seconds";
description "Duration of the CSES period in seconds.";
}
leaf error-count {
type uint32;
description
"Number of errors during the CSES period.";
}
}
}
grouping pm-periodic-collection-gr {
description
"Hierarchical structure for periodic PM collection.";
list parameter-profile {
key "name";
description "List of performance parameter profiles.";
leaf name {
type profile-names;
description "Name of the parameter profile.";
}
list pm-parameter {
key "name";
description
"List of PM parameters within the parameter profile.";
leaf name {
type identityref {
base performance-parameter;
}
description
"Identity of the performance parameter being
collected, derived from the performance-parameter
base identity.";
}
leaf measurement-method {
type identityref {
base measurement-method;
}
description
"IPPM measurement method (RFC 7799) by which this
parameter's Stage 1 samples are produced. This leaf
is optional; when absent, the measurement method is
unspecified. It carries interpretation metadata
only and does not affect Collection-stage behaviour.
Some parameters (e.g., environmental sensor
readings) are not classified by this axis.";
reference
"RFC 7799: Active and Passive Metrics and Methods
Yoon & You Expires 7 May 2027 [Page 57]
Internet-Draft PM Collection YANG November 2026
(with Hybrid Types In-Between);
RFC 6390, Section 5.4.4: method of measurement
metadata";
}
uses periodic-collection-intervals;
}
}
}
/*
* MAIN CONTAINER
*/
container pm-periodic-collection {
description
"Main container for periodic PM collection.";
uses pm-periodic-collection-gr;
}
/*
* NOTIFICATIONS
*/
notification pm-threshold-events {
description
"Notification for periodic threshold crossing events and
non-periodic performance events (BUT, EUT, CSES).";
container periodic-events {
description "Container for periodic threshold events.";
list parameter-profile {
key "name";
description
"List of performance parameter profiles for event
monitoring.";
leaf name {
type profile-names;
description "Name of the parameter profile.";
}
list pm-parameter {
key "name";
description
"List of PM parameters within the parameter
profile.";
leaf name {
type identityref {
base performance-parameter;
}
description
"Identity of the performance parameter being
monitored, derived from the performance-parameter
Yoon & You Expires 7 May 2027 [Page 58]
Internet-Draft PM Collection YANG November 2026
base identity.";
}
list sampling-interval {
key "id";
description
"List of sampling intervals for event monitoring.";
leaf id {
type string;
description
"Unique identifier for this sampling interval
configuration.";
}
uses time-interval-config;
list collection-interval {
key "id";
description
"List of collection intervals for event
aggregation.";
leaf id {
type string;
description
"Unique identifier for this collection
interval configuration.";
}
uses time-interval-config;
container event-types {
description
"Container for different threshold event
types.";
uses counts-transient-event-gr;
uses counts-standing-event-gr;
uses snapshot-events-gr;
uses tidemarks-events-gr;
}
}
}
}
}
}
container non-periodic-events {
description
"Container for non-periodic performance events (BUT,
EUT, CSES).";
uses non-periodic-events-gr;
}
}
}
Yoon & You Expires 7 May 2027 [Page 59]
Internet-Draft PM Collection YANG November 2026
<CODE ENDS>
8. YANG Data Trees
module: ietf-pm-collection
+--rw pm-periodic-collection
+--rw parameter-profile* [name]
+--rw name profile-names
+--rw pm-parameter* [name]
+--rw name identityref
+--rw measurement-method? identityref
+--rw sampling-interval* [id]
+--rw id string
+--rw interval-value? uint32
+--rw unit? time-interval-unit
+--rw collection-interval* [id]
+--rw id string
+--rw interval-value? uint32
+--rw unit? time-interval-unit
+--ro interval-data-status
| +--ro suspect-interval-flag? boolean
| +--ro interval-status? interval-status
| +--ro suspect-reason* identityref
| +--ro expected-sample-count? uint64
| | {coverage-counters}?
| +--ro received-sample-count? uint64
| | {coverage-counters}?
| +--ro elapsed-time? uint32
| +--ro interval-start-time? yang:date-and-time
| +--ro interval-end-time? yang:date-and-time
+--rw collection-types
+--rw counts!
| +--rw transient-condition-config
| | +--rw transient-threshold? uint32
| +--rw standing-condition-config
| | +--rw standing-threshold? uint32
| | +--rw reset-threshold? uint32
| +--ro collection-value? uint32
+--rw snapshot!
| +--rw uniform-time-config
| | +--rw offset-value? uint32
| | +--rw unit? time-interval-unit
| +--rw threshold-config
| | +--rw high-threshold? uint32
| | +--rw low-threshold? uint32
| +--ro collection-value? uint32
+--rw tidemarks!
+--rw threshold-config
Yoon & You Expires 7 May 2027 [Page 60]
Internet-Draft PM Collection YANG November 2026
| +--rw high-threshold? uint32
| +--rw low-threshold? uint32
+--ro high-collection-value? uint32
+--ro low-collection-value? uint32
notifications:
+---n pm-threshold-events
+--ro periodic-events
| +--ro parameter-profile* [name]
| +--ro name profile-names
| +--ro pm-parameter* [name]
| +--ro name identityref
| +--ro sampling-interval* [id]
| +--ro id string
| +--ro interval-value? uint32
| +--ro unit? time-interval-unit
| +--ro collection-interval* [id]
| +--ro id string
| +--ro interval-value? uint32
| +--ro unit? time-interval-unit
| +--ro event-types
| +--ro counts-transient
| | +--ro event-type? enumeration
| | +--ro event-occurred? boolean
| | +--ro event-time? yang:date-and-time
| +--ro counts-standing
| | +--ro event-type? enumeration
| | +--ro event-occurred? boolean
| | +--ro event-time? yang:date-and-time
| +--ro snapshot
| | +--ro event-type? enumeration
| | +--ro event-occurred? boolean
| | +--ro event-time? yang:date-and-time
| +--ro tidemarks
| +--ro event-type? enumeration
| +--ro event-occurred? boolean
| +--ro event-time? yang:date-and-time
+--ro non-periodic-events
+--ro BUT-event
| +--ro event-occurred? boolean
| +--ro event-time? yang:date-and-time
+--ro EUT-event
| +--ro event-occurred? boolean
| +--ro event-time? yang:date-and-time
| +--ro duration? uint32
+--ro CSES-event
+--ro event-occurred? boolean
+--ro start? yang:date-and-time
Yoon & You Expires 7 May 2027 [Page 61]
Internet-Draft PM Collection YANG November 2026
+--ro end? yang:date-and-time
+--ro duration? uint32
+--ro error-count? uint32
Figure 18: Tree Diagram of the ietf-pm-collection Module
9. Manageability Considerations
This section discusses operational aspects of deploying the model
defined in this document.
Capability discovery before configuration: A server is not required
to support every sampling interval, collection interval, or
collection type for every parameter, and it rejects a
configuration that it does not support. How a client discovers
the supported combinations before configuration is outside the
scope of this document.
Configuration and operational state: Profiles, intervals, collection
types, and thresholds are configuration and are held in the
running configuration datastore. Collected values, interval
status, and validity metadata are operational state and are read
from the operational state datastore [RFC8342]. A server may
provide profiles as system-defined configuration, which then
appear in the operational state datastore without client
configuration.
Scaling and load: The processing load on a network element grows
with the number of configured "pm-parameter" and interval entries,
with shorter sampling intervals, and with the number of monitored
objects. The delivery load grows with the number of concurrent
YANG-Push subscriptions [RFC8639] [RFC8641] and with shorter
subscription periods. Operators should choose profiles,
intervals, and subscription periods with these costs in mind. A
periodic subscription period that matches the collection interval
delivers each completed result once, without redundant updates. A
server MAY limit the number of entries or subscriptions it
accepts, and MAY reject a subscription it cannot serve, as
permitted by [RFC8639] and [RFC8641].
Time synchronization: Collection interval boundaries are derived
from the clock of the network element. For results to be
comparable across network elements, operators should synchronize
those clocks, for example with NTP or PTP. An interval in which
the clock was adjusted, or in which data was otherwise incomplete,
is marked by the suspect interval flag (see Section 4).
Data validity: A client SHOULD check "interval-data-status" before
Yoon & You Expires 7 May 2027 [Page 62]
Internet-Draft PM Collection YANG November 2026
using a collected value. A value from an interval whose suspect
interval flag is set should not be treated as equivalent to a
value from a complete interval, for example in SLA reporting. A
value of zero is interpreted according to the interval status, as
described in Section 4.
Retention: A server is not required to retain completed intervals.
When it does not, a client that needs a complete history must
obtain each result as its interval ends, either by subscription or
by polling close to the interval boundary.
Threshold events and fault management: Threshold events (see
Section 5) indicate performance degradation. They are not
equipment alarms, but an operator may feed them into existing
fault management workflows. Thresholds set too low can produce a
large number of notifications. The standing condition method,
with its reset threshold, can be used to limit repeated reports
for a persistent condition.
10. Security Considerations
The YANG module specified in this document defines 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.
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 under the "/pm-periodic-
collection" container. These data nodes may be considered sensitive
or vulnerable in some network environments. Write operations (e.g.,
edit-config) to these data nodes without proper protection can have a
negative effect on network operations. These are the subtrees and
data nodes and their sensitivity/vulnerability:
"/pm-periodic-collection/parameter-profile", including its
"pm-parameter", "sampling-interval", and "collection-interval"
entries: An attacker who can create entries, or shorten sampling
Yoon & You Expires 7 May 2027 [Page 63]
Internet-Draft PM Collection YANG November 2026
intervals, could raise the processing and memory load on the
network element and degrade its other functions. An attacker who
can delete or modify entries could stop or alter the collection of
performance data, hiding service degradation from the operator and
corrupting the data used for SLA verification.
".../collection-types/counts", ".../snapshot", and
".../tidemarks": These presence containers enable collection types.
Removing them silently stops the corresponding collection and
threshold reporting.
".../transient-condition-config", ".../standing-condition-config",
".../threshold-config", and ".../uniform-time-config": Raising
thresholds or the reset threshold could suppress threshold reports
and hide performance degradation. Lowering them could cause a
flood of notifications towards clients. Changing the uniform time
offset changes when snapshots are taken, which can make results
inconsistent across network elements.
"measurement-method": Changing this leaf could cause clients to
misinterpret how the collected values were obtained.
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:
"collection-value", "high-collection-value", "low-collection-
value",
and "interval-data-status": These nodes reveal error performance,
unavailability periods, and the quality of service delivered on
monitored connections. This information can expose weak points in
the network and indicate when and where an attack is likely to
have an effect. It can also reveal commercially sensitive
information, such as SLA compliance. The configuration nodes can
reveal which resources and parameters an operator monitors and at
which thresholds.
The "pm-threshold-events" notification carries the same kind of
information as the readable nodes, including the times of
unavailability (BUT and EUT events) and of consecutive severely
errored seconds (CSES events). Access to it SHOULD be restricted in
the same way, using NACM and the security mechanisms of the
subscription framework [RFC8639] [RFC8641].
Yoon & You Expires 7 May 2027 [Page 64]
Internet-Draft PM Collection YANG November 2026
This YANG module defines no RPC operations or actions.
11. IANA Considerations
This document requests IANA to register the following URI in the "ns"
subregistry within the "IETF XML Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-pm-collection Registrant
Contact: The IESG. XML: N/A; the requested URI is an XML namespace.
This document also requests IANA to register the following YANG
module in the "YANG Module Names" registry [RFC6020]:
Name: ietf-pm-collection Namespace: urn:ietf:params:xml:ns:yang:ietf-
pm-collection Prefix: pm-co Reference: RFC XXXX
12. References
12.1. Normative References
[G7710] ITU-T, "Common Equipment Management Function
Requirements", ITU-T Recommendation G.7710, November 2025,
<https://www.itu.int/rec/T-REC-G.7710>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/rfc/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/rfc/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/rfc/rfc6242>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/rfc/rfc6991>.
Yoon & You Expires 7 May 2027 [Page 65]
Internet-Draft PM Collection YANG November 2026
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/rfc/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/rfc/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/rfc/rfc8340>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/rfc/rfc8341>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/rfc/rfc8342>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.
[RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
E., and A. Tripathy, "Subscription to YANG Notifications",
RFC 8639, DOI 10.17487/RFC8639, September 2019,
<https://www.rfc-editor.org/rfc/rfc8639>.
[RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
E., and A. Tripathy, "Dynamic Subscription to YANG Events
and Datastores over NETCONF", RFC 8640,
DOI 10.17487/RFC8640, September 2019,
<https://www.rfc-editor.org/rfc/rfc8640>.
[RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications
for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,
September 2019, <https://www.rfc-editor.org/rfc/rfc8641>.
12.2. Informative References
Yoon & You Expires 7 May 2027 [Page 66]
Internet-Draft PM Collection YANG November 2026
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330,
DOI 10.17487/RFC2330, May 1998,
<https://www.rfc-editor.org/rfc/rfc2330>.
[RFC3593] Tesink, K., Ed., "Textual Conventions for MIB Modules
Using Performance History Based on 15 Minute Intervals",
RFC 3593, DOI 10.17487/RFC3593, September 2003,
<https://www.rfc-editor.org/rfc/rfc3593>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/rfc/rfc3688>.
[RFC3705] Ray, B. and R. Abbi, "High Capacity Textual Conventions
for MIB Modules Using Performance History Based on 15
Minute Intervals", RFC 3705, DOI 10.17487/RFC3705,
February 2004, <https://www.rfc-editor.org/rfc/rfc3705>.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,
<https://www.rfc-editor.org/rfc/rfc4656>.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
RFC 5357, DOI 10.17487/RFC5357, October 2008,
<https://www.rfc-editor.org/rfc/rfc5357>.
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New
Performance Metric Development", BCP 170, RFC 6390,
DOI 10.17487/RFC6390, October 2011,
<https://www.rfc-editor.org/rfc/rfc6390>.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <https://www.rfc-editor.org/rfc/rfc7799>.
[RFC8526] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "NETCONF Extensions to Support the Network
Management Datastore Architecture", RFC 8526,
DOI 10.17487/RFC8526, March 2019,
<https://www.rfc-editor.org/rfc/rfc8526>.
[RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple
Two-Way Active Measurement Protocol", RFC 8762,
DOI 10.17487/RFC8762, March 2020,
<https://www.rfc-editor.org/rfc/rfc8762>.
Yoon & You Expires 7 May 2027 [Page 67]
Internet-Draft PM Collection YANG November 2026
[RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi,
Ed., "Data Fields for In Situ Operations, Administration,
and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197,
May 2022, <https://www.rfc-editor.org/rfc/rfc9197>.
Contributors
Kwangkoog Lee
KT
Email: kwangkoog.lee@kt.com
Jongyoon Shin
SK Telecom
Email: jongyoon.shin@sk.com
Sungyong Nam
LGU+
Email: sy.nam@lguplus.co.kr
Authors' Addresses
Bin Yeong Yoon
ETRI
Email: byyun@etri.re.kr
Youngkil You
woori-net
Email: young@woori-net.com
Yoon & You Expires 7 May 2027 [Page 68]