IETF Internet-Drafts & RFCs — Daily Digest

The CATS framework brings computing-related information into traffic-steering decisions, but existing work does not fully address whether a metric is still suitable at the point of consumption. This draft defines operational semantics for CATS metrics: Freshness, Operational acceptability, and Assurance exposure. These describe whether a metric stays temporally aligned with the underlying condition, whether it remains usable for steering, and whether degraded consumption is visible to management or OAM. It explains how the semantics apply across centralized, distributed, and hybrid deployments, including mixed metric sources, aiming for a consistent basis for interpreting metric usability without adding a new metric level or mandating one derivation method.

Several in-progress YANG modules across IETF working groups define counters, gauges, and other measured values that a remote collector compares, sums, or averages, either against a node's own history or across nodes. YANG (RFC 7950) has no first-class, machine-checkable way to state the domain within which two occurrences of such a value are comparable, so today this is decided in prose, inconsistently or not at all. This document defines a YANG extension statement, csc:comparability-scope, a four-value scope lattice, and a compatibility rule so a schema-aware tool can statically detect an illegal aggregation across incomparable scopes rather than discovering it at a collector.

RFC 8584 defines Highest Random Weight (HRW) as the Designated Forwarder election algorithm in EVPN and names the Consistent Hashing family as addressing the same mapping problem before explicitly declining to evaluate it. A later draft (evpn-per-mcast-flow-df-election) introduces a scope transition from per-(ES,VLAN) to per-(ES,VLAN,S,G) election, exactly the key-space-resizing event Consistent Hashing was designed to bound churn for. This document supplies the applicability analysis RFC 8584 declined to make: it defines a DF-churn metric, states HRW's and Consistent Hashing's theoretical guarantees, and sets out an evaluation methodology using bounded-load Consistent Hashing as the comparison point, noting multicast group popularity is highly non-uniform in deployed networks.

YANG-Push version 2 assigns each publisher a monotonically increasing sequence number so a receiver can detect loss and reordering, but two issues remain unresolved: counter wraparound behavior and comparing sequence numbers across multiple publishers. This document examines causal-ordering solutions drawn from distributed systems and deployed streaming platforms, then proposes adopting a Hybrid Logical Clock to address both issues by design rather than by expanding the counter. The goal is a receiver able to reason about ordering consistently even across several publishers.

EVPN MAC Mobility uses a per-MAC sequence number so PEs agree on the most recent location of a moving host, and a related draft extends this to cross-data-center moves via gateways, keeping two independent counters per host (intra-DC and inter-DC). What that document does not specify is what a gateway does if it fails after locally resetting its intra-DC counter to zero but before propagating that fact; no crash-recovery text exists. This draft shows the gap is a special case of a Last-Writer-Wins Register, a member of the Conflict-Free Replicated Data Type (CRDT) family, and proposes modeling the per-gateway mobility sequence state that way so a mid-reset crash is recovered through the data type's algebra rather than a separately specified procedure.

This document specifies the Proof of Sovereign Integrity (PSI) Protocol, version 1.2, a cryptographic framework letting organizations prove compliance with AI regulations (including the EU AI Act 2024/1689, NIST AI RMF, UK AI Safety Institute guidelines, and equivalents) without disclosing proprietary model architectures, training data, or inference logic. PSI combines SHA-256 hash-chained audit trails, Ed25519 digital signatures, Merkle inclusion proofs, Groth16-compatible zero-knowledge commitments over BN128 fields, and a 3-node Multi-Party Computation consensus with 2/3 threshold verification. This revision documents a deployed public reference implementation and adds optional post-quantum signature profiles and Bitcoin timestamp anchoring.

Authorization artifacts can provide signed evidence of a permission, and receipts can record that it was exercised, but none of them necessarily tells an affected person or organization where the authorization can be contested, which procedure applies, whether a filing changes execution state, or who chose the forum. This draft defines a transport-independent Contestability Binding for authorized agent actions, committing an authorization to a versioned Contestation Parameters Object identifying forum, submission mechanism, standing policy, procedure, time bounds, declared effect policy, and selection evidence. A deterministic verifier validates the binding, classifies pre-execution verification claims, and reports forum-selection provenance as unilateral, multiparty, externally selected, or indeterminate. It makes contestation parameters identifiable and verifiable while resisting post-action substitution, without deciding standing, remedies, or legal enforceability.

