CATS C-SMA Nomination Snapshot and C-SMA-to-C-PS Transport Bindings

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

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 29 April 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The Computing-Aware Traffic Steering (CATS) framework [RFC10053] assigns the C-SMA the role of collecting service capabilities and status and advertising CS-IDs with metrics to C-PSes. It allows metrics to be reported per service contact instance, as aggregates, or both. The C-PS uses service information together with network information and local policy to select a destination and path. The CATS data model [I-D.ietf-cats-data-model-00] defines service identifiers and metric-type identities. Neither document defines a common C-SMA-to-C-PS snapshot format or its transport encoding.¶

This matters when a C-SMA and C-PS are independently implemented: they need to agree on the identity, scope, metric content, and candidate information conveyed by a publication, and on how that information is represented by the selected transport.¶

This document specifies the C-SMA-to-C-PS snapshot contract and two major bindings for delivering nomination snapshots from C-SMA to C-PS:¶

1. Centralized C-PS: C-SMA exposes nomination snapshots to a centralized C-PS using gNMI, where path computation is performed. This scenario can use a subscription to receive each published snapshot.¶

2. Distributed forwarding-plane selection: Nomination results are advertised directly to CATS ingress forwarding nodes. The ingress forwarding node runs local service-aware path selection, using the service metrics and candidate list carried in BGP updates. This architecture naturally reuses the BGP-LS distribution fabric.¶

This document defines a single abstract nomination snapshot model, and specifies the two alternative transport bindings for carrying this snapshot from C-SMA to C-PS. The upstream SCI-to-C-SMA interface is not defined in this document; it is treated as an input source for C-SMA. If C-SMA and C-PS are co-located and built by a single vendor, their interaction is a private internal interface and this specification is not required. Standardization applies only to cross-node, cross-vendor C-SMA → C-PS interworking.¶

2. Scope

This document contains normative requirements for:¶

• Abstract semantic model of the C-SMA nomination snapshot, including snapshot identifier, observation window, timestamp, versioning, FULL publication, refresh, invalidation, and withdrawal semantics;¶

• Rules for identifying successive publications and obtaining a fresh FULL snapshot after synchronization is lost;¶

• Two proposed transport bindings for the C-SMA → C-PS interface:¶

  1. YANG-modeled nomination snapshot delivered using gNMI¶

  2. Mapping of nomination snapshot fields into BGP-LS service-metadata TLVs associated with an identified NLRI (Network Layer Reachability Information).¶

This document explicitly excludes from normative scope:¶

• SCI-to-C-SMA metric snapshot format and interaction (referenced from a separate specification);¶

• Individual service metric definitions, metric registry entries;¶

• Existing CATS YANG configuration and state models beyond the nomination snapshot structure;¶

• Generic transport protocol characteristics and protocol applicability evaluation;¶

• Generic session keepalive, fault detection and link recovery from the CATS OAM framework;¶

• Internal C-SMA logic: aggregation algorithms, nomination ranking logic, cache eviction policies. These are implementation choices.¶

NOTE: An implementation of C-SMA MAY support one or both transport bindings. A deployment selects one binding according to its control-plane architecture. Mixed bindings in the same control domain are permitted but not required.¶

3. Design Rationale

C-SMA's nomination snapshot couples aggregated metrics with a consistent set of nominated service candidates aligned to the same observation window. A YANG data structure can define these fields independently of the protocol that delivers them. For centralized deployments, gNMI provides a streaming subscription mechanism for YANG-modeled operational state. Binding 1 specifies how complete snapshots and lifecycle events are represented in the subscribed data and how a C-PS resynchronizes.¶

Instead of creating separate semantic structures for centralized and distributed deployments, this specification decouples the abstract nomination snapshot semantics from the underlying transport.¶

• For centralized C-PS: a YANG-modeled snapshot is exposed through a gNMI subscription. Each FULL publication is delivered as a complete snapshot update, with lifecycle and synchronization rules specified in Binding 1.¶

• For distributed selection on CATS ingress forwarding nodes: the same abstract snapshot content is encoded into BGP-LS service attributes, reusing BGP's mature update, withdraw and flooding mechanisms across the routing domain.¶

This approach keeps one consistent nomination data model for C-SMA output, while allowing operators to choose the control-plane distribution mechanism matching their network design.¶

