]> ETRI

byyun@etri.re.kr

woori-net

young@woori-net.com

IPPM Working Group performance management interval capabilities capability advertisement YANG This document defines a YANG data model, "ietf-pm-interval-capabilities", that enables a server to advertise which collection intervals it can support. A client reads this capability information before configuring performance measurements, so that it selects only sampling and collection intervals that the server can honour. The capabilities are advertised by augmenting the "ietf-system-capabilities" module defined in , so that a client discovers them at the same well-known location used for subscription and notification capabilities. The model imports the "profile-names" type from the companion collection measurement model defined in and mirrors its profile-and-parameter structure, ensuring direct alignment between capability discovery and measurement configuration. The model does not define measurement data structures or any delivery mechanism; those are defined in the companion document. The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction The collection measurement data model defined in allows a client to configure sampling and collection intervals for performance parameters within named parameter profiles. The same parameter may require different intervals depending on its type and monitoring objective, and different network elements support different ranges and granularities of intervals. Without a prior discovery step, a client risks configuring interval values that the server cannot honour, leading to configuration errors or suboptimal monitoring. This document defines a YANG data model , "ietf-pm-interval-capabilities", for advertising the collection collection interval capabilities a server supports. A client reads this information from the operational datastore before it configures measurements. The model mirrors the profile-and-parameter structure of the companion collection measurement model and reuses its "profile-names" type, so that capability discovery aligns directly with measurement configuration. Rather than defining a separate top-level container, this module augments the "system-capabilities" container of the "ietf-system-capabilities" module defined in . RFC 9196 provides a placeholder structure that other modules augment to expose YANG-related system capabilities; the companion module "ietf-notification-capabilities" (Section 3 of ) uses the same anchor to advertise subscription and notification capabilities. By augmenting the same anchor, this module lets a NETCONF or RESTCONF client discover the measurement interval capabilities and the subscription capabilities through a single, standardised query, without prior knowledge of this module's own layout. This document does not define measurement data structures, collection types, threshold events, or any delivery mechanism. All of those are defined in the companion document .

Terminology The terms "client", "server", "datastore", and "operational state" are used as defined in and . 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 when, and only when, they appear in all capitals, as shown here.

Relationship to Companion Documents This document and together provide the functional coverage that was originally combined in a single document, draft-yoon-ccamp-pm-streaming. The original document defined both the PM collection data model and the interval capability model in one place and focused on push-based streaming as the delivery mechanism. The two documents have been separated to achieve cleaner separation of concerns and to make the models delivery-mechanism neutral. The functional division is as follows. defines "ietf-pm-collection", which covers: Parameter profiles and PM parameter groupings Three collection types: Counts, Snapshot, and Tidemarks (per ITU-T G.7710 ) Configurable sampling and collection intervals Threshold event notifications (periodic and non-periodic) Data structures accessible via pull-based retrieval (NETCONF, RESTCONF) or push-based subscription (YANG-Push) This document defines "ietf-pm-interval-capabilities", which covers: Read-only advertisement of the sampling and collection interval ranges, units, defaults, and granularity that a server supports Hierarchical alignment with the companion model's profile-and- parameter structure Capability discovery prior to measurement configuration The separation of concerns is: "What data is collected and how it is structured" is in . "Which interval configurations the server can support" is in this document. illustrates the relationship between the two YANG modules.

Motivation ITU-T G.7710 does not include a clause that mandates a capability-discovery mechanism for configurable measurement timing parameters. However, because sampling and collection intervals are configurable, a client needs to know in advance which intervals a given server can support, so that requests can be built without violating implementation constraints. This module provides that advertisement.

Monitoring Objectives Require Different Intervals The same PM parameter may need to be collected simultaneously at multiple sampling and collection interval combinations, each serving a distinct operational objective. As illustrated by the use cases in , Errored Seconds (ES) sampled every second may be aggregated over a 1-minute interval for rapid fault detection in a Network Operations Center (NOC), over a 15-minute interval for routine maintenance monitoring aligned with ITU-T G.7710 , and over a 24-hour interval for daily QoS reporting -- all three objectives active concurrently on the same parameter. Similarly, latency parameters may be sampled at sub-second granularity with short collection intervals for digital twin synchronization, or at longer intervals for AI/ML model training. A client wishing to configure all of these combinations for all parameters in a profile must first verify that the target server supports every required interval. Without a capability discovery step, the client has no way to know whether a desired combination is valid on the specific server, and may submit configurations that the server silently truncates, rejects, or rounds to the nearest supported value.