This document specifies a compact HTTP API for administering an OpenID Federation node. The interface manages the operator-controlled inputs from which a node produces the Entity Configurations, Subordinate Statements, Trust Marks, and Federation Entity Keys defined by OpenID Federation 1.1. It does not replace the public federation protocol; it is the management plane operators and control-plane software use to configure what that protocol publishes. The design is document-oriented: operators read and write the same JSON objects OpenID Federation already defines rather than many per-claim endpoints, with five resources covering node identity, Federation Entity Keys, the node's Entity Configuration, Immediate Subordinates, and Trust Mark issuance.

This document specifies RCOAP, a compact, zero-round-trip, link-layer-agnostic object-security mechanism for highly constrained devices that transmit infrequently. RCOAP is a targeted delta over OSCORE (RFC 8613): instead of a single long-lived Sender Key, it derives a fresh symmetric key for every message via a one-way hash ratchet, bounding the impact of physical device capture to future messages only, at the cost of a modest per-message size increase and the loss of future secrecy. It is scoped to a narrow niche between OSCORE and EDHOC (RFC 9528), for devices where even EDHOC's one-time handshake is disproportionate to their message rate or compute budget. As a first individual submission, it requests feedback from the LAKE and CoRE working groups.

Modern telecom typically links knowledge of a routable identifier with the practical ability to attempt contact, so a number, SIP URI, messaging handle, or relay address can remain a reusable reachability path after its original purpose has ended. Existing controls (masked numbers, STIR/SHAKEN, OAuth) each address distinct problems but do not turn reachability into purpose-limited, revocable, consumable communication authority. This draft introduces a Capability-Validated Inbound Descriptor (CVID) and a query-scoped model where a request is a Candidate Act that stays non-effective until authorization is established, with blocked-path and absent-path deployment profiles. It motivates the model for IMT-2030/6G machine-speed communications and argues early rejection can reduce signaling, fraud-analysis load, and energy consumption.

TCP today maintains ordinary sessions (SES-O) exchanging ordinary segments (SEG-O), each of which can carry up to 40 octets of options. Future applications may need more; for example, a 36-byte TCP Authentication Option (TCP-AO) leaves little room for other required options. This document describes an experiment introducing upgraded sessions (SES-U) and upgraded segments (SEG-U), where each SEG-U can accommodate up to 1,016 octets of Individual Options, substantially expanding the option space available to TCP.

RFC 5926 defines the list of cryptographic algorithms usable with TCP-AO. This document expands that list by adding two Message Authentication Code algorithms, HMAC-SHA256 and KMAC256, and for each a corresponding Key Derivation Function. These MAC algorithms produce 256-bit (32-byte) MACs; when encoded in TCP-AO, a 32-byte MAC consumes 36 of the 40 bytes available for TCP options, which motivates the companion work on extended TCP option space.

RFC 5926 defines the list of cryptographic algorithms usable with TCP-AO. This working-group document expands that list by adding two MAC algorithms, HMAC-SHA256-128 and KMAC256-128, and for each a corresponding Key Derivation Function. These algorithms produce 128-bit (16-byte) MACs; when encoded in TCP-AO, a 16-byte MAC consumes 20 of the 40 bytes available for TCP options, leaving more room for other options than the 256-bit variants.

The Behavioral State Protocol (BEST) defines a discovery-first, behaviour-oriented interaction surface for domain services: the commands a service accepts, the events it publishes, and optionally the queries it answers and the multi-step recipes (workflows) it publishes. Services self-describe through a manifest at the well-known URI /.well-known/best, and messages use a conformant profile of the CloudEvents 1.0 envelope described by JSON Schema. BEST deliberately specifies only the interaction surface, never a service's internal architecture, storage, or execution model, so independent implementations across any runtime, language, or transport can interoperate without bespoke integration.

This draft presents technical details of CVE-2026-33697 and EUVD-2026-16488, demonstrating how intra-handshake attestation fails in practice, even without physical access. The author argues that because continuous attestation is generally required anyway, intra-handshake attestation adds unnecessary complexity. The results are supported by formal analysis using ProVerif, released under Apache-2.0 for reproducibility, and the draft states the findings have been acknowledged by relevant stakeholders.

This document specifies General-Purpose Compression via Mathematical Functions (GCMF), a lossless compression format that represents sequences of data using mathematical functions and their parameters rather than storing every value explicitly. It defines the GCMF data format, the function types, the encoding rules, the decoding procedure, and the interoperability requirements needed for independent implementations to exchange compressed sequences.

BGP routing security is critical to the stability and reliability of Internet services. Existing mechanisms such as Route Origin Authorization (ROA) and Autonomous System Provider Authorization (ASPA) mitigate route origin hijacking, path hijacking, and route leaks in general scenarios, but large ISPs managing multiple ASes remain vulnerable: crafted routes can bypass ROA and ASPA validation and hijack traffic within or between large ISPs. This document defines a region-based authorization and verification framework for multi-AS ISPs to prevent intra-ISP and inter-ISP traffic hijacking.