4. Abstract Nomination Snapshot Model (Normative Core)

A nomination snapshot is published by one C-SMA for one CS-ID. It explicitly identifies the CSCI-IDs covered by its aggregated metrics and candidate list. An SCI-to-C-SMA computing-metric snapshot can provide input to this publication, but this C-SMA-to-C-PS snapshot has a different publisher, scope, and candidate information. The following fields describe that information. The YANG node names correspond to the operational-state schema and notification in Appendix B. It imports the reusable CATS identifier typedefs and metric-type identity from [I-D.ietf-cats-data-model-00]:¶

The YANG representation is a nomination-snapshot operational-state entry (with a notification available for the alternative HTTPS/RESTCONF binding) containing one publication from one publisher for one CS-ID. It is distinct from an SCI-originated computing-metric-snapshot notification: the C-SMA may aggregate input from multiple SCIs and add covered-instance status and nomination results before publishing to the C-PS. The publisher-id, publisher-epoch, cs-id, and snapshot-version identify one publication generation; snapshot-id identifies the publication event within that epoch and does not replace snapshot-version for ordering or validity checks. CS-ID and CSCI-ID use the CATS data-model typedefs; publisher-id remains a local identifier. A later version in the same epoch and CS-ID scope denotes a later publication.¶

Each covered-instance entry identifies one CSCI-ID and carries its status. Each candidate refers to a covered CSCI-ID; ranks and any constraint tags require defined types and uniqueness rules. A metric-entry contains a CATS metric-type identity and one typed value. The specification defining that identity determines the value branch, units, and validity semantics. The module offers unsigned, decimal, text, and boolean value branches. The module uses a required choice with full-snapshot, invalidated-version, and withdraw cases; the selected case conveys the snapshot type. Window times and metric entries occur only in a FULL snapshot. An INVALIDATE signal identifies the version that is no longer valid; a WITHDRAW signal identifies the publisher and CS-ID whose publication is removed. Deleting a YANG data node is not, by itself, a snapshot withdrawal.¶

A FULL snapshot is one logically complete and consistent publication for a single publisher, publisher epoch, and CS-ID. Its covered-instance statuses, aggregated metrics, and nominated candidate set MUST be interpreted together as one publication generation. A receiver MUST NOT combine fields from different snapshot versions to construct a current nomination view. Each transport binding MUST preserve this logical publication boundary, either by carrying the complete publication atomically or by defining explicit reconstruction and synchronization procedures.¶

All transport bindings defined in this document SHALL carry the complete information represented by this abstract model. Interoperability conformance is judged against this abstract model, not against a particular transport encoding. Appendix B contains the YANG module. Binding 1 specifies its gNMI subscription and update semantics. HTTPS/RESTCONF is a potential alternative described in Appendix C. Each metric identity needs an unambiguous value branch and interpretation.¶

5. Snapshot Publication and Refresh Semantics

The reporting policy determines when the C-SMA publishes information. The periodic refresh and significant-change triggers described in [I-D.zhangb-cats-service-metrics-op] may be used for this purpose. A threshold-triggered report is a report caused by a change; it does not imply an INCREMENTAL payload. This document defines the publication content and its meaning on the C-SMA-to-C-PS interface, not the threshold values, reporting interval, or local metric cache.¶

A publisher sends a FULL snapshot for each publisher and CS-ID when a C-PS first establishes its view, on a periodic refresh, and after a significant metric, candidate, or instance-status change. Each FULL snapshot contains the complete current covered set, aggregated metric set, instance statuses, and nominated candidate set for that publisher and CS-ID. Its version is greater than the preceding version for the same publisher, epoch, and CS-ID. After restart or loss of version state, the publisher changes its epoch and sends a new FULL snapshot. A new FULL snapshot replaces the preceding publication in that scope.¶

If one covered instance becomes unavailable, the publisher issues a new FULL snapshot promptly according to the reporting policy. The snapshot can retain that instance in the covered set with an unavailable status while removing it from the candidate list. That change does not withdraw the publication for the CS-ID.¶