Equipment Performance Determines Achievable Intervals Beyond monitoring objective, the processing capacity of the network element itself directly determines which interval configurations are feasible for a given parameter. Network elements vary significantly in their measurement engines and hardware resources. High-performance network elements with dedicated measurement processors can support short minimum sampling intervals and fine-grained collection interval steps, enabling high-resolution monitoring for demanding use cases such as real-time fault detection, network digital twins, and AI-driven analytics. For example, such a device may support a 100-millisecond sampling interval for ES, with collection intervals as short as 1 minute and a 5-second granularity step. Lower-specification network elements, constrained by processing resources or hardware architecture, may support only longer minimum intervals and coarser granularity steps. The same ES parameter on such a device might have a minimum sampling interval of 1 second and a minimum collection interval of 15 minutes, adequate for traditional operations and maintenance monitoring but insufficient for sub-minute analytics. shows an example comparison for the ES parameter. Equipment class Min. sampling Min. measurement Granularity High-performance 100 ms 1 min 5 s Standard 1 s 1 min 1 min Low-specification 1 s 15 min 15 min A client operating across a heterogeneous network cannot assume a uniform interval floor and must discover the capabilities of each network element individually. The interval capability model enables a client to select the highest-resolution intervals a given server supports for each operational objective, rather than applying a conservative lowest-common-denominator configuration across all devices.

Multi-Vendor Interoperability Equipment from different vendors supports different ranges and granularities of intervals, and may impose implementation-specific constraints on the relationship between sampling and collection intervals. In multi-vendor networks, clients must adapt to the capabilities of each element. Without a discovery mechanism, clients risk configuration failures, suboptimal monitoring, or system instability. A standardised capability model addresses these challenges and enables interoperability across diverse network environments.

Structure and the Sampling/Measurement Relationship The module follows a hierarchical structure that mirrors the measurement configuration model defined in , ensuring consistency between capability discovery and actual configuration. It has three levels: parameter profiles (collections of related parameters such as "itu-transport-maintenance-15min"), PM parameters (individual parameters such as ES, SES, BBE), and interval capabilities (supported sampling and collection intervals for each parameter). The model defines a key relationship: a collection interval MUST be a multiple of its corresponding sampling interval. This ensures that aggregation periods align with the data collection frequency. For example, if a server supports a 5-second sampling interval, valid collection intervals are 5s, 10s, 15s, 30s, 60s, and so on. The relationship is expressed structurally by nesting collection intervals within their corresponding sampling interval entry. For each interval, the model advertises: min-value: minimum supported numeric value max-value: maximum supported numeric value units: list of supported time units (e.g., second, minute) default-value: recommended default numeric value default-unit: recommended default time unit granularity: step size; valid values must be multiples of this Once a client knows the supported intervals, it can pair a single supported sampling interval with several supported collection intervals to serve different operational purposes for the same parameter. The "Use Cases" section of gives concrete examples of such combinations, which motivate the ranges and granularities a server advertises here.

Capability Discovery and Configuration Workflow A client performs the following three steps to configure and access collection measurements correctly. Steps 2 and 3 use the companion model defined in ; Step 1 uses the model defined in this document.

| |<--pm-interval-capabilities-------- | | | | Step 2: Configure measurement | | [ietf-pm-collection] | |---NETCONF edit-config-----------> | |<--OK------------------------------ | | | | Step 3: Access data | | [ietf-pm-collection] | | | | Option A: Pull (polling) | |---NETCONF get-data--------------> | |<--collection-value--------------- | | | | Option B: Push (YANG-Push) | |---establish-subscription--------> | |<--periodic-notifications---------- | | | ]]>

Step 1 -- Discover interval capabilities (this document). On session establishment, the server's YANG Library and capability information indicate whether "ietf-pm-collection" and "ietf-pm-interval-capabilities" are both supported. The client queries the "pm-interval-capabilities" container, which this module augments into the "system-capabilities" container of "ietf-system-capabilities" . Because that container is "config false", the augmented nodes inherit "config false" and reside in the operational datastore per the Network Management Datastore Architecture (NMDA) . Querying the same anchor also returns any subscription and notification capabilities advertised there by "ietf-notification-capabilities" (Section 3 of ). From it, the client retrieves the supported sampling and collection intervals for each parameter and profile, including the minimum and maximum values, allowed units, and granularity. This runtime exposure follows the model described in for advertising capabilities in operational state. The same information MAY also be published as static instance data using the format defined in . The interval ranges advertised here correspond to the Measurement Timing aspect of the Performance Metric Specification described in Section 5.4.2 of ; this document provides the runtime discovery of those timing constraints, which the companion model then applies when measurements are configured. Step 2 -- Configure measurements (companion document). The client configures the "pm-periodic-collection" container defined in "ietf-pm-collection" , selecting only sampling and collection interval values that Step 1 confirmed the server supports. This avoids configuration errors such as an unsupported interval being rejected during collection setup or subscription establishment. Step 3 -- Access data (companion document). The client accesses the collected PM data using either pull-based retrieval or push-based subscription, both supported by "ietf-pm- collection". For pull-based access, the client issues NETCONF "get-data" or RESTCONF GET operations against the operational datastore to read current measurement values. For push-based access, the client establishes a YANG-Push subscription per , , to receive periodic or threshold-triggered notifications.

