| Internet-Draft | Operational KPI Semantics | October 2026 |
| Soumplis | Expires 10 April 2027 | [Page] |
Closed-loop management of IP-connected edge-cloud services depends on measurements that retain their meaning across collectors, processing pipelines, and administrative domains. A metric name and numeric value are insufficient to determine whether a measurement can be compared, combined, or used at a particular decision time. This document proposes a compact operational profile connecting KPI definitions to observation scope, statistical populations, time windows, freshness, and data-quality evidence. It supplies calculation conventions for five KPI families, a consumer eligibility procedure, and worked examples. The profile is intended to complement existing telemetry and metric-definition mechanisms. It introduces no transport protocol, YANG module, or IANA registration.¶
This note is to be removed before publishing as an RFC.¶
This is an individual contribution proposed for discussion in the Network Management Operations (NMOP) working group. It does not represent working group consensus. The NMOP mailing list is mailto:nmop@ietf.org and its archive is https://mailarchive.ietf.org/arch/browse/nmop/.¶
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 10 April 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.¶
A controller may select a service endpoint, change traffic steering, or scale an edge-hosted network function using telemetry from several sites. Two sites can export a metric called latency while measuring different paths, populations, or statistics. Even a correctly identified metric can be unsuitable at a decision epoch because its observation interval is old, its denominator is incomplete, or its service-instance binding predates a migration. Consistent encoding alone does not resolve these conditions.¶
The telemetry framework in [RFC9232] describes the wider collection and consumption setting. Metric definitions and measurement methods already have established guidance in [RFC6390] and a registry framework in [RFC8911]. This proposal uses those foundations and concentrates on a consumer-facing question: what evidence is needed before a reported KPI can be used for a particular operational decision?¶
The contribution is a set of explicit calculation and eligibility conventions, rather than a claim that measurement metadata are new. It combines a reusable definition descriptor, an observation record, and a decision policy; distinguishes semantic comparability from data quality and timeliness; and illustrates errors that arise when these checks are omitted. All numerical examples are constructed examples, not reported deployments or performance measurements.¶
The intended setting is operation of IP networks and services delivered over them, including service endpoints and virtual network functions placed across edge and cloud sites. Application and resource measurements are considered only as inputs to network/service management decisions. General cloud scheduling, new measurement protocols, standardization of external platforms, anomaly vocabularies, and incident-management workflows are outside scope. Suitability for NMOP progression remains a matter for working group discussion.¶
This Informational proposal uses ordinary-language recommendations. It does not use the BCP 14 requirement vocabulary or claim conformance to an existing IETF standard. In this document, a profile-complete record is one that satisfies the proposed checklist; that designation does not certify the accuracy of its producer or authorize a control action.¶
KPI: a defined statistic used to assess a service objective or operational condition. A scalar is an observation of a KPI, not its definition.¶
Descriptor: a versioned description of the metric, measurement method, population rules, and aggregation semantics.¶
Observation: a value or explicit non-value state, bound to a descriptor, entity scope, measurement interval, and supporting quality information.¶
Decision policy: consumer configuration stating the intended comparison, acceptable methods, maximum ages, required completeness, and permitted fallback.¶
Measurement point: an instrumentation boundary or pair of boundaries. Scope identifies the entity or population being assessed; it is not interchangeable with the measurement point.¶
Population: the requests, probes, samples, resources, or events eligible to contribute to a statistic under its inclusion and exclusion rules.¶
A steering policy compares a one-minute request-latency p95 at a service ingress with a five-minute mean of internal processing time. The latter omits network and queueing components and is not an alternative estimate of the former.¶
A broker replays a ten-minute-old KPI with a new collection timestamp. Testing collection age alone accepts data that describe an obsolete service state.¶
A retrying client reports final request success, while another source reports success per individual attempt. Identical units and windows do not give these ratios the same denominator.¶
A post-migration KPI carries a service identifier but no instance generation or effective binding. A controller attributes an old instance's load to its replacement.¶
A missing telemetry stream is converted to zero utilization, triggering placement onto a site whose actual resource state is unknown.¶
The profile separates slowly changing definitions from per-observation evidence and consumer policy. A deployment can transmit a descriptor inline or by an authenticated reference. A reference identifies immutable content at a stated revision; changing interpretation requires a new revision. A consumer that cannot resolve the referenced revision treats the observation as unknown, rather than applying the newest available definition. Caching is permitted under the same content-identity rule.¶
Identity: a definition identifier and revision, a human-readable name, and a reference to the measurement specification. Registered metric identifiers are reused when applicable. A display name alone is not an identity.¶
Measurement semantics: measured quantity, point roles and boundaries, direction, active or passive method, request/packet/probe selection, and relevant parameters such as timeout, retry, and cancellation rules.¶
Population and scope roles: entity type, intended population, inclusion and exclusion predicates, and the meaning of domain, service, site, and instance identifiers. The descriptor defines roles; the observation supplies their actual values.¶
Output semantics: quantity kind, unit, scale, statistic, estimator, resolution, and permitted ranges. Percentiles include their quantile and exact or approximate estimation method. Approximation-error metadata state whether error is in rank or value.¶
Time semantics: cohort assignment event, window type, width and alignment, endpoint convention, sampling method/cadence, expected reporting cadence, and rules for late data and finalized results.¶
Aggregation rules: sufficient statistics, weighting, deduplication, disjointness or overlap handling, and reset/discontinuity detection. Unsupported transformations are explicitly excluded.¶
Extensions: namespaced identifiers and a declaration of whether each extension can affect interpretation. Unknown interpretation-affecting extensions prevent eligibility; unknown descriptive extensions may be ignored.¶
Binding: descriptor identity/revision; producer identity and producer epoch; observation identity/revision; scoped service, site, instance, and domain identifiers where applicable; and a binding generation or effective interval where identities can be reused.¶
Value state: a numeric value with sufficient supporting statistics, or an explicit state such as no-observations, unavailable, or invalid. Missing, censored, and failed observations are not represented as successful zero-valued measurements.¶
Timing: actual observation start/end, generation time, available collection time, and the clock basis and uncertainty needed to compare relevant timestamps. An instantaneous observation uses a measurement timestamp instead of a population interval.¶
Quality: observed and expected counts where meaningful, missing/censored counts, completeness state, applicable uncertainty/error bounds, and whether the observation is provisional or final.¶
Lineage: source references and transformations sufficient to distinguish duplicate/replayed records from independent measurements and to audit the statistic. Sensitive raw identifiers need not be exported.¶
For UTC timestamps, an implementation can use the format in [RFC3339]. All timestamps compared in an age calculation need a shared interpretation of time and a bound on their relative error. Reporting a UTC string does not establish synchronization. Expected count is applicable to a known schedule or independently enumerated cohort; it is not inferred from the number of records that happened to arrive.¶
A policy identifies the intended KPI definition and acceptable revisions or explicit equivalence mappings, the permitted comparison dimensions, allowed normalization, required finality, maximum window width, minimum sample count or coverage, estimator-error limits, and bounds on age and clock uncertainty. These thresholds depend on the control task; this document prescribes no universally safe freshness interval or minimum number of samples. Policy revision and the chosen observations should be retained with the decision record.¶
Semantic comparability is policy-relative. A cross-site comparison deliberately permits different site and instance identifiers, but requires equivalent service roles, measurement boundaries, traffic classes, statistics, and relevant methods. Equal identifier strings from different naming authorities do not establish identity. Conversely, requiring all entity identifiers to be identical would incorrectly prohibit the intended cross-site comparison. Eligible measurements still need not represent equal workloads or predict the result of a traffic move.¶
The table below summarizes which information a profile-complete record carries unconditionally and which is conditional. A conditional item is needed whenever its condition applies; where the condition does not apply, its absence is not a defect. The table supplies the information a consumer needs in order to evaluate the eligibility procedure of Section 7; carrying it does not by itself make a record eligible, since the outcome still depends on the policy checks, including compatibility, completeness, and freshness.¶
| Part | Information | Requirement |
|---|---|---|
| Descriptor | Identity and revision; measured quantity; measurement point roles; method; unit; statistic | Required |
| Descriptor | Population and cohort rules; window type, width and alignment; finalization rule | Conditional: interval or cohort statistics; an instantaneous measurement instead identifies its measurement timestamp |
| Descriptor | Quantile and estimator detail | Conditional: percentile statistics |
| Descriptor | Aggregation and merge rules | Conditional: records that may be combined |
| Descriptor | Extension declarations | Conditional: extensions present |
| Observation | Descriptor identity and revision; scoped entity identifiers; value or explicit non-value state; observation window or measurement timestamp; finality marking | Required |
| Observation | Clock basis and relative clock-error information | Conditional: age-bounded consumption |
| Observation | Expected, observed, missing and censored counts | Conditional: ratio and cohort statistics |
| Observation | Binding generation or effective interval | Conditional: reusable identifiers |
| Observation | Lineage references | Conditional: deduplication or audit needed |
| Policy | Accepted definition and revisions; comparison dimensions; completeness and finality requirements; age, clock-error and window bounds; fallback | Required for consumers |
The following conventions form one proposed core profile. Existing measurements that use other definitions retain those definitions and can be described, but are not silently relabelled as these KPIs. All interval populations below use half-open intervals [start, end). Two distinct non-value conditions apply. A no-observations state is used when the eligible population is empty, as with a request cohort of N=0; an empty population is a valid measurement outcome. A zero or unknown basis quantity that is not a population count, such as capacity in a headroom calculation or eligible duration in a time-availability calculation, instead produces an invalid or unavailable state, because the KPI is not well defined for that basis. Each family also uses the common descriptor and observation fields.¶
A request-latency descriptor identifies the start and completion events and the instrumentation boundaries. An ingress-to-response value includes the components between those events; an internal service-time value is a different metric. A packet-delay metric references its appropriate measurement definition, including treatment of loss and clock error. It is not substituted for request latency.¶
For the illustrative request profile, the cohort consists of logical requests whose start event lies in the window. A declared timeout and late-data policy determine when the cohort can be finalized. Successful completed requests supply latency samples. Timed-out or otherwise failed requests are counted separately and remain visible through success/error KPIs; dropping them does not establish a latency SLO for all requests. The consumer can require both a latency bound and a success bound.¶
For n > 0 sorted successful latency samples x(1) through x(n), the exact nearest-rank q-quantile is x(ceil(q*n)), for 0 < q <= 1. This is one explicit estimator, not a requirement to replace other established estimators. A mean uses sum(x)/n. Approximate sketches identify their algorithm, configuration, and error model. Neither means nor individual percentile scalars can be converted into another percentile. Combining quantiles requires sufficient underlying distribution information and compatible merge rules; averaging site p95 values does not produce a pooled p95.¶
For a finalized request-start cohort, let N be the number of eligible logical requests and S the number with a successful terminal outcome within the declared timeout. The success ratio is S/N. Retries belong to their original logical request; the start event and timeout are not restarted merely because an attempt is retried. A per-attempt ratio is a separate definition. Cancellation rules are fixed by the descriptor before classification.¶
Before the cohort matures, pending outcomes make it provisional. Telemetry loss makes it incomplete even after the timeout: absence of a report does not prove a request timed out. If a trusted source observes a timeout, that is a classified failure; if the source loses the outcome, it is unknown. A final, complete cohort satisfies S+F=N, where F counts unsuccessful terminal outcomes. A consumer requiring this ratio rejects incomplete cohorts unless its policy explicitly defines conservative bounds.¶
Request success is not time availability. A time-availability descriptor instead defines the service-up predicate, the eligible duration, exclusions, and treatment of unknown intervals. For a fully observed interval, availability is known-up duration divided by eligible duration. With eligible duration T, known-up duration U, and unknown duration X, only the interval [U/T, (U+X)/T] is justified without another model. Probe-success fraction is a third metric and does not directly establish time availability between probes.¶
The error ratio of a complete request cohort is F/N only when every non-successful terminal outcome is classified as an error under the declared taxonomy. If cancellations or other neutral outcomes form a third class, its count and denominator rule are explicit, and error ratio is not assumed to equal 1-success ratio. A category-specific ratio declares whether its denominator is all eligible requests or only failures. Taxonomy revision is part of the definition revision; overlapping categories are not summed as if disjoint.¶
For a resource whose used and usable capacity quantities are commensurate, instantaneous headroom is H=(C-U)/C with C > 0, where C is capacity available under a stated allocation policy and U is consumption on that same basis and scope. Both quantities use the same measurement instant or a declared alignment tolerance. Negative H can indicate oversubscription and is not silently clamped. Zero or unknown C produces an invalid or unavailable state, not a division by zero.¶
Link bandwidth, memory allocation, and CPU time have different capacity semantics. An observation identifies the resource class, reservation basis, and relevant averaging interval. For sampled utilization over a window, a profile can report mean instantaneous headroom or headroom from mean quantities, but it names the selected method because they differ when C changes. A resource vector is retained as separate KPIs unless a documented mapping defines a composite score. A headroom percentage across heterogeneous processors does not by itself imply equal additional service capacity.¶
A churn count is the number of distinct qualifying committed transitions in the window for the stated entity set. The descriptor defines the transition, commit timestamp, event identity, producer epoch, and treatment of rollback and replacement. Duplicate notifications of one transition count once; command requests that were never committed are not transitions. Missing event coverage makes the count incomplete.¶
An event rate divides the count by the observed window duration. An entity-normalized rate instead divides by entity exposure, the integral of the number of eligible entities over time, and reports units such as transitions per instance-hour. These rates are not interchangeable. A migration count does not quantify service disruption; a disruption-duration KPI needs its own start/stop predicates and unknown-interval treatment.¶
A consumer evaluates an observation at decision time t_d under a named policy. The following order is useful for diagnostics; failures may be reported together. Eligibility is permission to consider the evidence, not a directive to actuate.¶
Resolve and validate: obtain the exact descriptor revision, check record structure and quantity ranges, understand interpretation-affecting extensions, authenticate its source as required by policy, and reject conflicting records with the same identity/revision.¶
Bind and compare: validate entity naming authority and generation; match measurement boundaries, cohort, statistic, method and units to the intended policy. Apply only declared meaning-preserving transformations. Do not invent defaults for absent semantics.¶
Check finality and quality: check maturation, missing/censored data, count invariants, observation coverage and estimator uncertainty. A larger sample count is not proof of unbiased sampling. Distinguish incomplete measurement from poor service performance.¶
Check time: test freshness using the measurement reference, verify acceptable window width and alignment, and reject timestamps whose clock uncertainty cannot meet policy. Recollection and replay do not change observation time.¶
Record disposition: accept as eligible, or retain specific reasons such as unknown-definition, incompatible-semantics, invalid-binding, insufficient-data, provisional, stale, or clock-uncertain. The controller applies its separately configured fallback and action safeguards.¶
For an interval statistic, let t_e be its observation-window end. Let epsilon bound the absolute error of t_d-t_e, including the relevant producer and consumer clock uncertainties. This is a bound on the difference, not just one clock's advertised accuracy. If t_e > t_d+epsilon, the record has an inconsistent future timestamp. Otherwise, a conservative end-age bound is A_end=max(0,t_d-t_e+epsilon). The observation satisfies an end-age limit F_end only when A_end <= F_end. An unknown epsilon cannot satisfy a policy that requires a finite guaranteed age bound. The epsilon in a policy is an assumption to be justified, not a setting that creates accuracy: a deployment supports it with clock-synchronization evidence, such as the synchronization mechanism in use, monitored offset bounds, and holdover behavior after synchronization loss. If the monitored bound exceeds the declared epsilon, the declared value is not valid, and configurations that were eligible under it can become unsatisfiable.¶
A short end-age does not make a long window representative of current conditions. The policy also bounds window width W=t_e-t_s and, where the oldest contributing evidence matters, tests A_start=max(0,t_d-t_s+epsilon) against an oldest-evidence limit. For an instantaneous measurement, its measurement timestamp replaces t_e. A policy using the last actual sample time can add that test explicitly. Sparse or incomplete sampling is still handled by the quality check.¶
Generation time can occur after window end, especially while request cohorts mature. The maturation delay consumes the freshness budget; a configuration that cannot both finalize and meet its age limit is unsuitable for that control timescale. Generation or collection timestamps cannot replace the observation reference merely to make the data appear fresher. For differences between timestamps on one producer clock, clock-rate error and discontinuities also need treatment; negative or implausible durations are invalid.¶
Ratios are combined by summing compatible numerators and denominators over disjoint populations, not by averaging unweighted ratios. Means require sums and sample counts. Deduplication precedes aggregation. Overlapping windows, shared logical requests, inconsistent time alignment, and cumulative counters with unhandled reset epochs prevent direct aggregation. Numeric unit conversion is allowed only between the same quantity kind with a known scale and precision impact.¶
A corrected observation retains its observation identity, advances its revision, and explicitly supersedes the previous value. Its measurement window remains tied to the data actually measured. Late arrivals, retries, and corrections are not new independent observations. A consumer rejects inconsistent same-revision payloads and records which revision supported each decision. Corrections can change historical evaluations but cannot retroactively prove that an earlier control action was justified by evidence then available.¶
Suppose site A reports ingress request-latency p95 of 18 ms over a 60-second request-start cohort and site B reports a five-minute internal-processing mean of 12 ms. The smaller number does not justify steering to B. Measurement boundaries, statistic, and window fail the comparison policy. Re-exporting B in seconds or renaming its metric does not repair these mismatches.¶
For two disjoint, complete and otherwise compatible request cohorts, A has 90 successes out of 100 requests and B has 990 successes out of 1000. Pooled success is (90+990)/(100+1000)=1080/1100, approximately 0.981818. The unweighted mean of the two ratios is 0.945 and is a different quantity. Pooling also requires a policy that permits the combined population; it is not automatically appropriate for comparing sites.¶
For samples [1,2,3,4,5,6,7,8,9,10] ms, nearest-rank p95 is the tenth value, 10 ms. A mean-only record containing 5.5 ms cannot supply that quantile. If a cohort contains 90 successful first attempts and 10 requests that each succeed on their second attempt, logical-request success is 100/100; per-attempt success is 100/110. The two definitions remain different even though both express a fraction.¶
The JSON below illustrates the information carried by the profile with an inline descriptor and policy. It is not a standardized schema, a protocol binding, or RFC 7951 YANG JSON encoding [RFC7951]. Names and example URIs have local illustrative meaning. Counts summarize a trusted ingress cohort enumerator; they are not inferred from collected successes. There is no claim of independent verification of the producer.¶
{
"descriptor": {
"id": "https://example.org/kpi/request-success",
"revision": "1",
"quantity": "logical-request-success",
"unit": "1",
"statistic": "ratio",
"scope-role": "service-at-site",
"measurement": {
"method": "passive",
"point": "ingress-proxy",
"start": "first-request-accept",
"end": "terminal-response-or-timeout"
},
"population": {
"filter": "accepted-requests:class-interactive",
"cohort": "logical-request-start",
"retry": "one-logical-request",
"timeout-ms": 1000,
"success": "HTTP-200-to-299-within-timeout",
"cancellation": "unsuccessful-terminal-outcome",
"exclusions": "none"
},
"window": {
"kind": "tumbling",
"width-ms": 1000,
"alignment": "UTC-seconds",
"endpoints": "[start,end)"
},
"sampling": "all-eligible-requests",
"report-period-ms": 1000,
"finalization": "timeout-plus-500ms-late-data-allowance",
"aggregation": "sum-counts-only-for-disjoint-compatible-cohorts",
"extensions": []
},
"observation": {
"definition-revision": "1",
"producer": "example.org/ingress-7",
"producer-epoch": "boot-12",
"id": "cohort-20261006T120000Z",
"revision": 1,
"scope": {
"authority": "example.org",
"service": "svc-7",
"site": "edge-a",
"instance": "ingress-7",
"generation": "12"
},
"window-start": "2026-10-06T12:00:00Z",
"window-end": "2026-10-06T12:00:01Z",
"generated-at": "2026-10-06T12:00:02.500Z",
"collected-at": "2026-10-06T12:00:02.600Z",
"clock-basis": "UTC",
"state": "valid",
"final": true,
"value": 0.99,
"numerator": 990,
"denominator": 1000,
"failure-count": 10,
"unknown-count": 0,
"quality": {
"coverage": "complete",
"expected-count": 1000,
"observed-count": 1000,
"censored-count": 0
},
"lineage": "example.org/ingress-7/boot-12/cohort-120000"
},
"policy": {
"id": "example.org/policy/steering-1",
"revision": "1",
"accepted-definition": "https://example.org/kpi/request-success",
"accepted-definition-revision": "1",
"comparison-dimensions": [
"site",
"instance"
],
"required-service": "example.org/svc-7",
"allowed-normalization": "none",
"require-final": true,
"require-complete": true,
"minimum-count": 100,
"max-window-ms": 1000,
"max-end-age-ms": 2000,
"max-oldest-evidence-age-ms": 3000,
"decision-time": "2026-10-06T12:00:02.700Z",
"relative-clock-error-bound-ms": 20,
"fallback": "retain-policy-approved-current-configuration"
}
}¶
At 12:00:02.700Z, the conservative end age is 1720 ms and the oldest-evidence age is 2720 ms. Both satisfy the displayed policy, as does the one-second window. The cohort is mature and complete. Assuming successful authentication, binding and descriptor checks, the observation is eligible. At 12:00:03.100Z, end age is 2120 ms and exceeds the policy limit. Replaying the record with a newer collection time does not change this result.¶
No traffic: N=0 and S=0. Expected outcome: no-observations, not 100% or 0% success.¶
Incomplete cohort: N=1000, S=980, known failures=10 and unknown outcomes=10. Under a complete-only policy, reject as insufficient-data. If bounds are explicitly allowed, success lies in [0.98,0.99]; 980/990 changes the denominator and is not the same metric.¶
Fresh replay of old data: measurement end is ten minutes before the decision, collection age is 10 ms, and maximum end age is 2 seconds. Expected outcome: stale.¶
Future timestamp: measurement end is 100 ms after the decision and the relative clock-error bound is 20 ms. Expected outcome: clock inconsistency.¶
Availability: over 60 eligible seconds, known-up duration is 54 seconds and unknown duration is 3 seconds. Expected range: [0.90,0.95], not a declared exact availability of 0.95.¶
Resource capacity: C=100 and U=110 on the same basis. Expected headroom: -0.10. With C=0, the value is invalid.¶
Churn: four unique transitions over exposure of ten instance-minutes give 24 transitions per instance-hour. A duplicate notification does not increase the count.¶
Semantic mismatch: two records share a metric label but have logical-request and per-attempt denominators. Expected outcome: incompatible-semantics.¶
Correction: a later revision of the same cohort replaces the earlier record. Expected outcome: recompute using one revision, never add both denominators.¶
Binding reuse: a record for generation 11 arrives after the target instance becomes generation 12. Expected outcome: invalid-binding for a current-instance decision unless policy explicitly requests historical data.¶
An initial deployment can maintain the descriptor in a versioned configuration store, keep observations in its existing telemetry pipeline, and apply eligibility checks at the consumer. Descriptor references and bindings need to survive forwarding, storage, replay, and aggregation. A gateway documents each mapping from native counters to the proposed KPI; transport encryption does not validate that mapping.¶
No production deployment, interoperability trial, or measured improvement is asserted in this revision. The examples are reproducible arithmetic and decision cases. Evaluation should compare independently generated records and independent consumers, deliberately varying window alignment, clock offsets, descriptor revisions, missing outcomes, population overlap, and reset epochs. Useful results include agreement on disposition and rejection reason, errors against an independently specified measurement oracle, record overhead, and processing cost. Agreement between two consumers alone is not evidence that both interpret the underlying metric correctly.¶
Open questions include which KPI families operators need first, whether this material should be consolidated with existing NMOP work, the minimal mapping to existing metadata mechanisms, and how compactly to carry estimator and completeness evidence. Any future YANG binding or registration needs separate specification and review.¶
Passing the profile checks does not guarantee controller stability, representative sampling, causal attribution, or future service performance. Controllers still need suitable actuation limits, hysteresis or dwell times where appropriate, rollback behavior, and protection against decisions made on mutually inconsistent observations. Invalid telemetry is a measurement condition, not proof of service failure. A fallback is explicit and task-specific; retaining an existing configuration is not universally safe.¶
Cross-domain exports can use scoped pseudonyms and aggregate counts where raw request identifiers would disclose personal or commercial information. Exported context still needs to preserve the distinctions required for interpretation. A field withheld for confidentiality is unavailable, not implicitly equivalent to another domain's value. Minimize retained provenance to what is necessary for the operational and audit purpose, under the deployment's retention policy.¶
A forged descriptor or observation can cause traffic steering, scale-out, or placement to be based on false evidence. Deployments need integrity protection and authentication for both data and referenced definitions, authorization for policy changes, and an appropriate trust model for producers. A cryptographically authentic producer can still be faulty or dishonest; reconciliation with independent evidence may be needed for consequential actions.¶
Replay protection combines observation identity, producer epoch, revision handling and measurement-time checks. Repeated delivery does not refresh a measurement. Clock manipulation can bypass naive age checks; consumers need bounded uncertainty and a defined behavior when synchronization is lost. A semantic revision that alters a denominator or unit is not accepted merely because it uses the same display name.¶
Untrusted descriptor references can trigger server-side request forgery or resource exhaustion. Consumers should restrict resolvable schemes and destinations, bound document size, nesting and cache growth, and avoid arbitrary fetching during time-critical decisions. Records can also reveal topology, capacity, demand and tenant relationships; confidentiality, scoped authorization and minimization apply to metadata as well as values. Logging rejection reasons should not expose credentials or sensitive payloads.¶
This document has no IANA actions. The example identifiers do not establish a registry, namespace allocation, or assigned code points.¶
This checklist concerns the proposed profile only. It is not an IETF certification scheme. For each deployment, record a pass, failure, or explicit non-applicability with justification:¶
Can the exact definition revision be resolved, with units, statistic, estimator, measurement boundaries, population and timeout/retry rules?¶
Are domain, service, site and instance bindings unambiguous for the observation interval, including identifier reuse and producer restarts?¶
Are the actual measurement interval, time basis, cadence and finalization rules available, without substituting collection time for measurement time?¶
Are zero denominators, unknown outcomes, missing samples, censored values and provisional cohorts represented distinctly?¶
Do ratios retain their numerator/denominator and do merges avoid overlap, duplicates, counter resets and averaging of percentile scalars?¶
Are clock uncertainty, maximum age, window width, coverage, and method tolerances checked against an explicit policy?¶
Are corrections processed as replacement revisions, with the decision's actual inputs retained?¶
Are interpretation-affecting extensions understood, and descriptor resolution and data provenance protected?¶
Do the worked cases produce the documented arithmetic and rejection reasons, with independent measurement validation where accuracy is claimed?¶
Is fallback behavior defined separately from eligibility, and are limitations and privacy controls documented?¶
Preparation of this contribution was supported by a fellowship of the StandICT.eu 2029 project, Open Call 2, activity 2029-02-1710, "Telemetry and KPI semantics for closed-loop edge-cloud orchestration". StandICT.eu 2029 has received funding from the European Union’s Horizon Europe programme under Grant Agreement No. 101213612.¶