An INVALIDATE signal targets only the specified snapshot version within its publisher, epoch, and CS-ID scope. A receiver MUST NOT invalidate a different, later FULL snapshot solely because an older version was invalidated. If the targeted version is the receiver's current version, the receiver MUST cease treating that FULL snapshot as current until a subsequent valid FULL snapshot is obtained. A WITHDRAW removes the current publication for the identified publisher and CS-ID, regardless of the version previously held by the receiver. Both signals are explicit; silence, expiry, and deletion of a YANG node are not equivalent to a publisher-issued WITHDRAW. The C-PS determines its local response to unavailable or expired information under its own policy. A publisher that resumes after a lost subscription or other loss of synchronization provides a fresh FULL snapshot before relying on subsequent publications.¶

This profile uses complete FULL snapshots for both periodic and change-triggered reporting. It does not define INCREMENTAL payloads. A future extension may add them only with explicit base-version, ordering, and resynchronization rules for each binding.¶

6. Transport Binding 1: YANG-Modeled Snapshots over gNMI

In a centralized deployment, the C-SMA acts as a gNMI target and exposes its nomination snapshot state to an authorized C-PS acting as a gNMI client. The interface uses the gNMI Subscribe RPC with TLS protection [GNMI-SPEC]. This binding uses the abstract snapshot semantics and the YANG-defined fields in Appendix B; it does not treat a YANG notification as a directly subscribable gNMI path.¶

The gNMI target MUST expose a YANG-modeled operational-state subtree keyed by publisher-id and cs-id, containing the snapshot context and the complete current covered-instance, metric, and candidate sets. Appendix B defines the operational-state schema. The canonical path is /cats-ns:nomination-snapshots/nomination-snapshot, with publisher-id and cs-id list keys.¶

The C-PS establishes a STREAM subscription to the snapshot state subtree. A target supporting ON_CHANGE for this subtree SHOULD use ON_CHANGE and send updates following each FULL publication. Where ON_CHANGE is not supported, a SAMPLE subscription MAY be used with an operator-selected sample interval. In either mode, the target MUST provide a complete consistent FULL snapshot for each subscribed publisher and CS-ID on initial synchronization and after a change that affects the snapshot. A gNMI Notification may contain multiple Update messages; the receiver MUST NOT treat an arbitrary individual Update as a complete snapshot unless the encoding explicitly identifies the complete publication boundary.¶

The snapshot context includes publisher-id, publisher-epoch, cs-id, snapshot-id, and snapshot-version. For the same publisher, epoch, and CS-ID, a higher-version FULL publication replaces the previous publication, including its candidate and metric sets. Removal of a candidate from a replacement FULL snapshot is not a WITHDRAW. INVALIDATE and WITHDRAW MUST be represented as explicit lifecycle events with their scope and, for INVALIDATE, the targeted version; a gNMI Delete operation on a state path alone does not establish the abstract WITHDRAW semantics. The operational-state schema defines explicit invalidated-version and withdrawn cases. The target MUST send the complete list entry as one JSON_IETF-valued gNMI Update at the keyed entry path, not as independently consumable leaf updates; receivers MUST apply it atomically. This is a binding requirement, not a guarantee provided by gNMI for arbitrary multi-update Notifications.¶

If a subscription is interrupted, an update is missed, or a complete publication cannot be reconstructed, the C-PS MUST resubscribe and obtain a new complete FULL snapshot before treating subsequent data as synchronized. The C-SMA changes its publisher epoch if restart loses version continuity. Reporting triggers follow [I-D.zhangb-cats-service-metrics-op]; this document does not prescribe thresholds or sampling intervals.¶

gNMI subscription synchronization establishes the transport's initial state view; it does not supersede the snapshot's publisher-epoch and snapshot-version ordering rules. The C-PS MUST validate these fields when accepting a publication and MUST NOT merge fields from different versions, including across subscription reconnection.¶

7. Transport Binding 2: Mapping to BGP-LS Service Attribute NLRI (Normative)

This section proposes a BGP-LS mapping for deployments in which a C-PS at an ingress CATS-Forwarder receives nomination information through BGP-LS distribution. The exact NLRI, TLV definitions, field mapping, and code-point allocations remain to be specified. Appendix A illustrates the intended deployment without defining a wire encoding.¶

