| Internet-Draft | PM Streaming Transport YANG | October 2026 |
| Yoon & You | Expires 2 May 2027 | [Page] |
This document applies the core Performance Monitoring (PM) collection and interval-capabilities YANG data models to common transport equipment. It defines a YANG module of transport performance parameter identities, derived from the base identity of the PM collection model; it specifies the three transport parameter profiles of ITU-T G.7710 normatively; and it gives end-to-end examples that show capability discovery followed by YANG-Push subscription, notification, and threshold reporting for a transport profile.¶
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-ccamp-pm-streaming.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-yoon-ccamp-pm-streaming/.¶
Discussion of this document takes place on the Common Control and Measurement Plane Working Group mailing list (mailto:ccamp@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/ccamp/. Subscribe at https://www.ietf.org/mailman/listinfo/ccamp/.¶
Source for this draft and an issue tracker can be found at https://github.com/binyeongyoon-ietf/ietf-pm-streaming.¶
Please replace "RFC XXXX" with the RFC number assigned to this document, and "RFC YYYY" with the RFC number assigned to [I-D.yoon-ippm-collection-measure], throughout this document and in the YANG module, and remove this note.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 2 May 2027.¶
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.¶
Performance Monitoring (PM) data generated by a transport Network Element (NE) is processed into summarized statistics and delivered to external clients. The continuous, push-based delivery of that data is referred to in this document as PM streaming.¶
This document depends on two core documents that define the technology-neutral models used here. The PM collection data model [I-D.yoon-ippm-collection-measure] defines the performance parameter structure, the sampling and collection interval hierarchy, the three collection types (counts, snapshot, and tidemarks), and the threshold-event notification. The interval-capabilities model [I-D.yoon-ippm-collection-interval-capabilities] lets a server advertise which intervals, measurement methods, and collection types it supports. Both models are generic and neutral to the transport technology.¶
This document specifies how those generic models are applied to common transport equipment. It defines a YANG module [RFC7950] of the transport performance parameters as identities, specifies the three transport profiles of ITU-T G.7710 normatively, and gives end-to-end examples of capability discovery, subscription, notification, and threshold reporting. This document does not define any new subscription or notification mechanism; the collected data and events are carried using the YANG-Push framework [RFC8639] [RFC8640] [RFC8641].¶
The term "client" refers to any consumer of the PM streaming interface of a transport NE, such as an operations system (OS), a Physical Network Controller (PNC), a network digital twin (NDT), or an AI-driven application. The term "transport" is used in the sense of [G7710] and covers technologies such as OTN, MPLS-TP, and transport Ethernet.¶
The tree diagrams in this document use the notation defined in [RFC8340].¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document is a technology-specific document that depends on the two core documents, as shown in Figure 1. Other technology-specific documents can depend on the core documents in the same way.¶
+--------------------------------------------------------+
| Core documents (technology-neutral) |
| |
| (1) ietf-pm-collection <---- (2) ietf-pm-interval- |
| PM collection imports capabilities |
| (base identity (augments |
| performance-parameter) RFC 9196) |
+--------------------------------------------------------+
^ ^
| imports | advertises
| (normative) | capabilities
+--------------------------------------------------------+
| Technology-specific documents |
| |
| (3) ietf-pm-parameters (THIS DOCUMENT): transport |
| (other documents for other technologies) |
+--------------------------------------------------------+
The documents play distinct, layered roles:¶
(1) The PM collection model [I-D.yoon-ippm-collection-measure] (module ietf-pm-collection) is the generic, transport-neutral core: the performance parameter structure and the "performance-parameter" base identity, the sampling and collection interval hierarchy, the three collection types (counts, snapshot, and tidemarks), and the threshold-event notification.¶
(2) The PM interval-capabilities model [I-D.yoon-ippm-collection-interval-capabilities] (module ietf-pm-interval-capabilities) imports the profile-names type and the performance-parameter identity from (1) and augments the "ietf-system-capabilities" module of [RFC9196], so that a server can advertise which sampling and collection intervals, measurement methods, and collection types it supports at the standard capability discovery anchor.¶
(3) This document (module ietf-pm-parameters) defines the transport-specific PM parameter identities, derived from the "performance-parameter" base identity of (1); specifies the transport profiles (see Section 4); and shows how the three modules are used together when PM data is streamed from common transport equipment.¶
This document's YANG module imports module (1) for the "performance-parameter" base identity; it does not import module (2). A "pm-parameter" entry of (1) identifies its parameter by one of the identities defined here, so that the parameter values collected under (1), and the capabilities advertised under (2), are interpreted using these identities. The normative collection and capability semantics remain in [I-D.yoon-ippm-collection-measure] and [I-D.yoon-ippm-collection-interval-capabilities]; this document adds the transport-specific parameter module (see Section 4.7), the normative definition of the transport profiles, and the applicability guidance.¶
The generic models are implemented within the Equipment Management Function (EMF) of a transport NE, as defined in ITU-T G.7710 [G7710]. The PM collection model [I-D.yoon-ippm-collection-measure] provides the data structures, the interval-capabilities model [I-D.yoon-ippm-collection-interval-capabilities] advertises the supported intervals, and the transport parameter module defined in this document (see Section 4.7) identifies the transport parameters that the profiles refer to. The data is exposed at the NE management interface and consumed by remote clients, as illustrated in Figure 2.¶
+------+ +-----+ +--------+
| OS | | NDT | ... | AI APP |
+---+--+ +--+--+ +----+---+
| | |
| PM data and notifications
| via YANG-Push (RFC 8639/8640/8641)
| | |
+---+--------+-------------+---+
| Transport NE |
| +-----------------------+ |
| | EMF / Collection | |
| | ietf-pm-collection(1)| |
| | + interval-caps (2) | |
| | + pm-parameters (3) | |
| +-----------------------+ |
+------------------------------+
OS: Operations System
NDT: Network Digital Twins
APP: Application
Metric values of PM parameters are measured for maintenance and QoS monitoring over transport networks. Quality of Service (QoS) parameters assess the network's long-term ability to deliver agreed-upon service quality. They verify performance against contractual obligations defined in service-level agreements (SLAs) over longer intervals (24 hours, monthly periods). By simultaneously measuring both directions of a bidirectional connection, QoS parameters provide a holistic view of the sustained quality experienced by users.¶
Maintenance parameters focus on short-term monitoring and detailed analysis for operational reliability. Over intervals such as 15 minutes or 24 hours, they enable swift responses to intermittent faults, bursts of errors, and subtle performance changes. Maintenance parameters typically involve unidirectional analysis, where each direction of transmission is monitored independently. This approach helps operators precisely pinpoint faults, troubleshoot intermittent issues, and perform preventive maintenance effectively.¶
The PM parameters of common transport equipment defined in [G7710] are listed below, together with the identity by which each is referred to in the "pm-parameter" list of [I-D.yoon-ippm-collection-measure]. Additional parameters may be needed for packet networks and can be defined in the same way by deriving further identities from "performance-parameter".¶
| Parameter | Identity | Description |
|---|---|---|
| ES | pm-pa:es | Errored Seconds |
| SES | pm-pa:ses | Severely Errored Seconds |
| BBE | pm-pa:bbe | Background Block Errors |
| BBC | pm-pa:bbc | Background Block Count |
| UAS | pm-pa:uas | Unavailable Seconds |
| SEP | pm-pa:sep | Severely Errored Period |
| PJE | pm-pa:pje | Pointer Justification Events |
All of the transport PM parameters listed above are obtained by passive measurement in the sense of [RFC7799]: they are derived from protocol counters and physical-layer signals already present on the monitored connection, without generating synthetic test traffic. When these parameters are configured through the PM collection model [I-D.yoon-ippm-collection-measure], the optional "measurement-method" leaf of each "pm-parameter" is therefore set to "passive".¶
According to collection types, purposes, and time intervals, different parameters are used. The following three transport profiles, named using the profile-naming format of the PM collection model [I-D.yoon-ippm-collection-measure], provide comprehensive coverage for maintenance and QoS monitoring across different temporal resolutions. The "transport" network token indicates that a profile applies across multiple transport technologies (for example OTN, MPLS-TP, and transport Ethernet). The normative definition of the profiles is given in Section 4.6.¶
The "itu-transport-maintenance-15min" profile is designed for short-term operational monitoring and rapid fault detection. It uses all three collection types (counts, snapshot, and tidemarks) over 15-minute intervals. The profile includes core maintenance parameters: ES, SES, BBE, BBC, and UAS.¶
The 15-minute interval enables operators to quickly detect and respond to performance degradation, making it ideal for proactive maintenance and immediate troubleshooting. The combination of counts (for cumulative event tracking), snapshot (for instantaneous state capture), and tidemarks (for extreme value monitoring) provides a comprehensive view of network behaviour within each collection interval. This profile is particularly valuable for network operations centres (NOCs) requiring real-time visibility into transport network health and for automated systems that need to trigger immediate responses to performance anomalies.¶
The "itu-transport-maintenance-24hr" profile extends maintenance monitoring to longer-term analysis and trend identification. Like the 15-minute profile, it employs all three collection types (counts, snapshot, and tidemarks) but over 24-hour intervals. The parameter set includes ES, SES, BBE, BBC, UAS, and additionally PJE.¶
The 24-hour interval allows for comprehensive daily performance analysis, enabling operators to identify patterns, trends, and recurring issues not apparent in shorter intervals. The inclusion of PJE provides additional insight into synchronisation-related performance issues that are more relevant over longer observation periods. This profile supports strategic maintenance planning, capacity management, and historical performance analysis. It complements the 15-minute profile by providing the broader context needed for long-term network optimisation and preventive maintenance strategies.¶
The "itu-transport-qos-24hr" profile is designed for QoS monitoring and SLA compliance verification. Unlike the maintenance profiles, it focuses exclusively on the counts collection type over 24-hour intervals, emphasising sustained performance assessment rather than detailed operational monitoring. The parameter set includes ES, SES, BBE, BBC, SEP, and UAS.¶
The exclusive use of counts reflects its focus on cumulative performance over extended periods, which is essential for SLA compliance and service quality reporting. The 24-hour interval aligns with typical SLA measurement periods and provides the statistical basis for service quality assessments. The inclusion of SEP is particularly relevant for QoS monitoring as it represents sustained periods of degraded performance that directly impact service quality commitments.¶
These three profiles work together to provide a comprehensive performance monitoring framework. The "itu-transport-maintenance-15min" profile serves as the primary operational tool for immediate network management, while the "itu-transport-maintenance-24hr" profile provides the analytical foundation for strategic planning and trend analysis. The "itu-transport-qos-24hr" profile ensures that service quality commitments are met and provides the data necessary for SLA reporting and customer assurance.¶
The hierarchical relationship between these profiles enables operators to correlate short-term operational events with long-term performance trends and service quality metrics. For example, a spike in ES detected by the 15-minute maintenance profile can be correlated with daily trends from the 24-hour maintenance profile and assessed against SLA thresholds defined in the QoS profile. This integrated approach supports both reactive troubleshooting and proactive network optimisation while ensuring compliance with service quality commitments.¶
The three transport profiles are defined in Table 2, which follows [G7710]. Each profile is an entry of the "parameter-profile" list of [I-D.yoon-ippm-collection-measure], keyed by the profile name, containing one "pm-parameter" entry for each listed parameter. Each "pm-parameter" entry has a "sampling-interval" entry and, within it, a "collection-interval" of the listed duration under which the listed collection types are enabled; its "measurement-method" is "passive".¶
| Profile | Parameters | Collection types | Sampling interval (default) | Collection interval |
|---|---|---|---|---|
| itu-transport-maintenance-15min | es, ses, bbe, bbc, uas | counts | 1 second | 15 minutes |
| itu-transport-maintenance-24hr | es, ses, bbe, bbc, uas, pje | counts | 1 second | 24 hours |
| itu-transport-qos-24hr | es, ses, bbe, bbc, uas, sep | counts | 1 second | 24 hours |
Collection is always performed on sampled values, so every profile entry has a sampling interval. The sampling interval in Table 2 is the default.¶
A server MAY provide a transport profile entry as system-defined configuration, in which case it is present in the operational datastore with origin "system" [RFC8342] without client configuration. A server MAY additionally support other collection intervals for the parameters of a profile, as advertised through [I-D.yoon-ippm-collection-interval-capabilities]; the sampling and collection intervals in Table 2 are the defaults of the transport profiles.¶
The following module defines the transport performance parameters as identities derived from "pm-co:performance-parameter" of [I-D.yoon-ippm-collection-measure]. The module defines no data nodes, so it has no tree diagram; its identities are summarised in Table 3.¶
| Statement | Name | Base / reference |
|---|---|---|
| identity | es, ses, bbe, bbc, uas, pje, sep | pm-co:performance-parameter |
<CODE BEGINS> file "ietf-pm-parameters@2026-10-29.yang"
module ietf-pm-parameters {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-pm-parameters";
prefix pm-pa;
import ietf-pm-collection {
prefix pm-co;
reference
"RFC YYYY: A YANG Data Model for Performance Monitoring (PM)
Collection";
}
organization
"IETF Common Control and Measurement Plane (ccamp)
Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/ccamp/>
Editor: Bin Yeong Yoon
<mailto:byyun@etri.re.kr>";
description
"This YANG module defines the performance monitoring (PM)
parameters of common transport equipment, based on ITU-T
G.7710, as identities derived from the performance-parameter
base identity of ietf-pm-collection. The three transport
parameter profiles (itu-transport-maintenance-15min,
itu-transport-maintenance-24hr, and itu-transport-qos-24hr)
are instances of the parameter-profile list of
ietf-pm-collection.
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-10-29 {
description
"Initial revision.";
reference
"RFC XXXX: A YANG Data Model for Performance Monitoring
Streaming on Common Transport Equipment";
}
/*
* IDENTITIES: transport performance parameters
*/
identity es {
base pm-co:performance-parameter;
description
"Errored Second (ES).";
reference
"ITU-T G.7710";
}
identity ses {
base pm-co:performance-parameter;
description
"Severely Errored Second (SES).";
reference
"ITU-T G.7710";
}
identity bbe {
base pm-co:performance-parameter;
description
"Background Block Error (BBE).";
reference
"ITU-T G.7710";
}
identity bbc {
base pm-co:performance-parameter;
description
"Background Block Count (BBC).";
reference
"ITU-T G.7710";
}
identity uas {
base pm-co:performance-parameter;
description
"Unavailable Second (UAS).";
reference
"ITU-T G.7710";
}
identity pje {
base pm-co:performance-parameter;
description
"Pointer Justification Event (PJE).";
reference
"ITU-T G.7710";
}
identity sep {
base pm-co:performance-parameter;
description
"Severely Errored Period (SEP).";
reference
"ITU-T G.7710";
}
}
<CODE ENDS>¶
This section shows the end-to-end flow for a transport profile, from capability discovery to subscription, notification, and threshold reporting. The examples use the SES parameter ("pm-pa:ses") of the "itu-transport-maintenance-15min" profile.¶
The client first reads the interval capabilities
[I-D.yoon-ippm-collection-interval-capabilities] for the parameter, to learn
which sampling and collection intervals, and which collection
types, the transport NE supports.
These capabilities are advertised by augmenting the
"ietf-system-capabilities" container of [RFC9196], so the client
retrieves them under "system-capabilities", the same anchor used for
subscription and notification capabilities. The client uses a NETCONF <get-data>
request [RFC8526] on the operational datastore, as shown in
Figure 3; the subtree filter selects the parameter by its list
keys, so the whole entry is returned.¶
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="301">
<get-data
xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
<datastore>ds:operational</datastore>
<subtree-filter>
<system-capabilities
xmlns=
"urn:ietf:params:xml:ns:yang:ietf-system-capabilities">
<pm-interval-capabilities
xmlns=
"urn:ietf:params:xml:ns:yang:ietf-pm-interval-capabilities"
xmlns:pm-pa=
"urn:ietf:params:xml:ns:yang:ietf-pm-parameters">
<parameter-profile>
<name>itu-transport-maintenance-15min</name>
<pm-parameter>
<name>pm-pa:ses</name>
</pm-parameter>
</parameter-profile>
</pm-interval-capabilities>
</system-capabilities>
</subtree-filter>
</get-data>
</rpc>
Figure 4 shows the "pm-interval-capabilities" data returned within "system-capabilities" in the reply.¶
<pm-interval-capabilities
xmlns=
"urn:ietf:params:xml:ns:yang:ietf-pm-interval-capabilities"
xmlns:pm-pa=
"urn:ietf:params:xml:ns:yang:ietf-pm-parameters">
<parameter-profile>
<name>itu-transport-maintenance-15min</name>
<pm-parameter>
<name>pm-pa:ses</name>
<supported-collection-types>counts</supported-collection-types>
<interval-relationships>
<sampling-interval>
<id>1s</id>
<min-value>1</min-value>
<max-value>1</max-value>
<units>second</units>
<default-value>1</default-value>
<default-unit>second</default-unit>
<granularity>1</granularity>
<collection-interval>
<id>collection-range</id>
<min-value>5</min-value>
<max-value>1440</max-value>
<units>minute</units>
<default-value>15</default-value>
<default-unit>minute</default-unit>
<granularity>5</granularity>
<retained-interval-count>1</retained-interval-count>
</collection-interval>
</sampling-interval>
</interval-relationships>
</pm-parameter>
</parameter-profile>
</pm-interval-capabilities>
The reply shows that the NE supports 1-second sampling and a collection interval range of 5 to 1440 minutes with 5-minute granularity, defaulting to 15 minutes, and that it supports the counts collection type for the parameter, and that it retains the most recently completed collection interval. The client therefore selects a 1-second sampling interval, a 15-minute collection interval, and the counts collection type, which the NE supports.¶
Using the supported intervals, the client establishes a periodic YANG-Push subscription [RFC8641] to the counts collection value in the operational datastore. The period is expressed in centiseconds and is set to 90000 (900 seconds), so that an update is sent once per 15-minute collection interval.¶
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="101">
<establish-subscription
xmlns=
"urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"
xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push"
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
<yp:datastore>ds:operational</yp:datastore>
<yp:datastore-xpath-filter
xmlns:pm-co="urn:ietf:params:xml:ns:yang:ietf-pm-collection"
xmlns:pm-pa="urn:ietf:params:xml:ns:yang:ietf-pm-parameters">
/pm-co:pm-periodic-collection/
parameter-profile[name='itu-transport-maintenance-15min']/
pm-parameter[name='pm-pa:ses']/
sampling-interval[id='1s']/
collection-interval[id='15min']/
collection-types/counts/collection-value
</yp:datastore-xpath-filter>
<encoding>encode-xml</encoding>
<yp:periodic>
<yp:period>90000</yp:period>
<yp:anchor-time>2026-07-01T00:00:00Z</yp:anchor-time>
</yp:periodic>
</establish-subscription>
</rpc>
Once per period the NE sends a "push-update" notification [RFC8641] for the subscription, whose identifier returned by the NE is 39. The update contains the selected data only. The collected value of 5 is the total severely errored seconds in the period.¶
<notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2026-07-01T00:15:00Z</eventTime>
<push-update xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push">
<id>39</id>
<datastore-contents>
<pm-periodic-collection
xmlns="urn:ietf:params:xml:ns:yang:ietf-pm-collection"
xmlns:pm-pa=
"urn:ietf:params:xml:ns:yang:ietf-pm-parameters">
<parameter-profile>
<name>itu-transport-maintenance-15min</name>
<pm-parameter>
<name>pm-pa:ses</name>
<sampling-interval>
<id>1s</id>
<collection-interval>
<id>15min</id>
<collection-types>
<counts>
<collection-value>5</collection-value>
</counts>
</collection-types>
</collection-interval>
</sampling-interval>
</pm-parameter>
</parameter-profile>
</pm-periodic-collection>
</datastore-contents>
</push-update>
</notification>
The client can also subscribe to threshold events. Threshold events are YANG notifications, not datastore data, so the client subscribes to an event stream, here the "NETCONF" event stream, using subscribed notifications [RFC8639], without a datastore or a period. When the counts value crosses the configured transient threshold during the interval, a Threshold Report is delivered using the "pm-threshold-events" notification of the PM collection model. No transport-specific event mechanism is required.¶
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="102">
<establish-subscription
xmlns=
"urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
<stream>NETCONF</stream>
<stream-xpath-filter
xmlns:pm-co="urn:ietf:params:xml:ns:yang:ietf-pm-collection">
/pm-co:pm-threshold-events
</stream-xpath-filter>
<encoding>encode-xml</encoding>
</establish-subscription>
</rpc>
<notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2026-07-01T00:09:00Z</eventTime>
<pm-threshold-events
xmlns="urn:ietf:params:xml:ns:yang:ietf-pm-collection"
xmlns:pm-pa=
"urn:ietf:params:xml:ns:yang:ietf-pm-parameters">
<periodic-events>
<parameter-profile>
<name>itu-transport-maintenance-15min</name>
<pm-parameter>
<name>pm-pa:ses</name>
<sampling-interval>
<id>1s</id>
<collection-interval>
<id>15min</id>
<event-types>
<counts-transient>
<event-type>Threshold-Crossed-Event</event-type>
<event-occurred>true</event-occurred>
<event-time>2026-07-01T00:09:00Z</event-time>
</counts-transient>
</event-types>
</collection-interval>
</sampling-interval>
</pm-parameter>
</parameter-profile>
</periodic-events>
</pm-threshold-events>
</notification>
On transport equipment the following points apply. Collection intervals should align with the NE clock source so that interval boundaries are consistent across the network and snapshots taken at a uniform time can be correlated across NEs. A transport NE may serve many parameters across many monitored objects (links, tunnels, equipment sensors), so operators should consider the load of large numbers of concurrent subscriptions and choose profiles and intervals accordingly. Threshold events, both periodic and the non-periodic BUT, EUT, and CSES events, are carried in the notification defined by the PM collection model.¶
This section is to be removed before publication.¶
The representation of the transport profiles in YANG is left for discussion in the Working Group. The profile contents (parameters, collection types, and default intervals) are given in Table 2. What remains open is how a server indicates the profiles it supports, and how the applicability of each parameter to a given transport layer is expressed. Candidates, none of which requires changes to the core documents, include one YANG feature per profile advertised in the YANG library [RFC8525], the profiles published as YANG instance data [RFC9195], and the capability advertisement of [I-D.yoon-ippm-collection-interval-capabilities].¶
The YANG module defined in this document defines only identities; it defines no data nodes, RPCs, actions, or notifications, and therefore introduces no new data that could be read, written, or delivered through network management protocols. The identities defined here are used as values of the "pm-parameter" name leaf of [I-D.yoon-ippm-collection-measure] and of [I-D.yoon-ippm-collection-interval-capabilities]; the security considerations of those documents apply to the data nodes in which these identities appear. Those data nodes are designed to be accessed via NETCONF [RFC6241] or RESTCONF over a secure transport such as SSH, with access restricted using the Network Configuration Access Control Model (NACM) [RFC8341]. The security considerations of the YANG-Push framework [RFC8639] [RFC8641] also apply.¶
The exposed performance and capability data can reveal information about the transport network; operators may wish to restrict access accordingly.¶
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-parameters 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 [RFC6020]:¶
Name: ietf-pm-parameters Namespace: urn:ietf:params:xml:ns:yang:ietf-pm-parameters Prefix: pm-pa Reference: RFC XXXX¶