A YANG Data Model for Collection Measurement
draft-yoon-ippm-collection-measure-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-07-05 | ||
| 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-ippm-collection-measure-00
IPPM Working Group B. Y. Yoon
Internet-Draft ETRI
Intended status: Standards Track Y. You
Expires: 7 January 2027 woori-net
6 July 2026
A YANG Data Model for Collection Measurement
draft-yoon-ippm-collection-measure-00
Abstract
This document specifies a YANG data model for Collection Measurement
based on the Performance Management (PM) Collection function
requirements 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 identified by ITU-T
G.7710.
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-
ippm-collection-measure.html. Status information for this document
may be found at https://datatracker.ietf.org/doc/draft-yoon-ippm-
collection-measure/.
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 January 2027 [Page 1]
Internet-Draft Collection Measurement YANG July 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 January 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 . . 5
1.3. Motivation and Scope . . . . . . . . . . . . . . . . . . 7
2. PM parameters . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Types . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Profiles . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1. Naming . . . . . . . . . . . . . . . . . . . . . . . 11
3. Periodic Collection . . . . . . . . . . . . . . . . . . . . . 12
3.1. Interval Timing . . . . . . . . . . . . . . . . . . . . . 12
3.1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Collection Types . . . . . . . . . . . . . . . . . . . . 15
3.2.1. Counts . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.2. Snapshot . . . . . . . . . . . . . . . . . . . . . . 18
3.2.3. Tidemarks . . . . . . . . . . . . . . . . . . . . . . 19
4. Thresholding . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1. Periodic Thresholding . . . . . . . . . . . . . . . . . . 19
4.2. Non-Periodic Thresholding . . . . . . . . . . . . . . . . 20
5. Data Access . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.1. Pull-Based Polling . . . . . . . . . . . . . . . . . . . 20
5.2. Periodic Events . . . . . . . . . . . . . . . . . . . . . 23
5.3. Threshold Events . . . . . . . . . . . . . . . . . . . . 25
5.3.1. Periodic Threshold Events . . . . . . . . . . . . . . 25
5.3.2. Non-Periodic Threshold Events . . . . . . . . . . . . 28
6. YANG Data Model . . . . . . . . . . . . . . . . . . . . . . . 29
Yoon & You Expires 7 January 2027 [Page 2]
Internet-Draft Collection Measurement YANG July 2026
7. YANG Data Trees . . . . . . . . . . . . . . . . . . . . . . . 44
8. Manageability Considerations . . . . . . . . . . . . . . . . 46
9. Security Considerations . . . . . . . . . . . . . . . . . . . 47
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 47
11.1. Normative References . . . . . . . . . . . . . . . . . . 47
11.2. Informative References . . . . . . . . . . . . . . . . . 48
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction
Performance Management (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 for the Collection stage, referred to in
this document as the Collection Measurement 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 January 2027 [Page 3]
Internet-Draft Collection Measurement YANG July 2026
+------------------+ +====================+ +------------------+
| Stage 1 | | Stage 2 | | Stage 3 |
| Sampling |--->| Collection |--->| Reporting |
| | | (this document) | | |
| - Physical layer | | | | - YANG-Push |
| - OWAMP/TWAMP/ | | - Counts | | RFC 8639/8640/ |
| STAMP/IOAM | | - Snapshot | | 8641 |
| - Sensors | | - Tidemarks | | - OS/NDT/AI APP |
| | | - Thresholding | | |
+------------------+ +====================+ +------------------+
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.
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 January 2027 [Page 4]
Internet-Draft Collection Measurement YANG July 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 Collection Measurement
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 Section 6.2. 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 Collection Measurement interface,
regardless of whether it acts as a controller, an analytics engine,
or an operator-facing management system.
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 January 2027 [Page 5]
Internet-Draft Collection Measurement YANG July 2026
+--------------------------------------------------------------------+
| Collection (G.7710): 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; following ITU-T G.7710, 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 referenced ITU-T
G.7710 recommendation and 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, and both retain
the meaning derived from ITU-T G.7710.
Yoon & You Expires 7 January 2027 [Page 6]
Internet-Draft Collection Measurement YANG July 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 aligned with ITU-T
G.7710.
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 instead reflects several decades of operational
experience by fixing a deliberately small set of collection forms and
parameters: per clause 10.1.6.2 of [G7710], 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 per clause 10.1.6.4 of
[G7710], 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.
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, as defined in ITU-T
G.7710; (b) configurable sampling and collection intervals that are
not restricted to the legacy 15-minute or 24-hour windows; and (c)
Yoon & You Expires 7 January 2027 [Page 7]
Internet-Draft Collection Measurement YANG July 2026
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 data model defined in this document realizes the Collection-stage
functions described in [G7710], in particular performance-monitoring
data, collection types, and threshold reporting.
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.
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:
- 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
Yoon & You Expires 7 January 2027 [Page 8]
Internet-Draft Collection Measurement YANG July 2026
* 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.
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. The network
and transport performance parameters listed above (for example, ES,
SES, UAS, BBE, BBC) are the primary parameters in scope, and each 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 remaining categories (network
environment, energy and sustainability, security, mobile network, and
application-aware parameters) are listed as illustrative examples of
the model's extensibility and are not themselves defined by this
document; the specification of any such parameter is left to the
relevant standards body.
2.2. Profiles
Yoon & You Expires 7 January 2027 [Page 9]
Internet-Draft Collection Measurement YANG July 2026
+--rw parameter-profile* [name]
+--rw name profile-names
+--rw pm-parameter* [name]
+--rw name string
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, the itu-transport-maintenance-15min profile
may include parameters such as errored seconds (ES), severely errored
seconds (SES), and unavailable seconds (UAS), which are typically
monitored together for network maintenance and fault detection
purposes. Similarly, the example-ip-qos-24hr profile may include
delay, jitter, and loss parameters used in service quality reporting.
Parameter profiles 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.
The profile abstraction also aligns with ITU-T G.7710, which
identifies multiple classes of performance monitoring (e.g.,
maintenance, service-level, and compliance monitoring), each
requiring specific sets of performance parameters.
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.
Yoon & You Expires 7 January 2027 [Page 10]
Internet-Draft Collection Measurement YANG July 2026
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:
* itu-transport-maintenance-15min
* itu-transport-qos-24hr
* ieee-access-availability
* example-ip-qos-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.
Yoon & You Expires 7 January 2027 [Page 11]
Internet-Draft Collection Measurement YANG July 2026
The term 'transport' means that the profile applies to multiple
technologies (e.g., OTN, MPLS-TP, Transport Ethernet, etc.).
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.
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 5: Sampling and Collection Intervals Subtree
Interval timing parameters are key components of network performance
management, 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.
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.
Yoon & You Expires 7 January 2027 [Page 12]
Internet-Draft Collection Measurement YANG July 2026
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.
Uniform time is a fixed, predefined point within each collection
interval at which a snapshot measurement 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 ITU-T G.7710 and 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), errored seconds (ES) 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 routine
maintenance monitoring and aligns with established operational
practices described in ITU-T G.7710. 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.
Yoon & You Expires 7 January 2027 [Page 13]
Internet-Draft Collection Measurement YANG July 2026
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.
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 January 2027 [Page 14]
Internet-Draft Collection Measurement YANG July 2026
+================+=======+=======+===========+====================+
| Client (param) | Samp. | Meas. | Coll. | Purpose |
+================+=======+=======+===========+====================+
| NOC (ES) | 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 January 2027 [Page 15]
Internet-Draft Collection Measurement YANG July 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 interval-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 6: Collection Types Subtree
The collection types defined based on ITU-T G.7710 establish a
focused and efficient framework for network performance monitoring by
specifying three core collection types: counts, snapshot, and
tidemarks.
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
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.
Yoon & You Expires 7 January 2027 [Page 16]
Internet-Draft Collection Measurement YANG July 2026
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.
+============+=========================+=======================+
| 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
Yoon & You Expires 7 January 2027 [Page 17]
Internet-Draft Collection Measurement YANG July 2026
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
Counts measurement 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.
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 type of measurement is
particularly useful for long-term analysis, enabling preventive
maintenance and optimizing network performance. Unlike instantaneous
measurements, 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 measurement 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 transport 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.
Yoon & You Expires 7 January 2027 [Page 18]
Internet-Draft Collection Measurement YANG July 2026
3.2.3. Tidemarks
Tidemarks measurements record 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 measurements 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.
4. Thresholding
4.1. Periodic Thresholding
Periodic threshold events are triggered when the counts or gauge
value reaches a pre-defined threshold during periodic measurements
including counts, snapshot, and tidemarks for performance parameters.
The counts measurement has two types of threshold reporting methods:
transient and standing condition methods. The transient condition
method treats each measurement period separately. As soon as a
threshold is reached or crossed in a collection interval for a given
performance measurement, 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.
For gauge measurements ("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.
Yoon & You Expires 7 January 2027 [Page 19]
Internet-Draft Collection Measurement YANG July 2026
4.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.
5. 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.
5.1. 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 against the operational datastore [RFC8342], or via
RESTCONF HTTP GET requests, at any polling interval chosen by the
client.
Yoon & You Expires 7 January 2027 [Page 20]
Internet-Draft Collection Measurement YANG July 2026
The collection-value leaf (config false) in the counts collection
type, and the corresponding measurement 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 7 shows a NETCONF <get-data> request that retrieves the
current errored-seconds (ES) count for the itu-transport-maintenance-
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 January 2027 [Page 21]
Internet-Draft Collection Measurement YANG July 2026
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:pm-coll=
"urn:ietf:params:xml:ns:yang:ietf-pm-collection"
message-id="401">
<get-data
xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda">
<datastore
xmlns:ds=
"urn:ietf:params:xml:ns:yang:ietf-datastores">
ds:operational
</datastore>
<subtree-filter>
<pm-coll:pm-periodic-collection>
<parameter-profile>
<name>itu-transport-maintenance-15min</name>
<pm-parameter>
<name>es</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-coll:pm-periodic-collection>
</subtree-filter>
</get-data>
</rpc>
Figure 7: Pull-Based Polling Request Example (NETCONF get-data)
Figure 8 shows the corresponding reply, in which the server returns
the current ES 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 January 2027 [Page 22]
Internet-Draft Collection Measurement YANG July 2026
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:pm-coll=
"urn:ietf:params:xml:ns:yang:ietf-pm-collection"
message-id="401">
<data>
<pm-coll:pm-periodic-collection>
<parameter-profile>
<name>itu-transport-maintenance-15min</name>
<pm-parameter>
<name>es</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-coll:pm-periodic-collection>
</data>
</rpc-reply>
Figure 8: Pull-Based Polling Reply Example (NETCONF get-data)
5.2. Periodic Events
The YANG-Push subscription model, as defined in [RFC8641], enables
clients to subscribe to periodic performance measurement 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.
Yoon & You Expires 7 January 2027 [Page 23]
Internet-Draft Collection Measurement YANG July 2026
Figure 9 shows a subscription request for the ES parameter in the
itu-transport-maintenance-15min profile. It requests counts
measurement data sampled every second and aggregated over a 15-minute
interval. The reporting period is set to 900 seconds, so a
notification is sent at the end of each collection interval.
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:sn=
"urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"
xmlns:pm-coll=
"urn:ietf:params:xml:ns:yang:ietf-pm-collection"
message-id="101">
<sn:establish-subscription>
<sn:stream>YANG-PUSH</sn:stream>
<sn:encoding>encode-xml</sn:encoding>
<sn:filter>
<sn:datastore>operational</sn:datastore>
<sn:xpath-filter>
/pm-coll:pm-periodic-collection/
parameter-profile[name='itu-transport-maintenance-15min']/
pm-parameter[name='es']/
sampling-interval[id='1s']/
collection-interval[id='15min']/
collection-types/counts/collection-value
</sn:xpath-filter>
</sn:filter>
<sn:period>900</sn:period>
<sn:anchor-time>2024-07-01T00:00:00Z</sn:anchor-time>
</sn:establish-subscription>
</rpc>
Figure 9: Periodic Event Subscription Example
Figure 10 shows a notification for the ES parameter in the itu-
transport-maintenance-15min profile. It reports the counts
measurement value sampled every second and aggregated over a
15-minute interval. The measured value (10) represents the total
errored seconds in that period.
Yoon & You Expires 7 January 2027 [Page 24]
Internet-Draft Collection Measurement YANG July 2026
<notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"
xmlns:pm-coll=
"urn:ietf:params:xml:ns:yang:ietf-pm-collection">
<eventTime>2024-07-01T00:15:00Z</eventTime>
<pm-coll:pm-periodic-collection>
<parameter-profile>
<name>itu-transport-maintenance-15min</name>
<pm-parameter>
<name>es</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>
<collection-types>
<counts>
<collection-value>10</collection-value>
</counts>
</collection-types>
</collection-interval>
</sampling-interval>
</pm-parameter>
</parameter-profile>
</pm-coll:pm-periodic-collection>
</notification>
Figure 10: Periodic Event Notification Example
5.3. Threshold Events
Threshold event subscriptions enable clients to receive immediate
notifications when performance metrics cross predefined thresholds,
providing proactive monitoring capabilities. This subscription type
uses standard YANG-Push [RFC8639] [RFC8641] datastore change
notifications to deliver the threshold events defined in this
document.
5.3.1. Periodic Threshold Events
Yoon & You Expires 7 January 2027 [Page 25]
Internet-Draft Collection Measurement YANG July 2026
+--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 11: 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: count-transient-event for immediate threshold
crossings, count-standing-event for persistent threshold violations,
snapshot-event for instantaneous value threshold crossings, and
tidemark-event for extreme value threshold crossings. 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 12 shows an example of the NETCONF request to subscribe to all
pm-threshold-events notifications in the ietf-pm-collection model.
Yoon & You Expires 7 January 2027 [Page 26]
Internet-Draft Collection Measurement YANG July 2026
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:sn=
"urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"
xmlns:pm-coll=
"urn:ietf:params:xml:ns:yang:ietf-pm-collection"
message-id="202">
<sn:establish-subscription>
<sn:stream>YANG-PUSH</sn:stream>
<sn:encoding>encode-xml</sn:encoding>
<sn:filter>
<sn:datastore>operational</sn:datastore>
<sn:xpath-filter>
/pm-coll:pm-threshold-events
</sn:xpath-filter>
</sn:filter>
<sn:period>1</sn:period>
<sn:anchor-time>2024-07-01T00:00:00Z</sn:anchor-time>
</sn:establish-subscription>
</rpc>
Figure 12: Threshold Event Subscription Example
Figure 13 reports a high-OOR-event threshold crossing for the
snapshot measurement of the ES parameter in the itu-transport-
maintenance-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 January 2027 [Page 27]
Internet-Draft Collection Measurement YANG July 2026
<notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"
xmlns:pm-coll=
"urn:ietf:params:xml:ns:yang:ietf-pm-collection">
<eventTime>2024-07-01T00:05:23Z</eventTime>
<pm-coll:pm-threshold-events>
<periodic-events>
<parameter-profile>
<name>itu-transport-maintenance-15min</name>
<pm-parameter>
<name>es</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>
<snapshot>
<event-type>High-OOR-event</event-type>
<event-occurred>true</event-occurred>
<event-time>2024-07-01T00:05:23Z</event-time>
</snapshot>
</event-types>
</collection-interval>
</sampling-interval>
</pm-parameter>
</parameter-profile>
</periodic-events>
</pm-coll:pm-threshold-events>
</notification>
Figure 13: Threshold Event Notification Example
5.3.2. Non-Periodic Threshold Events
Yoon & You Expires 7 January 2027 [Page 28]
Internet-Draft Collection Measurement YANG July 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 14: 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 measurements.
6. YANG Data Model
The YANG module for PM measurements is defined below:
<CODE BEGINS> file "ietf-pm-collection@2026-05-02.yang"
module ietf-pm-collection {
yang-version 1.1;
namespace
"urn:ietf:params:xml:ns:yang:ietf-pm-collection";
prefix pm-coll;
import ietf-yang-types {
prefix yang;
reference "RFC 6991: Common YANG Data Types";
}
organization
Yoon & You Expires 7 January 2027 [Page 29]
Internet-Draft Collection Measurement YANG July 2026
"IETF IP Performance Metrics (ippm) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/ippm/>
Editor: Bin Yeong Yoon <mailto:byyun@etri.re.kr>";
description
"This YANG module defines a data model for Collection
Measurement of performance management (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), as
defined in ITU-T G.7710.
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 measurements and non-periodic events (BUT, EUT,
CSES).
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. This hierarchical structure
allows operators, analytics systems, and digital twin
platforms to access performance data at appropriate
granularities while maintaining operational efficiency and
cross-vendor interoperability.
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.";
revision 2026-05-02 {
description
"Renamed the module from ietf-pm-measurements to
Yoon & You Expires 7 January 2027 [Page 30]
Internet-Draft Collection Measurement YANG July 2026
ietf-pm-collection (including namespace and prefix).
Terminology and model alignment: prior wording and the
measurement-methods container for counts, snapshot, and
tidemarks were replaced by collection types and the
collection-types container, per ITU-T G.7710 collection-
type concepts.";
reference
"RFC XXXX: A YANG Data Model for Collection Measurement";
}
/*
* 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:
- itu-transport-maintenance-15min
- itu-transport-maintenance-24hr
- itu-transport-qos-24hr
- ieee-access-availability";
}
typedef time-interval-unit {
type enumeration {
enum millisecond {
description "Time interval in milliseconds.";
}
enum second {
description "Time interval in seconds.";
}
Yoon & You Expires 7 January 2027 [Page 31]
Internet-Draft Collection Measurement YANG July 2026
enum minute {
description "Time interval in minutes.";
}
enum hour {
description "Time interval in hours.";
}
}
description "Units for expressing time intervals.";
}
/*
* IDENTITIES
*/
identity periodic-events {
description
"Base identity for periodic event notifications.";
}
identity counts-transient {
base periodic-events;
description
"Notification for transient threshold events in counts
measurements.";
}
identity counts-standing {
base periodic-events;
description
"Notification for standing threshold events in counts
measurements.";
}
identity snapshot {
base periodic-events;
description
"Notification for snapshot measurement threshold events.";
}
identity tidemarks {
base periodic-events;
description
"Notification for tidemarks measurement threshold events.";
}
identity non-periodic-events {
description
"Base identity for non-periodic event notifications.";
}
Yoon & You Expires 7 January 2027 [Page 32]
Internet-Draft Collection Measurement YANG July 2026
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 {
base non-periodic-events;
description
"Notification for Consecutive Severely Errored Seconds
(CSES) events.";
}
/*
* COMMON GROUPINGS
*/
grouping threshold-config {
description
"Common threshold configuration for snapshot and tidemarks
measurement 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 snapshot and tidemarks
measurements which support both high and low thresholds.";
Yoon & You Expires 7 January 2027 [Page 33]
Internet-Draft Collection Measurement YANG July 2026
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
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;
Yoon & You Expires 7 January 2027 [Page 34]
Internet-Draft Collection Measurement YANG July 2026
}
grouping count-transient-event-type {
description
"Transient threshold event type definition for counts
measurements. 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.";
}
}
description
"Specifies that a threshold crossing event occurred.";
}
}
grouping triggered-count-transient-event-info {
description
"Combined transient threshold event type and event
information for counts measurements. 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.";
}
}
/*
* COLLECTION TYPE GROUPINGS
*/
grouping count-collection-gr {
Yoon & You Expires 7 January 2027 [Page 35]
Internet-Draft Collection Measurement YANG July 2026
description
"Counts measurement for cumulative event tracking over a
collection interval. Supports transient and standing
threshold reporting, as defined in G.7710.";
container counts {
description
"Contains counts measurement 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 snapshot and tidemarks measurements 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
"Current cumulative count value for the collection
interval.";
Yoon & You Expires 7 January 2027 [Page 36]
Internet-Draft Collection Measurement YANG July 2026
}
}
}
grouping snapshot-collection-gr {
description
"Snapshot measurements for instantaneous values at uniform
time within each collection interval. Supports high/low
OOR threshold reporting, as defined in G.7710.";
container snapshot {
description
"Contains snapshot measurement configuration and values.";
container uniform-time-config {
description
"Configuration for uniform time intervals between
snapshots.";
leaf interval-value {
type uint32;
default 1;
description
"Numeric value for the sampling interval between
snapshots.";
}
leaf unit {
type time-interval-unit;
description
"Time unit for the snapshot sampling interval.";
}
}
container threshold-config {
description
"Configuration for snapshot threshold monitoring.";
uses threshold-config;
}
leaf collection-value {
type uint32;
config false;
description
"Current instantaneous snapshot value.";
}
}
}
grouping tidemarks-collection-gr {
description
"Tidemarks measurements for maximum and minimum values
over the collection interval. Supports high/low OOR
threshold reporting, as defined in G.7710.";
Yoon & You Expires 7 January 2027 [Page 37]
Internet-Draft Collection Measurement YANG July 2026
container tidemarks {
description
"Contains tidemarks measurement 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) per ITU-T G.7710.";
container collection-types {
description
"Container for the counts, snapshot, and tidemarks
collection types.";
uses count-collection-gr;
uses snapshot-collection-gr;
uses tidemarks-collection-gr;
}
}
/*
* EVENT GROUPINGS
*/
grouping counts-transient-event-gr {
description
"Transient threshold events for counts measurements.
Transient thresholds are independent threshold mechanisms
that report immediately when count values cross configured
Yoon & You Expires 7 January 2027 [Page 38]
Internet-Draft Collection Measurement YANG July 2026
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 counts measurements.";
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).";
}
}
description
"Specifies the type of standing threshold event that
occurred, as defined in G.7710. 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 snapshot measurements.";
Yoon & You Expires 7 January 2027 [Page 39]
Internet-Draft Collection Measurement YANG July 2026
container snapshot {
description
"Contains snapshot threshold event information.";
uses triggered-oor-event-info;
}
}
grouping tidemarks-events-gr {
description
"Threshold events for tidemarks measurements.";
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 measurement timing
and collection types.";
list sampling-interval {
key "id";
description
"List of sampling intervals defining data collection
frequency.";
leaf id {
type string;
description
"Unique identifier for this sampling interval
configuration.";
}
leaf interval-value {
type uint32;
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
Yoon & You Expires 7 January 2027 [Page 40]
Internet-Draft Collection Measurement YANG July 2026
"List of collection intervals defining aggregation
periods.";
leaf id {
type string;
description
"Unique identifier for this collection interval
configuration.";
}
leaf interval-value {
type uint32;
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.";
}
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;
Yoon & You Expires 7 January 2027 [Page 41]
Internet-Draft Collection Measurement YANG July 2026
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;
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 performance
measurements.";
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 string;
description
"Name of the performance parameter being measured.";
}
uses periodic-collection-intervals;
}
Yoon & You Expires 7 January 2027 [Page 42]
Internet-Draft Collection Measurement YANG July 2026
}
}
/*
* MAIN CONTAINER
*/
container pm-periodic-collection {
description
"Main container for periodic performance measurements.";
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 string;
description
"Name of the performance parameter being
monitored.";
}
list sampling-interval {
key "id";
description
"List of sampling intervals for event monitoring.";
leaf id {
type string;
description
Yoon & You Expires 7 January 2027 [Page 43]
Internet-Draft Collection Measurement YANG July 2026
"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;
}
}
}
<CODE ENDS>
7. YANG Data Trees
Yoon & You Expires 7 January 2027 [Page 44]
Internet-Draft Collection Measurement YANG July 2026
module: ietf-pm-collection
+--rw pm-periodic-collection
+--rw parameter-profile* [name]
+--rw name profile-names
+--rw pm-parameter* [name]
+--rw name string
+--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
+--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 interval-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
notifications:
+---n pm-threshold-events
+--ro periodic-events
| +--ro parameter-profile* [name]
| +--ro name profile-names
| +--ro pm-parameter* [name]
| +--ro name string
| +--ro sampling-interval* [id]
| +--ro id string
| +--ro interval-value? uint32
| +--ro unit? time-interval-unit
Yoon & You Expires 7 January 2027 [Page 45]
Internet-Draft Collection Measurement YANG July 2026
| +--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
+--ro end? yang:date-and-time
+--ro duration? uint32
+--ro error-count? uint32
Figure 15: Tree of pm measurements module
8. Manageability Considerations
This section will be completed in a future revision of this document.
Considerations to be addressed include the operational impact of
large numbers of concurrent YANG-Push subscriptions for PM data,
alignment of collection intervals with NE clock sources, and
interaction with existing fault and configuration management
workflows.
Yoon & You Expires 7 January 2027 [Page 46]
Internet-Draft Collection Measurement YANG July 2026
9. Security Considerations
This section will be completed in a future revision of this document.
The YANG module defined in this document defines data nodes that are
designed to be accessed via network management protocols such as
NETCONF [RFC6241] or RESTCONF. The lowest NETCONF layer is the
secure transport layer, and the mandatory- to-implement secure
transport is Secure Shell (SSH). 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.
Detailed analysis of sensitive readable nodes, writable nodes, and
RPC operations will be added in a future revision.
10. 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-coll Reference: RFC XXXX
11. References
11.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>.
[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>.
Yoon & You Expires 7 January 2027 [Page 47]
Internet-Draft Collection Measurement YANG July 2026
[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>.
[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>.
11.2. Informative References
[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>.
Yoon & You Expires 7 January 2027 [Page 48]
Internet-Draft Collection Measurement YANG July 2026
[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>.
[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>.
[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>.
[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
Yoon & You Expires 7 January 2027 [Page 49]
Internet-Draft Collection Measurement YANG July 2026
Youngkil You
woori-net
Email: young@woori-net.com
Yoon & You Expires 7 January 2027 [Page 50]