This profile is limited to a service whose CS-ID maps unambiguously to one service prefix and for which one authorized publisher owns the advertisement for that prefix in the distribution domain. A future BGP-LS encoding would use the corresponding Prefix NLRI and associate a service-metadata TLV in the BGP-LS Attribute with it. The TLV would contain CATS-specific sub-TLVs for Snapshot Context (publisher identity, epoch, CS-ID, snapshot ID, version, and window), Covered Instance and Status, repeated CATS Metric entries, and Candidate entries. The exact TLV and sub-TLV types, lengths, duplicate rules, and code points require IDR coordination and are not assigned here.¶

Each BGP UPDATE for the NLRI carries the complete current FULL snapshot in one advertisement. The publisher sends replacement UPDATEs after significant changes and for periodic refresh under the policy described in [I-D.zhangb-cats-service-metrics-op]; a threshold-triggered report is still encoded as a FULL snapshot. A changed or unavailable instance is represented in a replacement FULL snapshot and does not withdraw the NLRI. To signal INVALIDATE while retaining the NLRI, the future Snapshot Context sub-TLV needs an explicit invalid indication and the targeted version. WITHDRAW removes the whole publication by withdrawing the NLRI. The encoding must make the publisher and CS-ID scope of that withdrawal unambiguous.¶

A BGP-LS receiver can obtain the current complete advertisement after joining or restarting without reconstructing earlier deltas. This profile does not map INCREMENTAL snapshot payloads into ordinary BGP UPDATEs. It does not define a new BGP session behavior or address family. Appendix A illustrates the prefix-addressable case; a general CS-ID or multiple publishers for one prefix require additional identification mechanisms.¶

8. Security Considerations

The abstract nomination snapshot carries service selection state that affects forwarding behavior. All transport bindings MUST provide authentication, integrity and replay protection.¶

• gNMI transport: authenticate and authorize the C-SMA target and C-PS client, protect the gRPC exchange using TLS, and restrict Subscribe access to the intended snapshot paths;¶

• BGP-LS transport: distribution must be restricted to authorized CATS nodes and the intended administrative domain. The final BGP-LS encoding must identify mechanisms for publisher authentication, integrity, confidentiality, and freshness; TCP-AO or BGPsec alone does not provide all of these properties.¶

9. IANA Considerations

The YANG namespace and module name in Appendix B require registration if this document advances. The gNMI operational-state schema and paths are defined in Appendix B. The proposed BGP-LS mapping requires TLV and sub-TLV assignments only after its encoding is specified and reviewed with IDR. No BGP-LS code points are requested by this version.¶

Appendix A. Illustrative BGP-LS Distribution Scenario

This appendix is informative. It illustrates a possible mapping for a service whose CS-ID is unambiguously associated with an IP prefix. The names and values below are examples; no NLRI, TLV, sub-TLV, or code point is allocated by this appendix.¶

Suppose CS-ID 42 is associated with service prefix 2001:db8:42::/48. C-SMA csma-1 publishes a FULL snapshot covering CSCI-IDs 101 and 102. The snapshot identifies its publisher, CS-ID, snapshot ID and version, observation window, aggregated metric records, and instance status markers. Its candidate list nominates 101 at rank 1 and 102 at rank 2.¶

For this prefix-addressable case, a future BGP-LS binding could associate a Prefix NLRI for 2001:db8:42::/48 with a service-metadata TLV in the BGP-LS Attribute. Proposed CATS-specific sub-TLVs within that container would carry Snapshot Context (including csma-1, 42, and snapshot identification), Covered Instance entries for 101 and 102, the CATS Metric entries, Candidate entries with their ranks, and Instance Status entries. The service prefix alone identifies 42 only where that binding is configured or otherwise specified unambiguously; a general CS-ID requires an explicit encoding or another suitable NLRI.¶

If 102 becomes unavailable, csma-1 publishes a later FULL snapshot for the same service. Its covered set still includes 102, its status marks 102 unavailable, and its candidate list contains only 101. In the illustrated BGP-LS approach, a new UPDATE replaces the attributes for the same NLRI with this complete current snapshot. Removal of the entire publication would instead withdraw that NLRI. Removing one candidate does not by itself withdraw the service NLRI.¶

