China Mobile

Beijing China lizhiqiangyjy@chinamobile.com

China Mobile

Beijing China duzongpeng@chinamobile.com

Centec

Shanghai China wangjj@centec.com

Centec

Shanghai China chengw@centec.com

Centec

Shanghai China zhaoying@centec.com

SAIA

Shanghai China chunhao.zhao@sh-aia.com

Inesa

Shanghai China sunxun@inesa.com

RTG Computing-Aware Traffic Steering CATSYANGcontext-staging latencyobservation boundaryC-SMAdeterministic CBORNMDA This document specifies a Standards Track YANG 1.1 data model (ietf-cats-context-staging-metrics) and an on-demand deterministic CBOR query envelope for Computing-Aware Traffic Steering (CATS) service context-staging latency metrics. The specification defines three explicit observation-endpoint boundaries (transport-submit, remote-placement, and consumer-usable), enforces four-tuple snapshot view consistency (producer-id, boot-id, view-id, snapshot-id) with clock-uncertainty bounds, prohibits direct arithmetic addition of marginal latency quantiles across stages, and provides a point-to-point C-SMA to C-PS residency lookup envelope that avoids underlay routing protocol flooding.

Introduction A retrieval estimate can mean a transport submission interval, a lookup-to-placement interval, or a lookup-to-consumer-usability interval. Adding such values to an existing delay metric without their boundaries can count the same time twice. Even with identical units, a mean, a quantile, and an instantaneous prediction are not interchangeable. The Computing-Aware Traffic Steering (CATS) framework establishes the architecture for steering traffic across distributed service sites using computing and network metrics. The CATS use cases and requirements and metric definition baseline identify that stateful service instances frequently require external context staging prior to request execution. Within a controlled administrative domain , this document specifies a Standards Track YANG 1.1 data model and on-demand C-SMA residency query envelopes for CATS service context-staging metrics. The augmentation attaches to the service-metric list of , identified by cs-id, csci-id, and source-type. It imports the routing tree defined by . It does not add a replacement service identity, modify a base metric value, define a normalized score, or select a forwarding path. The source-type key retains the meaning assigned by the base model; no dynamically learned source is to be mislabeled static. The scope is operator-controlled metric exchange within one administrative reporting domain. A management application may consume the data using existing protocols; this document does not define a public application API or an inter-domain context directory. is related management work, not a dependency on a new northbound protocol. This augmentation is specified against version 00 of ; its path and imports will need review if that work changes before publication. The generic units, statistics, observation time, and validity concepts in and the freshness and unknown-value rules in Section 11.3 of already address part of this problem. This module does not redefine their metric registry or wire encoding. Its additional endpoint, component, and clock-bound semantics are operational metadata. In particular, quantile and model-estimate MUST NOT be silently encoded as an existing Statistics enumeration with a different meaning. Mapping these observations into a registered CATS metric requires the applicable metric definition; no such registry assignment is requested here.

Conventions and Scope Identifiers 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. The data model uses YANG 1.1 and the Network Management Datastore Architecture (NMDA) . Tree diagrams use . JSON examples follow ; in particular, uint64, int64, and decimal64 values are JSON strings. A producer is a management server exposing the operational data. A consumer is a management client interpreting it. An authorized reporting domain is a set of producers and consumers that share authenticated definitions of identifiers. Identifiers do not confer access rights. A state-class definition MUST identify the model and relevant revision, representation, and state coverage, including required auxiliary state. A workload or population definition MUST identify the inclusion, sampling, and load conditions. A method or boundary definition MUST identify the measured events, estimator, units, and relevant version. These definitions MAY be provisioned outside this module over authenticated management channels. A consumer MUST NOT infer equivalence from an unrecognized identifier or compare data whose required definitions are unavailable. This version does not specify a cross-domain identifier registry.

Retrieval Estimate Semantics