CBOR (RFC 8949) is a data format whose design goals include very small code size, fairly small message size, and extensibility without version negotiation. One point of extensibility is the definition of CBOR tags; RFC 7049 defined a basic set of 16 tags plus a registry, and since then roughly 250 tag and tag-range definitions have been added. This document provides a roadmap to a large subset of those definitions, pointing to the IETF standards documents that specify them where they exist and otherwise collecting specification information from the registrants. It is intended to become a reference document for the IANA registrations of these CBOR tags.

This document describes the changes between Unicode 12.0.0 and Unicode 18.0.0 in the context of IDNA2008. Additions and changes in the Unicode Standard affect the values the IDNA2008 algorithm produces, and the review assigns the derived property value UNDER REVIEW to certain code points, added as exceptions for backward compatibility. It provides the tables IANA needs to make its database consistent with Unicode 18.0.0. The document relies on pre-release data because Unicode 18.0.0 had not yet been published at the time of writing, with all values computed directly from the Unicode Character Database using the RFC 5892 Section 3 algorithm.

ASPA defines an RPKI-based method to validate the AS_PATH of BGP routes using a global Customer-to-Provider relationship model. In commercial routing, however, two ASes may hold different business relationships across regions or interconnection points, for example Customer-to-Provider in one region but Peer-to-Peer in another. Such regionalized or hybrid relationships can produce incorrect ASPA results, such as a false Valid attestation for a route propagated over a P2P link. This document analyzes the vulnerabilities caused by regionalized AS-relationships and proposes mechanisms to incorporate regional granularity into ASPA objects and verification procedures.

In an SRv6 network, each SRv6 segment endpoint has at least one SRv6 Locator, and other nodes steer traffic to it via the locator routes. This document describes a method for an SRv6 endpoint, such as a host or customer provider edge (CPE), to advertise its SRv6 locator to a neighboring SRv6-aware router using extensions to the IPv6 Neighbor Discovery (ND) protocol. This removes the need to run a full routing protocol stack on simple endpoints, facilitating SRv6 deployment in controlled, trusted domains such as data centers and managed access networks.

In situ OAM (IOAM) records and collects operational and telemetry information, using the IOAM Trace Option to add IOAM data fields to in-flight packets, while the Alternate-Marking method measures performance metrics on live traffic such as packet loss, delay, and jitter. This document extends the IOAM Trace Option to incorporate the Alternate-Marking method, augmenting IOAM's performance-measurement capabilities by combining trace-based data collection with alternate-marking measurement.

In situ OAM (IOAM) records and collects operational and telemetry information; passport-based IOAM pushes each node's telemetry into the data packets, while postcard-based IOAM exports it directly without adding it to in-flight packets. The Alternate-Marking method measures performance metrics on live traffic such as packet loss, delay, and jitter. This document extends the IOAM Direct Export (DEX) Option-Type to integrate the Alternate-Marking method, augmenting IOAM's performance measurement in the postcard/direct-export model.