The authorized BGP-LS distribution domain delivers the advertisement to an ingress CATS-Forwarder hosting a C-PS. The C-PS receives the snapshot information and combines it with network information under its own selection policy. An eventual binding specification needs to define the exact container and sub-TLV encodings, duplicate and unknown-type handling, size limits, authorization, and the relationship between the NLRI and CS-ID.¶

Appendix B. YANG Module for C-SMA Nomination Snapshots

This YANG module defines read-only C-SMA-to-C-PS operational state for gNMI Binding 1 and defines a notification usable by the alternative HTTPS/RESTCONF binding. It imports cats:cs-id, cats:csci-id, and cats:metric-type-base from the CATS data model [I-D.ietf-cats-data-model-00]. It also imports ietf-yang-types [RFC9911] for yang:uuid and yang:date-and-time. The metric-value choice and snapshot-specific fields remain defined here. This module is separate from any SCI-to-C-SMA notification model.¶

module ietf-cats-nomination-snapshot {
  yang-version 1.1;
  namespace
    "urn:ietf:params:xml:ns:yang:ietf-cats-nomination-snapshot";
  prefix cats-ns;

  import ietf-yang-types {
    prefix yang;
    reference "RFC 9911: Common YANG Data Types";
  }

  import ietf-cats {
    prefix cats;
    reference
      "draft-ietf-cats-data-model-00: Data Model for Computing-Aware
       Traffic Steering (CATS)";
  }

  organization "IETF CATS Working Group";
  contact "WG mailing list: cats@ietf.org";
  description
    "C-SMA to C-PS nomination snapshot state and notifications.  This module
     does not define the SCI to C-SMA reporting interface or metric
     definitions.  CS-ID, CSCI-ID, and metric-type reuse the ietf-cats
     module.  Snapshot-specific fields are defined here.";

  revision 2026-10-26 {
    description "Add gNMI-readable operational state and shared grouping.";
  }

  grouping full-snapshot-content {
    description
      "Fields of a complete nomination snapshot.  Only identifier
       and metric identity definitions are reused from ietf-cats.";
    leaf window-start {
      type yang:date-and-time;
      mandatory true;
      description "Start of the aggregate observation window.";
    }
    leaf window-end {
      type yang:date-and-time;
      mandatory true;
      description
        "End of the aggregate observation window, later than
         window-start.";
    }
    list covered-instance {
      key "csci-id";
      min-elements 1;
      description
        "Complete set of instances represented by this full
         snapshot's aggregate metrics.";
      leaf csci-id {
        type cats:csci-id;
        description "Covered service contact instance.";
      }
      leaf status {
        type enumeration {
          enum available;
          enum drained;
          enum failed;
          enum unknown;
        }
        mandatory true;
        description "Reported instance availability.";
      }
    }
    list metric-entry {
      key "metric-type";
      description
        "One aggregate value per metric-type identity.  The specification defining that identity determines the appropriate value branch, unit, statistics, and validity semantics.";
      leaf metric-type {
        type identityref {
          base cats:metric-type-base;
        }
        description "Metric type defined in ietf-cats or derived from its metric-type-base identity.";
      }
      choice metric-value {
        mandatory true;
        case unsigned {
          leaf unsigned-value { type uint64; }
        }
        case decimal {
          leaf decimal-value {
            type decimal64 { fraction-digits 6; }
          }
        }
        case text {
          leaf text-value { type string; }
        }
        case boolean {
          leaf boolean-value { type boolean; }
        }
      }
      leaf window-start {
        type yang:date-and-time;
        description "Metric-specific window start, if different.";
      }
      leaf window-end {
        type yang:date-and-time;
        description "Metric-specific window end, if different.";
      }
      leaf valid-until {
        type yang:date-and-time;
        description "End of the metric's stated validity.";
      }
    }
    list candidate {
      key "csci-id";
      unique "rank";
      description
        "Complete nominated set for this publication.  Every
         candidate must also be a covered instance.";
      leaf csci-id {
        type cats:csci-id;
        description "Nominated service contact instance.";
      }
      leaf rank {
        type uint16 { range "1..max"; }
        mandatory true;
        description "Publisher's nomination order; 1 is first.";
      }
      leaf-list constraint-tag {
        type string;
        description
          "An applicable constraint tag.  Tag syntax and
           semantics require a separate definition.";
      }
    }
  }