Observation Boundaries and Availability An estimate MUST identify one source scope, destination scope, state class, workload class, and method. All samples of a measured estimate MUST use those definitions and the advertised start and end events. lookup-start precedes lookup work; transfer-submit precedes submission of the first transfer operation. remote-placement means all transfer bytes required by the state class have been placed at the destination. consumer-usable additionally requires all required state, representation processing, and visibility conditions for the identified consumer. A producer MUST NOT infer consumer-usable solely from a local completion event. The method definition MUST identify how the terminal condition is observed or predicted. A prediction of a consumer-usable interval is an estimate of that event; it does not prove that any future transfer will reach it. If an implementation cannot express its endpoint using these definitions, it MUST NOT substitute the nearest enum silently. status describes availability of the metric. An available estimate MUST carry latency-us. An unavailable estimate MUST NOT carry latency-us. Context-tier absence, capacity exhaustion, and authorization failure do not imply zero latency and do not become infinite integer values. This model deliberately does not signal whether a particular object can presently be retrieved. Consumers requiring that fact need the applicable state or service protocol. Zero is a valid numeric estimate only when supported by the method. A missing uncertainty is unknown, not zero. A measured mean or quantile with available status MUST have a positive sample-count. A model-estimate MAY have sample-count zero. For unavailable metrics sample-count MAY be zero. Percentile MUST be present for a quantile and MUST NOT be present for other statistics.

Freshness and Clock Bounds observed-at is the UTC instant to which the estimate applies, not the time a client retrieves the management response. measurement-window-us identifies the preceding aggregation interval; zero identifies an instantaneous prediction. A producer MUST NOT extend validity merely by returning the same estimate in a later snapshot. valid-for-us equal to zero is immediately stale. A consumer that relies on bounded UTC timestamps MUST account for both producer and consumer clock uncertainty. Let T be observed-at, Es the producer error bound, N the consumer current time, En the consumer error bound, and V valid-for-us, expressed in a common exact time scale and microseconds. The following sufficient conditions establish freshness throughout the uncertainty intervals: N - En >= T + Es (N + En) - (T - Es) < V If either bound is unknown, or if either condition fails, freshness is not established by this rule. A consumer MUST NOT label the estimate fresh in that case. It MAY omit this estimate, request a refresh, or use a separately identified policy for stale or unverified information. It MUST keep that policy distinct from use of a fresh estimate. These conditions are deliberately conservative and can reject a recently generated estimate whose clock intervals overlap. Clock bounds MUST cover timestamp generation error and relevant synchronization uncertainty. Leap-second handling and conversion of UTC to the arithmetic time scale MUST be defined by the clock method. If conversion is ambiguous, a consumer MUST treat freshness as unverified. Validity is an estimator policy, not a guarantee of context residency, service admission, or constant future latency.

Cost Components and Composition A component-id identifies a particular included cost contribution, not a generic kind of work. The same component identifier within an authenticated reporting domain and boot denotes the same contribution when estimates are compared. Producers MUST preserve that equivalence when they set components-complete to true. Identical kind values alone do not prove duplicate cost. components-complete true asserts that every included contribution is represented in the component list. Comparable estimates MUST use the same granularity and identifier for a shared contribution; overlapping bundles with different identifiers do not satisfy this assertion. If that common decomposition cannot be established, the producer MUST set components-complete false. Completeness does not assert independence, temporal disjointness, or serial execution. components-complete false prohibits additive composition based on this representation. A consumer MUST NOT add estimates whose component sets intersect. Because this model has no per-component numeric values, a consumer MUST NOT subtract an assumed overlap from such estimates. It MUST select a directly measured composite estimate or use another explicitly justified model. A consumer MUST NOT add quantiles to claim the same quantile of a total interval. It MUST NOT sum overlapping elapsed intervals as if they were serial. Arithmetic means can be added without an independence assumption only when the underlying random variables actually represent the serial decomposition being estimated, their populations and units are compatible, and no contribution is duplicated. Summing model-estimates requires an equally explicit composition method. A list of disjoint identifiers alone is insufficient evidence. An existing CATS network metric may already be covered by the retrieval interval. The consumer MUST establish whether it is included before adding it. For example, a lookup-to-usable mean of 1200 microseconds including a transfer contribution must not be augmented by the same 400-microsecond transfer delay to produce 1600. If a reliable decomposition is absent, the consumer can use the end-to-end estimate directly. This specification does not standardize its conversion into a policy score or the decision to prefer a site.