The abstract for this draft could not be retrieved from the fast archive source on this run (HTTP 404, likely because this revision's HTML was not yet mirrored at www.ietf.org/archive/id). By its name alone (draft-jovancevic-saip), the specific subject cannot be reliably inferred from the acronym, so no description is asserted here to avoid inventing details. The document is an individual submission and appears to be part of a related family alongside draft-jovancevic-vicdm and draft-jovancevic-vdac. It should be grounded from its official Abstract on the next run.

The abstract for this draft could not be retrieved from the fast archive source on this run (HTTP 404, likely because this revision's HTML was not yet mirrored at www.ietf.org/archive/id). By its name alone (draft-jovancevic-vicdm), the specific subject cannot be reliably inferred from the acronym, so no description is asserted here to avoid inventing details. The document is an individual submission and appears to be part of a related family alongside draft-jovancevic-saip and draft-jovancevic-vdac. It should be grounded from its official Abstract on the next run.

The abstract for this draft could not be retrieved from the fast archive source on this run (HTTP 404, likely because this revision's HTML was not yet mirrored at www.ietf.org/archive/id). By its name alone (draft-jovancevic-vdac), the specific subject cannot be reliably inferred from the acronym, so no description is asserted here to avoid inventing details. The document is an individual submission and appears to be part of a related family alongside draft-jovancevic-saip and draft-jovancevic-vicdm. It should be grounded from its official Abstract on the next run.

This document proposes an execution-finality architecture for how third-party AI assistants can access device functions while preserving platform security and user control under EU regulations, on the principle that interoperability should grant participation, not uncontrolled execution authority. It separates request capability from execution authority: AI requests stay non-effective until protected infrastructure validates requester, resource, destination, user intent, freshness, revocation status, and policy, after which narrowly scoped, non-bearer execution authority is created. At the Finality Sink, where actions become externally effective, the system independently verifies the real operation matches what was authorized, failing closed on any mismatch, replay, substitution, expiry, or revocation, so platforms keep privacy, security, and final-effect controls.

This document defines a SCITT statement profile for recording what an AI agent did: the Agent Action Capsule. A Capsule is a digest-committed record of one agent action carrying its verdict-level disposition (executed, blocked, denied, errored, timed out), the deterministic constraints evaluated, the committed effect together with a confirmed-effect binding distinguishing a dispatched attempt from an observed result, and an honest human-in-the-loop flag. Capsules are identified independently of signing and may be authenticated by one or more COSE_Sign1 Producer Envelopes, and a Capsule ID can be made transparent via a SCITT Transparency Service. A Capsule is recorded on every verdict, including refusals, so a blocked or denied Capsule is auditor-grade evidence that a gate worked.

Using a distinct holder-binding key for each Credential improves unlinkability, but generating and storing many keys in a Wallet secure area can be expensive or impossible. This document defines a way to derive unlinkable P-256 Credential keys from one protected parent key while retaining the parent's key-protection properties. It specifies this as an extension to OpenID for Verifiable Credential Issuance (OpenID4VCI), allowing the Issuer to derive each child public key while only the Wallet can use the corresponding child private key.

Autonomous AI agents are evolving from interactive assistants into networked software workloads that discover services, invoke tools, delegate authority, transact, communicate with other agents, and act asynchronously on behalf of humans and organizations. Existing Internet protocols provide strong foundations, but agent autonomy, dynamic delegation, machine-speed execution, long model-processing intervals, and cross-domain interaction create requirements spanning multiple protocol families. This document describes architectural requirements across naming and discovery, HTTP, authentication, authorization and delegation, TLS and workload identity, transport and connection continuity, asynchronous messaging, capability and intent-based resolution, payments, provenance, auditability, revocation, security, and privacy. It favors profiling and extending existing protocols over a monolithic new agent protocol and calls for IETF-wide architectural coordination.

This document defines a trust model for agent-to-agent (A2A) interactions in multi-agent AI systems. It specifies how agents obtain verifiable identities via CA-signed templates, how spawn chains are cryptographically established and validated, how dynamic policies are governed under a dual-signature model, and how cross-organizational agent interactions are explicitly authorized. The model applies existing PKI primitives (X.509, CRL, CSR) and established identity patterns (OAuth 2.0, On-Behalf-Of) to agent provenance. It deliberately does not address agent-to-resource access control, human-in-the-loop orchestration, or agent behavior, leaving those to the resource enforcement and orchestration layers.

This working-group document defines how an ACME Server may offer a selection of different certificate profiles to ACME Clients, and how those clients indicate which profile they want. It extends the ACME protocol so that certificate issuance can be tailored to distinct profiles advertised by the server, allowing clients to select among them during the ACME order flow.

This document specifies encapsulations for the Simple Two-Way Active Measurement Protocol (STAMP, RFC 8762) and its optional extensions (RFC 8972) in MPLS networks. It defines the encapsulation of STAMP test packets for point-to-point Label Switched Paths and point-to-point single-segment Pseudowires, with or without an IP/UDP header, so the test packets experience the same forwarding and Equal-Cost Multi-Path behavior as the data traffic being measured, and defines two new MPLS Generic Associated Channel (G-ACh) types. It updates RFC 8972 by updating the STAMP Session Identifier for LSPs and PWs.

This document defines the Cedulon Protocol, an audit layer for agent-to-agent commerce. Payment rails such as HTTP 402 flows (x402) and mandate protocols (AP2) already move value; Cedulon adds mechanisms ensuring authorized spending through policy enforcement and cryptographic receipts. Key components include Trade Manifests signed before payment, a default-deny Policy Decision Point, Spend Receipts with COSE/CWT encoding after gated transactions, epoch checkpoints, and rail-extract reconciliation that verifies settlements match receipts and vice versa. This revision establishes trust-root requirements (a signed object cannot be verified against a key it itself carries) and defines Dispute Evidence Bundles and optional SCITT anchoring. Cedulon complements rather than replaces existing payment protocols.