Interval Capabilities Example shows a NETCONF <get> request that retrieves the interval capabilities for the ES parameter in the "itu-transport-maintenance-15min" profile.

itu-transport-maintenance-15min es 1s 1 1 second 1 second 1 collection-range 5 1440 minute 15 minute 5 ]]>

The response indicates that the server supports 1-second sampling and a collection interval range of 5 to 1440 minutes with 5-minute granularity, with a default of 15 minutes. Using this information, the client can configure the ES parameter in "ietf-pm-collection" with any collection interval that is a multiple of 5 within the range 5 to 1440 minutes, knowing the server will accept the configuration.

Tree Diagram The following tree diagram, using the notation defined in , shows the structure of the "ietf-pm-interval-capabilities" module.

YANG Module

Editor: Bin Yeong Yoon "; description "This YANG module defines a data model for advertising performance management (PM) collection interval capabilities in network equipment. The module enables clients to discover which sampling and collection intervals a server supports for different performance parameters within various parameter profiles, before configuring collection measurements. This module provides hierarchical interval capability discovery where collection intervals must be multiples of their corresponding sampling intervals, and each parameter can have different interval capabilities within each parameter profile. This module imports the profile-names type from ietf-pm-collection and mirrors its profile-and-parameter structure. It does not define measurement data structures, collection types, or any delivery mechanism; those are defined in ietf-pm-collection. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. Copyright (c) 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-06-11 { description "Initial revision as standalone interval capability module, separated from the combined PM streaming document and updated to import ietf-pm-collection. The interval capabilities are advertised by augmenting the system-capabilities container defined in RFC 9196."; reference "RFC XXXX: A YANG Data Model for Collection Interval Capabilities"; } /* * TYPEDEFs */ typedef 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 { description "Time interval in hours."; } enum day { description "Time interval in days."; } } description "Supported units for expressing time intervals."; } /* * GROUPINGS */ grouping interval-constraints { description "Capability constraints for a single interval type, covering the supported range, units, default, and granularity. Used for both sampling intervals and collection intervals."; leaf min-value { type uint32; description "Minimum supported value for this interval."; } leaf max-value { type uint32; description "Maximum supported value for this interval."; } leaf-list units { type interval-unit; description "List of supported time units for this interval."; } leaf default-value { type uint32; description "Default value recommended for this interval."; } leaf default-unit { type interval-unit; description "Default unit recommended for this interval."; } leaf granularity { type uint32; description "Granularity step for interval values. Only values that are multiples of this granularity are supported. For example, if granularity is 5, valid values are 5, 10, 15, 20, and so on."; } } grouping parameter-interval-capabilities { description "Interval capabilities for a single PM parameter within a profile. The structure nests collection intervals within their corresponding sampling interval, reflecting the constraint that collection intervals must be multiples of their sampling interval."; leaf name { type string; description "Name of the performance parameter (e.g., es, ses, bbe). This value corresponds to the pm-parameter name leaf in ietf-pm-collection."; } container interval-relationships { description "Hierarchical relationships between sampling and collection intervals for this parameter. Collection intervals MUST be multiples of their corresponding sampling intervals."; list sampling-interval { key "id"; description "List of supported sampling intervals and their compatible collection intervals."; leaf id { type string; description "Unique identifier for this sampling interval capability entry."; } uses interval-constraints; list collection-interval { key "id"; description "List of supported collection intervals for this sampling interval."; leaf id { type string; description "Unique identifier for this collection interval capability entry."; } uses interval-constraints; } } } } grouping profile-parameter-capabilities { description "Interval capabilities for all PM parameters within a single parameter profile."; leaf name { type pm-coll:profile-names; description "Name of the parameter profile. This value corresponds to the parameter-profile name leaf in ietf-pm-collection (e.g., itu-transport-maintenance-15min)."; } list pm-parameter { key "name"; description "List of PM parameters and their interval capabilities within this profile."; uses parameter-interval-capabilities; } } /* * AUGMENTATION OF ietf-system-capabilities (RFC 9196) * * The interval capabilities are advertised by augmenting the * "system-capabilities" container defined in RFC 9196. This * places the PM measurement interval capabilities at the same * well-known location at which a NETCONF/RESTCONF client * discovers subscription and notification capabilities * (ietf-notification-capabilities, RFC 9196 Section 3), so that * both can be retrieved in a single, standardised query. The * "pm-interval-capabilities" wrapper container cleanly separates * this capability group from other capabilities augmented into * the same anchor. All augmented nodes inherit "config false" * from sysc:system-capabilities and therefore reside in the * operational datastore. */ augment "/sysc:system-capabilities" { description "Augments the system capabilities with PM collection interval capabilities, advertising the sampling and collection intervals that this server supports, organised by parameter profile and PM parameter."; container pm-interval-capabilities { description "Read-only advertisement of the sampling and collection interval capabilities of this server, organised by parameter profile and PM parameter. A client reads this container to determine which interval values are valid before configuring measurements in ietf-pm-collection."; list parameter-profile { key "name"; description "List of parameter profiles and their per-parameter interval capabilities."; uses profile-parameter-capabilities; } } } } ]]>