Management Access, Retention, and Conformance The ietf-cats-context-staging-metrics module contains only operational state (config false). Its presence container denotes supported exposure; absence is not a zero metric. A server implementing this module MUST advertise the implemented revision using YANG Library . It MUST expose the model consistently with NMDA. No feature flags, RPCs, actions, or notifications are defined. This specification defines data semantics independent of the selected YANG management protocol. NETCONF and RESTCONF are applicable existing transports. It does not assign a new URI scheme, HTTP resource outside the existing datastore mapping, port, or packet format. Protocol errors use the selected management protocol; no new error tags are defined. A complete retrieval of context-staging-metrics MUST describe one coherent snapshot. The producer MUST change snapshot-id when any exposed content changes and MUST change boot-id when continuity of identifiers or counters is lost. It MUST NOT reuse a snapshot-id within a boot. A consumer combining separate reads MUST verify both identifiers are equal; otherwise it MUST obtain a new complete snapshot or mark the combination unusable. Identical identifiers from different authenticated servers are not equal snapshots. The producer MUST enforce the advertised retention limit and the schema maxima. A complete response MUST NOT contain dangling references. If authorization filtering or an incomplete response prevents reference resolution, the consumer MUST NOT treat the response as a complete conforming snapshot. The producer SHOULD expose only the authorized, internally consistent view to each principal. Omitted records MUST NOT be interpreted as successful operations or as zero-valued observations. Counters are cumulative within a boot and follow yang:counter64 , including possible wrap. Consumers MUST NOT calculate deltas across a boot change; they MUST detect or explicitly bound counter wrap before calculating a delta. Limits bound retained records, not the full history or network load. Servers MAY choose a smaller limit, provided they report it accurately. All arithmetic requirements in this document use exact integer quantities before division. Implementations MUST detect overflow and MUST NOT wrap, saturate silently, or turn an invalid result into zero. Schema validation does not replace semantic validation: XPath number conversion can lose precision for large 64-bit integers. Producers MUST satisfy, and consumers MUST verify before use, the additional constraints defined in this document. A consumer detecting a violation MUST exclude the affected record from the relevant calculation and SHOULD report the reason through its existing diagnostic interface; it need not discard unrelated valid records. Snapshot identity is the tuple (authenticated producer, boot-id, view-id, snapshot-id). view-id identifies one authorized projection and MUST change when its authorization scope, filtering policy, or interpretation definitions change. A consumer MUST NOT join responses or calculate deltas across different views. If a coherent complete view cannot be returned, the server MUST report failure using the management protocol. A filtered response alone does not establish completeness.

Additional Conformance Requirements

• The number of retained estimate entries MUST NOT exceed estimate-limit. discarded-estimates counts estimates omitted or removed due to retention, not staging misses or failed service requests. It MUST increase for each retention-driven omission according to the counter semantics.
• When definitions, boundaries, or measurement populations change, the producer MUST use identifiers that prevent consumers from silently merging incompatible records. A valid identifier is not a substitute for a documented definition.
• A consumer MUST keep unavailable, stale, and incomparable states distinct from available estimates. It MAY continue ordinary service selection using other metrics according to local policy.
• Implementations claiming conformance MUST satisfy the module and these interpretation rules. Estimator accuracy thresholds and service-selection policies remain deployment-specific.

Data Model Overview The following tree shows the nodes defined by this module. The module text is normative. Read-only nodes are marked ro; a presence container is marked with an exclamation mark. module: ietf-cats-context-staging-metrics augment /rt:routing/cats:cats/cats:service-metrics /cats:service-metric: +--ro context-staging-metrics! +--ro view-id local-id +--ro snapshot-id local-id +--ro boot-id local-id +--ro estimate-limit uint16 +--ro discarded-estimates yang:counter64 +--ro estimate* [estimate-id] +--ro estimate-id local-id +--ro source-scope local-id +--ro destination-scope local-id +--ro state-class local-id +--ro workload-class local-id +--ro method-id local-id +--ro observed-at yang:date-and-time +--ro valid-for-us uint64 +--ro measurement-window-us uint64 +--ro sample-count uint64 +--ro statistic enumeration +--ro status enumeration +--ro start-boundary enumeration +--ro end-boundary enumeration +--ro components-complete boolean +--ro clock-uncertainty-us? uint64 +--ro latency-us uint64 +--ro percentile decimal64 +--ro component* [component-id] +--ro component-id local-id +--ro kind enumeration

