<?xml version='1.0' encoding='utf-8'?>
<rfc category="std" docName="draft-zhangb-cats-sci-implementation-02" ipr="trust200902" submissionType="IETF" consensus="true" version="3" tocInclude="true" symRefs="true" sortRefs="true">
  <front>
    <title abbrev="CATS Metric Snapshot Exchange">Metric Snapshot Exchange between SCI and C-SMA in CATS</title>
    <author fullname="Bin Zhang" initials="B." surname="Zhang" role="editor">
      <organization>Pengcheng Laboratory</organization>
      <address>
        <postal>
          <street>Sibilong Street</street>
          <city>Shenzhen</city>
          <region>Guangdong</region>
          <code>518055</code>
          <country>CN</country>
        </postal>
        <email>zhangb@pcl.ac.cn</email>
      </address>
    </author>
    <author fullname="Bowen Shen" initials="B." surname="Shen" role="editor">
      <organization>Harbin Institute of Technology</organization>
      <address>
        <postal>
          <street>Taoyuan Street</street>
          <city>Shenzhen</city>
          <code>518055</code>
          <country>China</country>
        </postal>
        <email>shenbowen@stu.hit.edu.cn</email>
      </address>
    </author>
    <author fullname="Yixuan Yang" initials="Y." surname="Yang" role="editor">
      <organization>Sun Yat-sen University</organization>
      <address>
        <postal>
          <street>Gongchang Street</street>
          <city>Shenzhen</city>
          <region>Guangdong</region>
          <code>518055</code>
          <country>CN</country>
        </postal>
        <email>yangyx277@mail2.sysu.edu.cn</email>
      </address>
    </author>
    <date year="2026" month="October" day="26" />
    <area>Routing</area>
    <workgroup>Computing-Aware Traffic Steering</workgroup>
    <keyword>CATS</keyword>
    <keyword>Service Contact Instance</keyword>
    <keyword>metric snapshot</keyword>
    <keyword>interoperability</keyword>
    <abstract>
      <t>This document specifies metric snapshot exchange between a Service Contact Instance (SCI) and a CATS Service Metric Agent (C-SMA). It defines atomic replacement, ordering, and validity for periodic full snapshots and change-triggered updates over HTTPS/JSON. An informative appendix explains how one shared snapshot YANG model can support generation of the publication and response messages.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro">
      <name>Introduction</name>
      <t>The SCI supplies service observations to the C-SMA, which reports service information to the CATS Path Selector (C-PS) <xref target="RFC10053" />. A snapshot groups metrics so that the consumer can apply a coherent publication and distinguish it from older or incomplete updates.</t>
      <t>The contract applies to independently implemented components and can also be used within a co-located platform. Individual metrics follow their defining specifications. A shared, versioned metric profile fixes metric keys, units, value encodings, required members, observation windows, maximum ages, and cross-metric acceptance constraints.</t>
      <t>
        <xref target="https" /> defines the HTTPS/JSON exchange. All structured messages described here can be populated and serialized by tooling based on one shared snapshot YANG model, using the mapping in <xref target="yang-model" />. That appendix is informative; conformance is determined by the snapshot contract and HTTPS/JSON binding in the main body.</t>
      <section anchor="motivation">
        <name>Motivation for the HTTPS/JSON Binding</name>
        <t>SCI and C-SMA may run on different hosts. The reporting policy recommends a 10-second refresh and sends an update whenever a published metric changes. With many SCI sources, these changes produce frequent updates that require an external reporting interface.</t>
        <t>gNMI supports periodic and on-change telemetry <xref target="GNMI" />. On a service host without a gNMI target, using it requires a target or adapter with gRPC/Protobuf and subscription handling. The C-SMA must establish subscriptions to those targets. This adds deployment work to service applications that already use HTTP clients.</t>
        <t>With RESTCONF polling, the C-SMA makes repeated reads and detects changes only at the next poll. Notification streams and dynamic subscriptions avoid polling but require a publisher endpoint and subscription handling <xref target="RFC8040" />
          <xref target="RFC8650" />. A RESTCONF push RPC is also possible, with a YANG RPC definition and RESTCONF operation mapping.</t>
        <t>This binding uses SCI-initiated HTTPS POST to a C-SMA collector, reusing existing HTTP clients and authenticated connections. The SCI publishes changes under the exchange rules without deploying a telemetry server on every SCI or requiring C-SMA subscriptions. The JSON contract defines snapshot acceptance, ordering, and retry behavior for this exchange.</t>
      </section>
      <section anchor="requirements">
        <name>Requirements Language</name>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" are interpreted as described in BCP 14 <xref target="RFC2119" />
          <xref target="RFC8174" /> when they appear in all capitals.</t>
      </section>
    </section>
    <section anchor="snapshot">
      <name>Snapshot Messages</name>
      <t>A reporting scope is (provider, cs-id, csci-id, group). Each scope has one authorized logical producer and one active profile. FULL, DELTA, and WITHDRAW reuse the following envelope.</t>
      <table>
        <name>Publication envelope</name>
        <thead>
          <tr>
            <th>Field</th>
            <th>Meaning</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td>contract</td>
            <td>Integer 1 for this contract.</td>
          </tr>
          <tr>
            <td>scope</td>
            <td>Object containing provider, cs-id, csci-id, and group.</td>
          </tr>
          <tr>
            <td>profile</td>
            <td>Identifier of the shared metric profile version.</td>
          </tr>
          <tr>
            <td>context</td>
            <td>Current receiver token, issued by the C-SMA.</td>
          </tr>
          <tr>
            <td>generation, revision</td>
            <td>Producer lifetime and publication numbers; revision is positive.</td>
          </tr>
          <tr>
            <td>kind</td>
            <td>FULL, DELTA, or WITHDRAW.</td>
          </tr>
          <tr>
            <td>generated-at</td>
            <td>UTC time when this publication was assembled.</td>
          </tr>
          <tr>
            <td>entries</td>
            <td>Metric-keyed object for FULL and DELTA; absent for WITHDRAW.</td>
          </tr>
          <tr>
            <td>base-revision, remove</td>
            <td>DELTA only: accepted base revision and array of keys to remove.</td>
          </tr>
        </tbody>
      </table>
      <t>Each entry contains status, observed-at, and valid-until. An available entry includes value; an unavailable entry omits it. An available interval statistic also contains window-start and window-end, with observed-at equal to window-end. Instantaneous and unavailable entries omit the window fields.</t>
      <t>The consumer MUST validate and apply each publication as one operation. FULL replaces the group, DELTA replaces or removes listed entries, and WITHDRAW removes the group. A required profile member must remain present in FULL and after DELTA, with either available or unavailable status. A DELTA key MUST NOT occur in both entries and remove.</t>
      <t>An omitted entry is removed by FULL and unchanged by DELTA. An unavailable required metric makes the group unusable but does not prevent acceptance; numeric constraints apply to available values. The same scope and entry definitions are reused for every publication kind, including in the shared-model mapping in <xref target="yang-model" />.</t>
    </section>
    <section anchor="exchange">
      <name>Exchange Rules</name>
      <t>FULL and WITHDRAW are required; DELTA is optional. The SCI serializes requests per scope, waiting for a response or timeout before sending another. A new publication has a greater revision than all earlier publications assigned in the generation; a retry preserves the same version and body bytes.</t>
      <t>Generations increase across producer resets and MUST NOT be reused or wrap. The consumer compares (generation, revision) lexicographically. A new context or higher generation requires FULL; DELTA requires the currently accepted base-revision in the same generation and a PRESENT group.</t>
      <t>An identical retry of the last accepted publication returns DUPLICATE. Older versions return STALE, and different content at the same version returns CONFLICT. A missing delta base or outdated context returns RESYNC; the producer obtains the descriptor and sends a newer FULL. Rejected messages leave accepted state unchanged.</t>
      <t>The C-SMA retains ordering state after expiry and withdrawal. Loss of that state, or a change to producer authorization, profile, capabilities, or limits, invalidates the group and creates a fresh context. Old-context publications cannot restore that group.</t>
      <t>The deployment maintains a maximum clock difference S. The consumer rejects observations later than generated-at or more than S ahead of its own time; it also checks window-start &lt;= window-end and observed-at &lt; valid-until within the profile's maximum age. Each metric retains its own measurement window.</t>
      <t>An entry is usable only while the receiver's time plus S is earlier than valid-until. A group needs all required entries to be available and usable; expiry stops their use even if no message arrives. A newer valid publication advances ordering even when its observations have already expired. Retransmission and forwarding MUST NOT extend source validity.</t>
      <section anchor="reporting-policy">
        <name>Periodic and Change-Triggered Reporting</name>
        <t>While advertising a service offer, the SCI MUST schedule a FULL report at each configured period boundary, even when values are unchanged. The recommended default period is 10 seconds. Triggered updates MUST NOT reset this timer.</t>
        <t>Every detected change in a published metric value, availability, or entry membership MUST trigger an update, sent promptly under the serialized exchange rules. Use DELTA when supported and a valid base exists; otherwise use FULL. The SCI applies no change-magnitude threshold.</t>
        <t>The SCI derives service metrics locally and reports their changes. The C-SMA controls downstream aggregation, thresholds, and publication timing toward the C-PS. Periodic reports use current observations; retained samples keep their original observation times and validity.</t>
      </section>
    </section>
    <section anchor="https">
      <name>HTTPS/JSON Binding</name>
      <t>The provider provisions one HTTPS endpoint per scope, the authorized producer, and the metric profile. HTTP <xref target="RFC9110" /> uses mutually authenticated TLS 1.3 <xref target="RFC8446" />. GET retrieves the receiver descriptor; POST submits a publication. Bodies are UTF-8 application/json <xref target="RFC8259" />, and responses use Cache-Control: no-store.</t>
      <t>The descriptor contains contract, scope, profile, context, delta-supported, max-message-bytes, max-entries, max-clock-skew-ms, current-generation, current-revision, and state. State is EMPTY, PRESENT, or WITHDRAWN; current version fields are null in EMPTY. PRESENT indicates accepted state whose usability follows <xref target="exchange" />.</t>
      <t>Context is a non-reused 32-character lowercase hexadecimal token generated from 128 unpredictable bits. The three max fields are positive integers: they bound request-body bytes, each entries/remove collection and resulting group size, and clock difference S in milliseconds. Delta-supported is boolean.</t>
      <t>Identifiers and profile keys are nonempty case-sensitive strings. Version numbers are unsigned 64-bit decimal strings without leading zeros; revision is nonzero. Times use UTC RFC 3339 strings ending in Z <xref target="RFC3339" /> with up to nine fractional digits. Value types and ranges follow the profile.</t>
      <t>The receiver checks authorization, envelope, context, capability, ordering, and the resulting group. It rejects unsupported contract versions or profiles, duplicate JSON names, unknown members or metric keys, invalid types or ranges, and exceeded limits. All envelope fields are required except those restricted to another kind; entries use only the fields in <xref target="snapshot" />.</t>
      <t>The JSON result contains result, context, submitted-generation, submitted-revision, current-generation, current-revision, and state. HTTP 200 carries ACCEPTED or DUPLICATE; 409 carries RESYNC, STALE, or CONFLICT; 422 carries INVALID. Malformed JSON returns 400, unauthorized requests 401 or 403, oversized bodies 413, and unsupported media types or Content-Encoding 415.</t>
      <t>A timeout leaves the outcome unknown: retry the same body or obtain the descriptor before sending a newer FULL. A response must match the submitted context and version to acknowledge that publication. Unsupported DELTA returns INVALID. Senders omit Content-Encoding and do not follow endpoint redirects automatically.</t>
    </section>
    <section anchor="example">
      <name>JSON Example</name>
      <t>The example uses profile example-service-v2 for GAS, Computing Time, Price, Reputation, and Security Level as described in <xref target="I-D.zhangb-cats-service-metrics-op" />. GAS and Computing Time are required; the other three attributes are optional. The profile uses a maximum age of 20 seconds and the value types below.</t>
      <table>
        <name>Example metric profile</name>
        <thead>
          <tr>
            <th>Key</th>
            <th>Value interpretation</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td>gas</td>
            <td>uint32; available concurrent-request count; instantaneous estimate.</td>
          </tr>
          <tr>
            <td>comp_time</td>
            <td>Nonnegative finite number; mean processing time in milliseconds over the given window.</td>
          </tr>
          <tr>
            <td>price</td>
            <td>uint16; provider-defined pricing unit.</td>
          </tr>
          <tr>
            <td>reputation</td>
            <td>Integer score from 0 to 10.</td>
          </tr>
          <tr>
            <td>security_level</td>
            <td>Integer score from 0 to 10.</td>
          </tr>
        </tbody>
      </table>
      <t>All five values apply to the same service offer. The SCI has confirmed the attributes at the observation time; the context token is an illustrative value standing for a token obtained by GET. The following body is also supplied as <tt>sci-csma-snapshot-main-02.example.json</tt>.</t>
      <figure anchor="full-example">
        <name>Full service snapshot</name>
        <sourcecode type="json">{
  "contract": 1,
  "scope": {
    "provider": "p1",
    "cs-id": "S1",
    "csci-id": "SCI-A",
    "group": "service-offer"
  },
  "profile": "example-service-v2",
  "context": "fedcba9876543210fedcba9876543210",
  "generation": "7",
  "revision": "12",
  "kind": "FULL",
  "generated-at": "2026-10-24T08:00:10Z",
  "entries": {
    "gas": {
      "status": "available",
      "value": 7,
      "observed-at": "2026-10-24T08:00:10Z",
      "valid-until": "2026-10-24T08:00:30Z"
    },
    "comp_time": {
      "status": "available",
      "value": 10.0,
      "observed-at": "2026-10-24T08:00:10Z",
      "valid-until": "2026-10-24T08:00:30Z",
      "window-start": "2026-10-24T08:00:00Z",
      "window-end": "2026-10-24T08:00:10Z"
    },
    "price": {
      "status": "available",
      "value": 100,
      "observed-at": "2026-10-24T08:00:10Z",
      "valid-until": "2026-10-24T08:00:30Z"
    },
    "reputation": {
      "status": "available",
      "value": 8,
      "observed-at": "2026-10-24T08:00:10Z",
      "valid-until": "2026-10-24T08:00:30Z"
    },
    "security_level": {
      "status": "available",
      "value": 7,
      "observed-at": "2026-10-24T08:00:10Z",
      "valid-until": "2026-10-24T08:00:30Z"
    }
  }
}</sourcecode>
      </figure>
      <t>Acceptance returns HTTP 200 with result ACCEPTED and current version (7, 12). An identical retry returns DUPLICATE. A DELTA with revision 13 and base-revision 12 can replace an entry; an unknown base returns RESYNC. WITHDRAW removes the offer while retaining its accepted version.</t>
      <t>For a 10-second period, a FULL at t=0 can be followed by change-triggered updates at t=3 and t=7, then another FULL at t=10. Those updates do not postpone the periodic report. The example's 20-second maximum age leaves margin for delivery and clock error between periodic observations; it does not refresh retained samples.</t>
    </section>
    <section anchor="security">
      <name>Security Considerations</name>
      <t>A forged or replayed snapshot can affect service selection. The C-SMA authorizes the authenticated publisher for its scope, protects ordering state, and rotates context after losing that state. A deployment unable to maintain its clock bound suspends use of time-sensitive groups. Message limits, access controls, and bounded log retention protect processing capacity and service information <xref target="RFC10053" />.</t>
    </section>
    <section anchor="iana">
      <name>IANA Considerations</name>
      <t>This document requests no IANA allocations.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>Normative References</name>
      <reference anchor="RFC2119">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <author initials="S." surname="Bradner" fullname="Scott Bradner" />
          <date year="1997" month="March" />
        </front>
        <seriesInfo name="BCP" value="14" />
        <seriesInfo name="RFC" value="2119" />
        <format type="TXT" target="https://www.rfc-editor.org/rfc/rfc2119.txt" />
      </reference>
      <reference anchor="RFC8174">
        <front>
          <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <author initials="B." surname="Leiba" fullname="Barry Leiba" />
          <date year="2017" month="May" />
        </front>
        <seriesInfo name="BCP" value="14" />
        <seriesInfo name="RFC" value="8174" />
        <format type="TXT" target="https://www.rfc-editor.org/rfc/rfc8174.txt" />
      </reference>
      <reference anchor="RFC10053" target="https://www.rfc-editor.org/info/rfc10053">
        <front>
          <title>A Framework for Computing-Aware Traffic Steering (CATS)</title>
          <author initials="C." surname="Li" fullname="C. Li" role="editor" />
          <author initials="Z." surname="Du" fullname="Z. Du" />
          <author initials="M." surname="Boucadair" fullname="M. Boucadair" role="editor" />
          <author initials="L. M." surname="Contreras" fullname="L. M. Contreras" />
          <author initials="J." surname="Drake" fullname="J. Drake" />
          <date year="2026" month="October" />
        </front>
        <seriesInfo name="RFC" value="10053" />
        <seriesInfo name="DOI" value="10.17487/RFC10053" />
      </reference>
      <reference anchor="RFC9110" target="https://www.rfc-editor.org/info/rfc9110">
        <front>
          <title>HTTP Semantics</title>
          <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding" />
          <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham" />
          <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke" />
          <date month="June" year="2022" />
        </front>
        <seriesInfo name="STD" value="97" />
        <seriesInfo name="RFC" value="9110" />
        <seriesInfo name="DOI" value="10.17487/RFC9110" />
      </reference>
      <reference anchor="RFC8259" target="https://www.rfc-editor.org/info/rfc8259">
        <front>
          <title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
          <author fullname="T. Bray" initials="T." role="editor" surname="Bray" />
          <date month="December" year="2017" />
        </front>
        <seriesInfo name="STD" value="90" />
        <seriesInfo name="RFC" value="8259" />
        <seriesInfo name="DOI" value="10.17487/RFC8259" />
      </reference>
      <reference anchor="RFC3339" target="https://www.rfc-editor.org/info/rfc3339">
        <front>
          <title>Date and Time on the Internet: Timestamps</title>
          <author fullname="G. Klyne" initials="G." surname="Klyne" />
          <author fullname="C. Newman" initials="C." surname="Newman" />
          <date month="July" year="2002" />
        </front>
        <seriesInfo name="RFC" value="3339" />
        <seriesInfo name="DOI" value="10.17487/RFC3339" />
      </reference>
      <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446">
        <front>
          <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
          <author fullname="E. Rescorla" initials="E." surname="Rescorla" />
          <date month="August" year="2018" />
        </front>
        <seriesInfo name="RFC" value="8446" />
        <seriesInfo name="DOI" value="10.17487/RFC8446" />
      </reference>
    </references>
    <references>
      <name>Informative References</name>
      <reference anchor="RFC8641" target="https://www.rfc-editor.org/info/rfc8641">
        <front>
          <title>Subscription to YANG Notifications for Datastore Updates</title>
          <author fullname="A. Clemm" initials="A." surname="Clemm" />
          <author fullname="E. Voit" initials="E." surname="Voit" />
          <date month="September" year="2019" />
        </front>
        <seriesInfo name="RFC" value="8641" />
        <seriesInfo name="DOI" value="10.17487/RFC8641" />
      </reference>
      <reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7950">
        <front>
          <title>The YANG 1.1 Data Modeling Language</title>
          <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund" />
          <date month="August" year="2016" />
        </front>
        <seriesInfo name="RFC" value="7950" />
        <seriesInfo name="DOI" value="10.17487/RFC7950" />
      </reference>
      <reference anchor="I-D.zhangb-cats-service-metrics-op">
        <front>
          <title>Computing Service Metrics Operation and Joint Service Selection under CATS</title>
          <author initials="B." surname="Zhang" fullname="Bin Zhang" />
          <author initials="Y." surname="Dai" fullname="Yina Dai" />
          <author initials="Z." surname="Du" fullname="Zongpeng Du" />
          <author initials="G." surname="Zeng" fullname="Guanming Zeng" />
          <author initials="C." surname="Miao" fullname="Chuanyang Miao" />
          <date year="2026" month="September" day="14" />
        </front>
        <seriesInfo name="Internet-Draft" value="draft-zhangb-cats-service-metrics-op-05" />
        <format type="TXT" target="https://www.ietf.org/archive/id/draft-zhangb-cats-service-metrics-op-05.txt" />
      </reference>
      <reference anchor="GNMI" target="https://github.com/openconfig/reference/blob/master/rpc/gnmi/gnmi-specification.md">
        <front>
          <title>gRPC Network Management Interface (gNMI) Specification</title>
          <author>
            <organization>OpenConfig</organization>
          </author>
          <date year="2026" month="March" day="5" />
        </front>
        <seriesInfo name="Version" value="0.11.0" />
      </reference>
      <reference anchor="RFC7951" target="https://www.rfc-editor.org/info/rfc7951">
        <front>
          <title>JSON Encoding of Data Modeled with YANG</title>
          <author fullname="L. Lhotka" initials="L." surname="Lhotka" />
          <date month="August" year="2016" />
        </front>
        <seriesInfo name="RFC" value="7951" />
        <seriesInfo name="DOI" value="10.17487/RFC7951" />
      </reference>
      <reference anchor="RFC8040" target="https://www.rfc-editor.org/info/rfc8040">
        <front>
          <title>RESTCONF Protocol</title>
          <author fullname="A. Bierman" initials="A." surname="Bierman" />
          <author fullname="M. Bjorklund" initials="M." surname="Bjorklund" />
          <author fullname="K. Watsen" initials="K." surname="Watsen" />
          <date month="January" year="2017" />
        </front>
        <seriesInfo name="RFC" value="8040" />
        <seriesInfo name="DOI" value="10.17487/RFC8040" />
      </reference>
      <reference anchor="RFC8650" target="https://www.rfc-editor.org/info/rfc8650">
        <front>
          <title>Dynamic Subscription to YANG Events and Datastores over RESTCONF</title>
          <author fullname="E. Voit" initials="E." surname="Voit" />
          <author fullname="R. Rahman" initials="R." surname="Rahman" />
          <author fullname="E. Nilsen-Nygaard" initials="E." surname="Nilsen-Nygaard" />
          <author fullname="A. Clemm" initials="A." surname="Clemm" />
          <author fullname="A. Bierman" initials="A." surname="Bierman" />
          <date month="November" year="2019" />
        </front>
        <seriesInfo name="RFC" value="8650" />
        <seriesInfo name="DOI" value="10.17487/RFC8650" />
      </reference>
    </references>
    <section anchor="local-examples">
      <name>Local Metric Production (Informative)</name>
      <t>For two independent service instances with budgets of ten requests and active counts of six and seven, the aggregate GAS is four plus three, or seven. Shared resources limit that sum; a pool with four unused allocations can support at most four additional requests. A processing-time estimate uses compatible requests and the stated measurement window.</t>
    </section>
    <section anchor="yang-model">
      <name>Shared Snapshot YANG Model (Informative)</name>
      <t>One shared snapshot YANG model can describe the payloads for FULL, DELTA, WITHDRAW, receiver descriptors, and publication results <xref target="RFC7950" />. Both components can reuse its scope, version, timestamp, and metric-entry definitions. Model-driven tooling can generate data bindings and serializers; the application supplies observations, context tokens, and accepted versions.</t>
      <table>
        <name>Reuse of the shared model</name>
        <thead>
          <tr>
            <th>Message</th>
            <th>Shared definitions and message-specific data</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td>FULL</td>
            <td>Common envelope and complete collection of metric entries.</td>
          </tr>
          <tr>
            <td>DELTA</td>
            <td>Same envelope and entries, plus base-revision and remove.</td>
          </tr>
          <tr>
            <td>WITHDRAW</td>
            <td>Same envelope; entries, base-revision, and remove are absent.</td>
          </tr>
          <tr>
            <td>Receiver descriptor</td>
            <td>Common scope, profile, context, and version types; capabilities, limits, and state.</td>
          </tr>
          <tr>
            <td>Publication result</td>
            <td>Common context and version types; result and state.</td>
          </tr>
        </tbody>
      </table>
      <t>A serializer uses the exact JSON field names and kind-specific presence rules in the main body. If metric entries are represented as a YANG list keyed by metric-key, the adapter produces the entries object keyed by those values. The profile determines each value's JSON type. Shared RPC input/output groupings can cover descriptor retrieval and publication results as well as publications.</t>
      <t>RFC 7951 encoding of YANG data introduces namespace and list rules <xref target="RFC7951" />. The HTTPS binding here uses its own application/json envelope, so a model-based adapter maps those representations explicitly, including decimal strings for uint64 values and null current versions in EMPTY state. This appendix supplies implementation guidance, not a normative YANG module or a NETCONF/gNMI binding.</t>
      <t>YANG-Push and gNMI provide existing subscription mechanisms <xref target="RFC8641" />
        <xref target="GNMI" />. A future binding can reuse the common payload definitions while specifying subscription reset, atomic scope, and application acknowledgments.</t>
    </section>
    <section anchor="ack">
      <name>Acknowledgments</name>
      <t>The authors thank the CATS working group for its feedback.</t>
    </section>
  </back>
</rfc>