Manageability Considerations A server SHOULD ensure that the capabilities advertised in "pm-interval-capabilities" remain consistent with its actual ability to honour interval configurations in "ietf-pm-collection". If a server's resources change dynamically (e.g., due to load), it SHOULD update the operational datastore accordingly, and clients that have already configured measurements using previously advertised values SHOULD be notified through standard NETCONF or YANG-Push mechanisms. Operators SHOULD verify that the interval values configured in "ietf-pm-collection" fall within the ranges advertised in this module before deploying measurement configurations in production.

Security Considerations The YANG module defined in this document defines data nodes that are designed to be accessed via network management protocols such as NETCONF or RESTCONF. The module augments the "system-capabilities" container of "ietf-system-capabilities" , which is "config false"; all nodes added by this module therefore inherit "config false" and reside in the operational datastore. Following the guidance in , this section documents the security considerations of the augmented nodes. 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) 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. Although all nodes are read-only, the capability information they expose can reveal vendor-specific implementation details about the equipment, such as supported interval ranges and granularities. Operators SHOULD restrict read access to authorised management clients to prevent unintended disclosure of device implementation characteristics.

IANA Considerations This document requests IANA to register the following URI in the "ns" subregistry within the "IETF XML Registry" : URI: urn:ietf:params:xml:ns:yang:ietf-pm-interval-capabilities Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. This document requests IANA to register the following YANG module in the "YANG Module Names" registry : Name: ietf-pm-interval-capabilities Namespace: urn:ietf:params:xml:ns:yang:ietf-pm-interval-capabilities Prefix: ipc Reference: RFC XXXX

YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK] The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language. The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536. Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950. This document describes a YANG library that provides information about the YANG modules, datastores, and datastore schemas used by a network management server. Simple caching mechanisms are provided to allow clients to minimize retrieval of this information. This version of the YANG library supports the Network Management Datastore Architecture (NMDA) by listing all datastores supported by a network management server and the schema that is used by each of these datastores. This document defines two YANG modules, "ietf-system-capabilities" and "ietf-notification-capabilities". The module "ietf-system-capabilities" provides a placeholder structure that can be used to discover YANG-related system capabilities for servers. The module can be used to report capability information from the server at runtime or at implementation time by making use of the YANG instance data file format. The module "ietf-notification-capabilities" augments "ietf-system-capabilities" to specify capabilities related to "Subscription to YANG Notifications for Datastore Updates" (RFC 8641). ETRI ITU-T In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document defines a YANG data model and associated mechanisms enabling subscriber-specific subscriptions to a publisher's event streams. Applying these elements allows a subscriber to request and receive a continuous, customized feed of publisher-generated information. This document describes a mechanism that allows subscriber applications to request a continuous and customized stream of updates from a YANG datastore. Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state. This document provides a Network Configuration Protocol (NETCONF) binding to the dynamic subscription capability of both subscribed notifications and YANG-Push. This document describes a framework and a process for developing Performance Metrics of protocols and applications transported over IETF-specified protocols. These metrics can be used to characterize traffic on live networks and services. This memo documents an Internet Best Current Practice. There is a need to document data defined in YANG models at design time, implementation time, or when a live server is unavailable. This document specifies a standard file format for YANG instance data, which follows the syntax and semantics of existing YANG models and annotates it with metadata. This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.

Acknowledgments The interval capability model in this document is derived from the PM interval capabilities work originally defined in draft-yoon-ccamp-pm-streaming, and has been separated into this standalone document to complement the collection measurement model in draft-yoon-ippm-collection-measure.

Contributors KT

kwangkoog.lee@kt.com

SK Telecom

jongyoon.shin@sk.com

LGU+

sy.nam@lguplus.co.kr