YANG Module This module imports common data types from . RFC XXXX in the module and registration templates is to be replaced by the RFC number assigned to this document; it is not an allocated number. module ietf-cats-context-staging-metrics { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-cats-context-staging-metrics"; prefix ccr; import ietf-yang-types { prefix yang; reference "RFC 9911: Common YANG Data Types"; } import ietf-routing { prefix rt; reference "RFC 8349: A YANG Data Model for Routing Management"; } import ietf-cats { prefix cats; reference "I-D.ietf-cats-data-model: CATS Data Model"; } organization "IETF Computing-Aware Traffic Steering (CATS) Working Group"; contact "Discussion: IETF CATS and OPSAWG mailing lists Web: https://datatracker.ietf.org/group/cats/ Web: https://datatracker.ietf.org/group/opsawg/ Author: Zhiqiang Li <lizhiqiangyjy@chinamobile.com> Author: Junjie Wang <wangjj@centec.com>"; description "A YANG Data Model for Computing-Aware Traffic Steering (CATS) Service Context-Staging Latency Metrics. 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; see the RFC itself for full legal notices."; revision 2026-10-30 { description "Initial revision."; reference "RFC XXXX: A YANG Data Model for Computing-Aware Traffic Steering (CATS) Service Context-Staging Latency Metrics"; } typedef local-id { type string { length "1..128"; } description "Opaque identifier scoped to one authorized reporting domain. It is not a global content hash or an access credential."; } augment "/rt:routing/cats:cats/cats:service-metrics/" + "cats:service-metric" { description "Operational context-staging latency observations for an existing CATS service metric entry. No forwarding metric is changed."; container context-staging-metrics { presence "Service context-staging latency observations are exposed."; config false; description "One coherent snapshot of bounded retrieval estimates. Snapshot identifiers change whenever any content changes."; leaf view-id { type local-id; mandatory true; description "Authorized projection identity; changes when scope or interpretation definitions change."; } leaf snapshot-id { type local-id; mandatory true; description "Identifier of the immutable snapshot within this server boot."; } leaf boot-id { type local-id; mandatory true; description "Changes after restart or loss of snapshot identifier state."; } leaf estimate-limit { type uint16 { range "1..256"; } mandatory true; description "Maximum number of estimates retained by this server."; } leaf discarded-estimates { type yang:counter64; mandatory true; description "Estimates not retained since this boot; not requests or failed lookups."; } list estimate { must "status = 'unavailable' or " + "statistic = 'model-estimate' or sample-count > 0" { error-message "Sample statistics require observations."; description "A measured statistic has a nonempty population."; } key "estimate-id"; max-elements 256; description "A raw latency estimate for a declared state and workload scope. Its presence does not reserve staged context."; leaf estimate-id { type local-id; mandatory true; description "Identifier unique within this snapshot."; } leaf source-scope { type local-id; mandatory true; description "State source tier or source instance in the reporting domain."; } leaf destination-scope { type local-id; mandatory true; description "Consumer placement to which the estimate applies."; } leaf state-class { type local-id; mandatory true; description "Shared definition of model, representation and state coverage."; } leaf workload-class { type local-id; mandatory true; description "Shared definition of request population and load conditions."; } leaf method-id { type local-id; mandatory true; description "Versioned estimator or measurement procedure identifier."; } leaf observed-at { type yang:date-and-time; mandatory true; description "UTC instant to which this estimate applies."; } leaf valid-for-us { type uint64; units "microseconds"; mandatory true; description "Validity duration from observed-at; zero is immediately stale."; } leaf measurement-window-us { type uint64; units "microseconds"; mandatory true; description "Aggregation interval ending at observed-at; zero means an instantaneous estimate."; } leaf sample-count { type uint64; mandatory true; description "Number of observations supporting the value; zero for a model estimate without samples."; } leaf statistic { type enumeration { enum mean { description "Arithmetic mean for the declared population."; } enum quantile { description "Quantile using the identified estimator."; } enum model-estimate { description "Prediction rather than a sample statistic."; } } mandatory true; description "Meaning of the latency value."; } leaf status { type enumeration { enum available { description "A latency estimate is available."; } enum unavailable { description "No usable value is provided."; } } mandatory true; description "Availability of the metric, not availability of the state."; } leaf start-boundary { type enumeration { enum lookup-start { description "Before lookup for the specified state starts."; } enum transfer-submit { description "Immediately before submitting the first transfer operation."; } } mandatory true; description "Event at which the estimated elapsed time begins."; } leaf end-boundary { type enumeration { enum remote-placement { description "All required transfer bytes placed at the destination."; } enum consumer-usable { description "All required state is usable by the named consumer."; } } mandatory true; description "Event at which the estimated elapsed time ends."; } leaf components-complete { type boolean; mandatory true; description "True only if all included component instances are listed. False prohibits additive composition."; } leaf clock-uncertainty-us { type uint64; units "microseconds"; description "Bound on error of observed-at relative to UTC; absence means unknown."; } leaf latency-us { when "../status = 'available'"; type uint64; units "microseconds"; mandatory true; description "Elapsed latency estimate. Zero is a measured or estimated zero, never a missing value."; } leaf percentile { when "../statistic = 'quantile'"; type decimal64 { fraction-digits 2; range "0..100"; } mandatory true; description "Requested percentile, including the estimator identified by method-id."; } list component { key "component-id"; max-elements 32; description "Included component instances. The same component-id denotes the same cost contribution across estimates within this boot and authorized reporting domain."; leaf component-id { type local-id; mandatory true; description "Stable identity of a particular cost contribution."; } leaf kind { type enumeration { enum lookup { description "Lookup activity."; } enum queueing { description "Queueing activity."; } enum registration { description "Registration activity."; } enum transfer { description "Transfer activity."; } enum conversion { description "Conversion activity."; } enum visibility { description "Visibility activity."; } enum other { description "Other activity."; } } mandatory true; description "Descriptive class, not a deduplication key."; } } } } } } <CODE ENDS>

Deployment and Instrumentation Boundaries The target deployment is a Computing-Aware Traffic Steering (CATS) domain within a single administrative boundary . Source and destination scopes identify a CATS Service Contact Instance (CSCI) or an associated state-storage tier under an authenticated operator policy. A remote-placement sample and a consumer-usable sample represent distinct readiness milestones, even when both are exported in microseconds. A CATS Service Metric Agent (C-SMA) instrumentation adapter collects native state-staging and runtime readiness timestamps from local service instances and storage tiers. A transport-level completion event alone does not establish execution-context usability at the target CSCI. Where runtime readiness instrumentation is unavailable, the exporter MUST report the consumer-usable metric as unavailable rather than extrapolating it from raw byte counts. This YANG module neither reserves compute or storage capacity nor floods fine-grained session residency into underlay routing protocols (IGP or BGP). Probabilistic membership filters MUST NOT be flooded in routing protocols to estimate lower bounds on reusable context units. Fine-grained candidate residency checks use the point-to-point C-SMA to C-PS deterministic CBOR query envelope specified in .

Delay Composition Guard and L0-L2 Metric Separation When composing quantities as elapsed time, a consumer MUST establish that the contributions form the claimed interval without overlap or duplicated work. A retrieval-start to consumer-usable interval that already includes a transfer MUST NOT have that transfer or the same network delay added again. Different component names or identifiers do not establish temporal disjointness. If coverage cannot be established, the consumer MUST NOT claim an additive latency result; it MAY use a directly observed composite interval or a separately justified model. A consumer MUST NOT add component quantiles and label the result as the same quantile of the total. To obtain an observed total quantile, it can compute totals from matched per-request observations and then apply the declared quantile estimator. Adding arithmetic means requires the same target population and a justified per-request serial decomposition with each contribution counted once; statistical independence is not required for that addition. Overlapping work needs an explicit overlap-aware model. A policy-weighted or normalized score MAY combine inputs for ranking, but MUST NOT be represented as an observed duration or percentile solely because its inputs have those meanings.

On-Demand CBOR State-Residency Lookup Envelope for C-SMA to C-PS Exchange To prevent high-churn per-prefix state residency identifiers from flooding the CATS control plane while enabling exact candidate verification between a CATS Service Metric Agent (C-SMA) and a CATS Path Selector (C-PS), implementations MAY exchange deterministic CBOR lookup queries and results conforming to Section 4.2.1 of [RFC8949] and defined in CDDL [RFC8610] below.

Wire Representation Both messages use CBOR core deterministic encoding , with shortest integer and length encodings, definite lengths, and ordered integer map keys. Only the types in the CDDL below are allowed. Tags, floats, text strings, duplicate keys, unknown keys, trailing bytes, and non-deterministic encodings MUST be rejected. Each message is limited to 32768 octets. id16 = bstr .size 16 digest = bstr .size 32 query-item = [units: 1..4294967295, context: digest] lookup-query = { 0: 1, ; version 1: id16, ; namespace 2: id16, ; query ID 3: digest, ; deployment profile 4: digest, ; import contract 5: [1*128 query-item] } unknown = [0] miss = [1] candidate = [2, descriptor: digest] lookup-result = { 0: 1, 1: id16, ; namespace 2: id16, ; query ID 3: digest, ; SHA-256 of complete encoded query 4: id16, ; serving instance 5: id16, ; incarnation 6: [1*128 (unknown / miss / candidate)] } The query ID MUST be generated from 128 unpredictable bits and MUST NOT intentionally be reused for a new query. Query items MUST be unique as (units, context) pairs. Response position i corresponds to query position i; the two arrays MUST have exactly the same length. A response MUST include the SHA-256 digest of the exact deterministic query bytes, computed as specified in . The digest binds profile, contract, order, and all queried keys, so a result cannot be silently reused for a shorter, reordered, or differently configured query. These identifiers and hashes provide correlation, not authentication. The enclosing RPC must protect both directions against modification and impersonation and authorize namespace access. It MUST delimit one complete CBOR message and identify whether it carries a query or a result. This document defines the representation, not a universal RPC method name or an independently interoperable transport binding.

Server Processing and Result Semantics The server first validates syntax, resource bounds, authenticated namespace authorization, and the supported profile/contract pair. A syntactically invalid or unauthorized request is rejected through the enclosing RPC's error mechanism, without returning a normal result. A well-formed query for an authorized but unsupported profile or contract returns unknown for every item. This behavior avoids misrepresenting an unsupported query as an authoritative miss. For each query item, the server returns exactly one of the following values:

• Unknown (0): the server cannot establish either a complete candidate or an authoritative negative result. Examples include index reconstruction, incomplete publication, partial component coverage, a Bloom-filter positive that has not been verified, or an internal deadline. Unknown MUST NOT be converted into miss for reporting or routing policy.
• Miss (1): at the instant this item was checked, the authoritative index contained no published, locally eligible candidate for the exact namespace, profile, contract, context-unit count, and context key. This is limited to this instance; it is not a global absence statement.
• Candidate (2): at the instant this item was checked, the index associated a published descriptor with the exact query tuple, and the instance's read service tracked every required component as available under that descriptor. The result carries the complete descriptor identity. This does not mean that the recipient has validated the descriptor or acquired read protection.

The server MUST obtain the tuple binding, descriptor ID, publication state, and component-coverage check from one logically consistent index view for each item. A lock, immutable index version, or transaction is sufficient; a mixture of pre- and post-eviction facts is not. Different items MAY be checked at different instants. The result does not claim a snapshot transaction across the whole array. If multiple published descriptors match an item, the server MAY select any candidate satisfying the contract. Version 1 returns one candidate per item and provides no enumeration or ranking semantics. A consumer can perform a later query if the selected object disappears. Advertised candidate IDs MUST be resolvable through the serving instance's authorized read interface; a candidate ID is not a URL or an RDMA remote key. A positive probabilistic lookup is insufficient for candidate. An absence inferred from a probabilistic or event-derived index is insufficient for miss unless that index is proven complete for the instance and cannot produce false negatives under its deletion, saturation, restart, and event-loss behavior. A server can always return unknown and fall back to an exact lookup. This document deliberately does not standardize Bloom parameters, folding, or counting-filter deletion.

Encoding Examples These fixtures exercise encoding only. Their artifact digests refer to test labels, not a production-approved service profile. Hexadecimal lines are concatenated without whitespace.

lookup-query Encoded length: 147 octets. a600010150000102030405060708090a0b0c0d0e0f0250515151515151515151 5151515151515103582072950781c8ae4408fa70d0cf5d9f992406a57f358fe7 971ee5d770127c78d4bb045820bf616ffee52c062d3fbc260143d7a7f77d622e 7f24fc9d4085f8376f058e7336058182035820c8337d9c6ab594881cf8ba1935 276abab7744338df278c1817f527a562869254 SHA-256 of these encoded bytes: 10d6a27f629f4813913e278f8f8c5681f014169bae6ad58c6241e22287d2062d

lookup-result Encoded length: 148 octets. a700010150000102030405060708090a0b0c0d0e0f0250515151515151515151 5151515151515103582010d6a27f629f4813913e278f8f8c5681f014169bae6a d58c6241e22287d2062d04504949494949494949494949494949494905504545 45454545454545454545454545450681820258203216099ee80f56e52066194f e29a4c89851e8d985b4ef2022f6ddab32f73b9ac SHA-256 of these encoded bytes: d05a63c345273e1104e7f01e17ab4722f8c05fbc36a0404a55e74cbc2d0d53a0

Incarnation Continuity and Producer/Consumer Conformance Each authoritative lookup responder (C-SMA directory agent) maintains a 16-octet opaque incarnation-id. An outstanding lookup query is bound to the authenticated responder identity and the incarnation-id captured from the responder's capabilities. If a subsequent authenticated capability refresh advertises a changed incarnation-id, the querying C-PS MUST immediately invalidate all outstanding queries and retained residency hints from the prior incarnation. A delayed reply carrying an older incarnation-id MUST NOT re-establish the superseded incarnation. A lookup result of candidate(2) is a point-in-time observation by one authoritative instance; it is neither a memory reservation nor a guarantee that a subsequent state read will succeed. Furthermore, independent candidate observations from distinct service instances MUST NOT be combined by bitwise OR or set union into a synthetic claim that a single instance holds the complete prefix. A metric producer claiming conformance to this specification MUST export the explicit observation-endpoint identifier (transport-submit, remote-placement, or consumer-usable), the four-tuple snapshot view identifier (producer-id, boot-id, view-id, snapshot-id), and the clock uncertainty bound. A consumer (C-PS) MUST reject metrics with unknown endpoint semantics or stale view generations, and MUST NOT construct a quantile of a sum by adding marginal P95 or P99 quantiles across network and state-preparation stages.

Security Considerations The security analysis for the ietf-cats-context-staging-metrics module follows the approach in . YANG management access requires a secure transport and mutual authentication. Deployments using NETCONF over SSH follow ; RESTCONF uses HTTPS with authentication appropriate to the deployment and current TLS guidance . Peer authentication alone does not authorize a metric or its scope. Access control MUST be enforced using the Network Configuration Access Control Model (NACM) when this module is accessed by NETCONF or RESTCONF. Deployments MUST restrict readable observations to authorized principals in the reporting domain and SHOULD deny them to other principals by default. The module introduces no writable data nodes, RPCs, actions, or notifications. It does not weaken access controls on nodes in imported or augmented modules. The context-staging-metrics subtree exposes source and destination scopes, state classes, workload classes, observation times, component relationships, and latency. These can disclose model placement, context residency patterns, tenant activity, and contention. Pseudonymous identifiers still permit correlation. Servers SHOULD minimize identifying detail, bound retention, and avoid placing user payloads, input sequences, content hashes, credentials, or customer names in identifiers. A forged cheap estimate or replayed old estimate can attract traffic to an unsuitable site. Consumers MUST authenticate the reporting peer and verify freshness and scope before using a value for steering. Freshness does not establish truthfulness or context-tier availability. Operators SHOULD monitor estimator error and apply independent service-health and admission controls. Invalid clock bounds or unavailable estimates MUST NOT be interpreted as zero cost. Component identifiers are scoped to an authenticated domain; an attacker-controlled identifier MUST NOT suppress another domain's cost as a duplicate. Long retention, frequent polling, and large authorized responses can consume server resources. Producers SHOULD rate-limit collection and reads using existing management facilities, and MUST enforce the stated cardinality bounds. A consumer MUST distinguish filtering, eviction, missing instrumentation, and failures from actual zero measurements. Confidentiality and integrity protect transport but do not eliminate information exposed to an authorized reader.

IANA Considerations This document requests registration of the following URI in the IETF XML Registry . These registrations follow the IANA review procedures specified in RFC 3688 and RFC 9890.

Field	Value
URI	urn:ietf:params:xml:ns:yang:ietf-cats-context-staging-metrics
Registrant Contact	The IESG
XML	N/A; the requested URI is an XML namespace.

This document requests registration of the following module in the YANG Module Names registry, following .

Field	Value
Name	ietf-cats-context-staging-metrics
Maintained by IANA?	N
Namespace	urn:ietf:params:xml:ns:yang:ietf-cats-context-staging-metrics
Prefix	ccr
Reference	RFC XXXX

Implementation Status This section follows and is to be removed before RFC publication. The accompanying review package reports schema, example, and semantic checks for this document. Earlier validation counts are not transferred to this revision. No production framework integration, independent management endpoint interoperability, or hardware performance result is claimed.

References Normative References The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. Federal Information Processing Standard, FIPS Informative References China Mobile

JSON Instance Example This illustrative operational snapshot uses a pre-existing statically sourced service entry. The estimate is a mean, with an explicit usable-state endpoint. The string identifiers stand for definitions provisioned within the reporting domain; they are not globally registered values. { "ietf-routing:routing": { "ietf-cats:cats": { "service-metrics": { "service-metric": [ { "cs-id": 1, "csci-id": 2, "source-type": "ietf-cats:source-type-static", "ietf-cats-context-staging-metrics:context-staging-metri "boot-id": "b1", "view-id": "view-a", "snapshot-id": "s1", "estimate-limit": 16, "discarded-estimates": "0", "estimate": [ { "estimate-id": "e1", "source-scope": "tier-host-a", "destination-scope": "csci-tier-b", "state-class": "dense-fp16-v1", "workload-class": "arrival-mix-v1", "method-id": "mean-direct-v1", "observed-at": "2026-10-24T00:00:00Z", "valid-for-us": "1000000", "measurement-window-us": "10000000", "sample-count": "50", "statistic": "mean", "status": "available", "start-boundary": "lookup-start", "end-boundary": "consumer-usable", "components-complete": true, "clock-uncertainty-us": "10", "latency-us": "1200", "component": [ { "component-id": "lookup-queue-transfer-1", "kind": "other" } ] } ] } } ] } } } }

Interoperability Test Vectors

Case	Input or mutation	Expected behavior
C01	Example snapshot	Accept structure and semantics.
C02	unavailable; remove latency; samples 0	Accept as unavailable, never zero cost.
C03/C04	available without latency, or unavailable with latency	Reject affected estimate.
C05/C06	quantile without percentile; available mean with 0 samples	Reject affected estimate.
S02	T=0, Es=2, N=50, En=2, V=100 us	Freshness established.
S03/S04	Age equals V, or Es unknown	Freshness not established.
S06/S07	Duplicate component or sum of quantiles	Reject additive interpretation.
S08	components-complete=false	Do not add this estimate to another cost.

These test vectors verify representation and semantic validation rules. Operational evaluations SHOULD compare direct lookup-to-usable observations with model estimates under controlled load and record both rejection reasons and estimator error.