  container nomination-snapshots {
    config false;
    description
      "Read-only C-SMA publication state for gNMI Subscribe.";
    list nomination-snapshot {
      key "publisher-id cs-id";
      description
        "Latest complete publication or explicit lifecycle event
         for a publisher and service.  The entire list entry is
         retrieved as one atomic JSON_IETF update.";
      leaf publisher-id {
        type string { length "1..max"; }
        description "Identity of the publishing C-SMA.";
      }
      leaf cs-id {
        type cats:cs-id;
        description "Service identifier.";
      }
      leaf publisher-epoch {
        type yang:uuid;
        mandatory true;
        description "Publisher generation identifier.";
      }
      leaf snapshot-id {
        type uint64;
        mandatory true;
        description "Unique event identifier within the epoch.";
      }
      leaf snapshot-version {
        type uint64;
        mandatory true;
        description "Monotonically increasing event version in scope.";
      }
      choice publication-content {
        mandatory true;
        description "Explicit current publication or lifecycle event.";
        case full {
          container full-snapshot {
            presence "Complete published snapshot is available.";
            uses full-snapshot-content;
          }
        }
        case invalidate {
          leaf invalidated-version {
            type uint64;
            mandatory true;
            description "Version explicitly invalidated.";
          }
        }
        case withdraw {
          leaf withdrawn {
            type empty;
            description "Explicit withdrawal of this publication.";
          }
        }
      }
    }
  }

  notification nomination-snapshot {
    description
      "One publication from a C-SMA for one CS-ID.  The publisher
       sends a full notification at subscription establishment,
       periodically, and after a significant change.";

    leaf publisher-id {
      type string { length "1..max"; }
      mandatory true;
      description "Identity of the publishing C-SMA.";
    }
    leaf publisher-epoch {
      type yang:uuid;
      mandatory true;
      description
        "Changes when the publisher restarts or loses its version
         state.  A new epoch starts a new version sequence.";
    }
    leaf cs-id {
      type cats:cs-id;
      mandatory true;
      description "Service described by this publication.";
    }
    leaf snapshot-id {
      type uint64;
      mandatory true;
      description
        "Identifier unique within the publisher epoch for this
         notification event.";
    }
    leaf snapshot-version {
      type uint64;
      mandatory true;
      description
        "Publication generation for this publisher, epoch, and
         CS-ID.  It increases for each event in that scope.";
    }

    choice publication-content {
      mandatory true;
      description "The publication operation and its content.";

      case full {
        container full-snapshot {
          presence "This event publishes a complete current snapshot.";
          description
            "Replaces the previous publication for the same
             publisher and CS-ID.";
          uses full-snapshot-content;
        }
      }
      case invalidate {
        leaf invalidated-version {
          type uint64;
          mandatory true;
          description
            "Version whose information is no longer valid in the
             identified publisher, epoch, and CS-ID scope.";
        }
      }
      case withdraw {
        leaf withdraw {
          type empty;
          description
            "Remove the publisher's current publication for the
             identified CS-ID.  This is not candidate removal.";
        }
      }
    }
  }
}

Appendix C. HTTPS/RESTCONF as an Alternative Transport Binding (Informative)

{
  "ietf-restconf:notification": {
    "eventTime": "2026-10-23T10:00:01Z",
    "ietf-cats-nomination-snapshot:nomination-snapshot": {
      "publisher-id": "csma-1",
      "publisher-epoch": "f81d4fae-7dec-11d0-a765-00a0c91e6bf6",
      "cs-id": 42,
      "snapshot-id": "1001",
      "snapshot-version": "7",
      "full-snapshot": {
        "window-start": "2026-10-23T09:59:00Z",
        "window-end": "2026-10-23T10:00:00Z",
        "covered-instance": [
          { "csci-id": 101, "status": "available" },
          { "csci-id": 102, "status": "available" }
        ],
        "metric-entry": [
          {
            "metric-type": "ietf-cats:metric-delay",
            "unsigned-value": "12"
          }
        ],
        "candidate": [
          { "csci-id": 101, "rank": 1 },
          { "csci-id": 102, "rank": 2 }
        ]
      }
    }
  }
}

Appendix D. Acknowledgments

The authors thank the CATS working group for their valuable feedback and contributions to this document.¶

Authors' Addresses