IETF Internet-Drafts & RFCs — Daily Digest

Defines the use of an X.509 certificate issued under a PKI as a means to request an OAuth 2.0 access token and to authenticate a client, profiling the OAuth Assertion Framework in a manner analogous to the JWT Bearer and SAML 2.0 Bearer profiles. It is motivated by workload-identity systems such as SPIFFE/SPIRE and Athenz that already issue short-lived X.509 certificates for mutual TLS and benefit from reusing them with OAuth. Unlike a bare bearer credential, the profile requires proof of possession of the private key on every use, so a copy of the (non-secret) certificate alone can never obtain a grant or authenticate a client.

Defines the Cedulon Protocol, an audit layer for agent-to-agent commerce that sits above payment rails such as x402 (HTTP 402) and mandate protocols (AP2). It specifies a signed Trade Manifest, a default-deny Policy Decision Point, a COSE/CWT Spend Receipt, epoch checkpoints, and rail-extract reconciliation showing that no settlement lacks a receipt and no receipt is absent from the extract. Checkpoints are profiled as Signed Statements carrying a suppression/equivocation guarantee, canonical encodings and hash inputs are fully specified, and a Dispute Evidence Bundle plus optional SCITT anchoring are defined. This revision requires every returned structure to name the account, rail and window it was computed over. Cedulon complements rather than replaces x402 and AP2.

Presents technical evidence, tied to CVE-2026-33697 and EUVD-2026-16488, arguing that intra-handshake attestation fails in practice even without physical access to the device. It further argues that because continuous attestation is generally required anyway, intra-handshake attestation adds unnecessary complexity. The results are backed by formal analysis using the ProVerif tool, with artifacts released under Apache-2.0 for reproducibility, and the authors state the findings have been acknowledged by relevant stakeholders.

Defines version 2.0 of JSCalendar, a data model and JSON representation of calendar data for storage and exchange in calendaring and scheduling environments. It obsoletes RFC 8984 (JSCalendar 1.0) and aims to improve interoperability with existing iCalendar-based systems. Version 2.0 also aligns its definitions with JSContact, including the IANA registry policy, validation requirements, and versioning scheme.

Specifies how to convert calendaring information between the JSCalendar and iCalendar data formats, covering every JSCalendar and iCalendar element registered at IANA at time of publication. It defines conversion rules for elements common to both formats and for handling arbitrary or unknown elements in either direction. The document updates RFC 5545 (iCalendar) and the JSCalendar-bis specification by defining new properties and parameters needed for lossless conversion.

Defines the post-quantum ML-KEM-512, ML-KEM-768, and ML-KEM-1024 key-encapsulation mechanisms as TLS NamedGroups and registers the corresponding IANA values in the TLS Supported Groups registry. The named groups are for use in TLS 1.3 to achieve post-quantum key establishment. This provides standalone PQ (non-hybrid) options for TLS key exchange.

Obsoletes RFC 8007 and describes the part of the CDN Interconnection (CDNI) Control interface that lets one CDN trigger activity in an interconnected CDN configured to deliver content on its behalf. An upstream CDN may use the mechanism to ask a downstream CDN to preposition, invalidate, and/or purge metadata and content. The upstream CDN may also monitor the status of the activity it has triggered downstream.

Explores when and how Merkle Tree Certificates (MTC), originally defined for the Web PKI, can be applied in whole or in part to other use cases. It surveys deployment scenarios beyond the WebPKI context. Some of these use cases may offer benefits for private PKI usage.

Addresses a gap in CBOR diagnostic notation (EDN), widely used to write CBOR examples for humans, where nested maps often draw their labels from different specifications. While the existing e'' application extension can import constant values from a CDDL model, it cannot automatically select the correct kind of map based on position within nested maps. The document captures ideas first discussed at the CBOR WG interim on 2025-06-25 and demonstrates design alternatives. It is explicitly not yet ready for adoption.

Addresses cases where a Certification Authority requires a certificate signing request to include verifiable evidence of policy compliance, such as proof that the private key is protected by an HSM or is non-exportable, a process referred to as remote attestation. It defines ASN.1 structures that can carry attestation data within PKCS#10 and CRMF certificate-request messages. Both standardized and existing proprietary attestation formats are supported.

Analyzes the structural vulnerabilities of ASRank, a widely used algorithm that infers Autonomous System business relationships from BGP routing data and plays a key role in security research and BGP operation. It shows ASRank's inference is highly sensitive to small changes in input, creating risk that results could be manipulated undetected under adversarial conditions. The draft outlines ASRank's design, identifies the structural weaknesses, analyzes a minimal manipulation example, and discusses security implications and possible countermeasures.

Specifies encapsulations for the Simple Two-Way Active Measurement Protocol (STAMP, RFC 8762) and its RFC 8972 extensions in MPLS networks. It defines how STAMP test packets are carried over point-to-point LSPs and single-segment pseudowires, with or without an IP/UDP header, so test traffic follows the same forwarding and ECMP behavior as the measured data, and it defines two new MPLS G-ACh types. The document updates RFC 8762 for TTL and IPv6 Hop Limit handling and RFC 8972 for the STAMP Session Identifier, and states requirements for IPv6 STAMP in unauthenticated mode with UDP zero-checksum that deviate from RFC 6936.

Describes an optional algorithm for processing NS resource-record sets during iterative DNS resolution, with its benefits and considerations. When following a referral to a child zone, resolvers should explicitly query the authoritative NS RRset at the child apex and cache it in preference to the parent-side NS RRset, and should similarly re-query the associated A/AAAA address records rather than trusting additional-section glue of lower trustworthiness. Resolvers should also periodically revalidate the delegation by re-querying the parent at the expiration of the shortest TTL among the parent NS, DS, and child NS RRsets.

By its name, this individual submission appears to describe a mechanism or protocol related to "video surfing" — probably navigation, browsing, or streaming of video content. The official abstract page was not reachable on this run (404), so this description is approximate and based on the draft name alone; specific scope, mechanisms and terminology are not confirmed here. It will be grounded from its abstract on a future run once the archived page is available.

Specifies vaara.receipt/v1, a signed, independently recomputable record that binds a decision about an autonomous action to the evidence it was based on, optionally anchored to external timestamps. The format is canonicalized with the JSON Canonicalization Scheme so any third party can recompute digests and verify the signature without the issuer, and a decision plus its execution receipt form one recomputable pair via a back link. Trust is root-agnostic: the same record verifies with or without a hardware TEE and is re-expressible as an IETF RATS Entity Attestation Result. Downstream profiles pin a version and add only their own evidence schema; the format is described as already deployed with public conformance vectors.

By its name, this individual submission concerns Bidirectional Forwarding Detection (BFD) path consistency over Segment Routing — probably ensuring that BFD sessions follow and verify the same forward and reverse paths as the SR-routed data traffic they monitor. The official abstract page was not reachable on this run (404), so this description is approximate and based on the draft name alone; exact mechanisms and encodings are not confirmed here. It will be grounded from its abstract on a future run.

Specifies a profile for delegating authorization to automated agents across administrative domains. It defines an HTTP Agent-Delegation header field carrying a chain of attenuated delegation links, where each link narrows scope, tightens or holds a set of floor conditions, and shortens or holds its parent's expiry. A verifier checks every link in the chain, not just the last, and rejects the chain if any link violates attenuation. The profile is deliberately agnostic to credential format and to the kind of entity issuing floor attestations, specifying required properties rather than a specific encoding, and it composes with existing agent credential and posture work.

Specifies the In-Network Inference Protocol (INIP), a lightweight protocol for high-speed in-network inference inside data-center networks. It leverages data-plane devices such as switches and SmartNICs to run inference tasks without compromising core network functions, using a dual-layer design in which the control plane manages models and scheduling while the data plane performs minimal, efficient inference. The architecture applies centralized control-plane adaptation and scheduling with minimal data-plane execution, plus CDN-inspired model distribution, model-popularity tracking, and automatic fallback for reliable service.

Motivated by the observation that ANIMA Intent enables goal-oriented control within an Autonomic Domain, but emerging services such as AI inference need a common, interoperable way to express service-level objectives and constraints spanning network, compute, and storage rather than connection-centric descriptions. The document defines Service Intent for Autonomic Networks. It specifies a structured semantic model and a concise format with identification, scope, versioning, and lifecycle semantics.

Defines Agent Identity and Discovery (AID), which answers, for a given domain, where the agent is and which protocol a client should speak. A client queries a DNS TXT record at the well-known subdomain _agent.<domain> to learn the service endpoint URI, protocol token, authentication hint, and optional metadata. The draft specifies the AID v2 (aid2) record format, the client discovery algorithm, exact-host lookup rules, an Ed25519 HTTP Message Signatures endpoint-proof (PKA) handshake, security requirements, and IANA registrations; the legacy aid1 format is retained for migration. AID is intentionally small, leaving post-discovery communication to protocols such as MCP or A2A.

Presents a security- and privacy-preserving execution-finality architecture for third-party AI interoperability under the EU Digital Markets Act. It separates AI-generated requests from the authority to execute them, keeping consequential device actions under bounded, verifiable platform control: a requested operation stays non-effective until protected infrastructure validates the requester, resource, destination, user authorization, purpose, scope, freshness, revocation state, runtime conditions, and policy, then mints narrowly scoped, non-bearer authority bound to the specific act. At the Finality Sink the system re-verifies that the actual operation matches the validated act and that authority is current and unused. It targets prompt injection, confused-deputy behavior, replay, token theft, parameter substitution, scope escalation, and stale authorization.

Addresses securing CoAP group communication with Group OSCORE, where at deployment time devices may not know which security groups to join, the responsible Group Managers, or the information needed to join. It defines how a CoAP endpoint uses resource descriptions and links registered at the CoRE Resource Directory to discover security groups and obtain the information needed to join them through their Group Managers. A single security group can protect multiple application groups, which are separately announced in the Resource Directory, and the approach is consistent with (but not limited to) ACE-based joining.

Notes that BCP 18 (RFC 2277) has guided handling of character-shaped data in IETF specifications for over 25 years and that RFC 5198 defined Network Unicode conventions while also serving the legacy Telnet protocol. It defines "Modern Network Unicode" (MNU), a form of RFC 5198 Network Unicode for specifications that require exchanging plain text over networks. MNU comes in a one-dimensional variant useful for identifiers and labels without a line structure, and a two-dimensional variant for text composed of a sequence of lines.

Updates the Authentication and Authorization for Constrained Environments (ACE) framework by defining a method to enforce bidirectional access control using a single access token. This allows both parties in an exchange to be authorized through one token rather than separate credentials in each direction. The document updates RFC 9200.

Observes that CDDL, defined by RFC 8610/9682 with extensions in RFC 9165 and RFC 9741, has been extended only through its single control-operator extension point, which is insufficient as CDDL is used in larger projects needing features that cannot be mapped there. The document defines a way to add a module structure to CDDL. The mechanism is designed to be both backward- and forward-compatible with existing CDDL.

Defines a specific realization of a proxy for scenarios that use CoAP group communication. Such a proxy takes a single request a client sends, typically over unicast, and distributes it to a group of servers, over UDP/IP multicast as the default transport. It then collects the individual server responses and relays them back to the client with embedded addressing information so the client can distinguish each response and its origin server. The document updates RFC 7252 regarding proxy caching of response messages.

Describes prominent scenarios in which enterprise systems and networks maintaining digital assets need to securely transfer assets or data to one another. It motivates the Secure Asset Transfer Protocol (SATP) work by collecting representative use cases. The document frames the requirements that arise from these cross-system asset-transfer needs.

Serves as a "freezer" collecting nice-to-have CDDL features that did not make it into RFC 8610 or the specifications exercising its extension points (such as RFC 9165), kept aside to complete those documents in a timely manner. Significant parts of this draft have now moved to the CDDL 2.0 project described in draft-bormann-cbor-cddl-2-draft. The remaining items here are not directly related to the CDDL 2.0 effort.

Defines two formally provable consequences of retiring the IPv4 stack in a dual-stack environment: complete elimination of attacks attributable to the IPv4 protocol, and at least a 50% reduction in the count of concurrently exposed network-layer attack surfaces. Both results are presented as definitional and structural derivations, independent of empirical attack-volume measurement. The document proposes standard terminology for these effects and states explicitly the boundary between what is proven and what remains an open empirical question.

By its name and the tsvwg (Transport Area Working Group) context, this individual submission ("camp") probably concerns a transport-layer mechanism — possibly congestion, admission, or multipath-related, though the acronym is not expanded here. The official abstract page was not reachable on this run (404), so this description is approximate and based on the draft name alone; scope, mechanisms and terminology are not confirmed. It will be grounded from its abstract on a future run.

Defines a YANG data model to configure and manage IPv6 Neighbor Discovery and related functions. Covered functions include IPv6 address resolution, the redirect function, proxy Neighbor Advertisement, Neighbor Unreachability Detection (NUD), Duplicate Address Detection (DAD), and Enhanced Duplicate Address Detection. The model gives operators a standardized way to manage ND behavior on IPv6 nodes.

Notes that OAuth 2.0 Token Exchange (RFC 8693) defines the moment an authorization server decides whether one party may obtain a token to act as or on behalf of another, but leaves that decision to unspecified policy, a seam inherited by identity chaining, identity assertion grants, and transaction tokens. The document binds these flows to the AuthZEN profile for OAuth 2.0 token issuance. It specifies how a token-exchange request is derived into AuthZEN evaluation requests, how the requesting party's authority is expressed as a decision distinct from the authority being delegated, and what each layered token type contributes to the mapping.

Addresses RFC 9068's recommendation that an authorization server placing group memberships, roles, or entitlements in a JWT access token draw those claims from the SCIM user schema without saying where the server obtains them — today from a directory, database, or vendor hook, effectively asking an authorization question of something that is not the authorization system. It profiles the Resource Search API of the OpenID AuthZEN Authorization API for this purpose, binding each authorization claim to a search and defining how a result set becomes a claim value. Crucially it requires that a search result never influence whether a token is issued or what authority it conveys; it may be used alone or with the companion issuance framework.

Observes that many OAuth 2.0 specifications define a moment at which an authorization server decides whether to issue a token, yet each declares that decision to be out-of-scope local policy, leaving a decision common to every OAuth deployment with no interoperable expression. The document defines a profile for using the OpenID AuthZEN Authorization API to externalize that decision to a Policy Decision Point, specifying how token-issuance inputs map onto AuthZEN's mandatory five-tuple, how a PDP response may shape the issued token, and how a PDP advertises support. The mapping is complete for grants naming a single party (authorization code, client credentials); companion documents cover more structured grant families, token exchange first.

Describes an experimental protocol, the Available Session Recovery Protocol (ASRP), to optimize high-availability network cluster architectures for stateful services such as load balancing and NAT. ASRP defines procedures and message formats for session backup and recovery. Its core innovation is distributing backup of session state to the client or server side rather than within the cluster, which the authors argue provides theoretically unlimited elastic scaling, rapid recovery from multi-point failures, reduced resource redundancy by eliminating centralized backup nodes, and simpler cluster implementation, offering a standardized way to build elastic service clusters.

Specifies the "agent" URI scheme and its associated cryptographic attestation protocol. The scheme defines a transport-agnostic, cryptographically verifiable addressing layer for identifying autonomous software agents. It binds domain ownership via DNS TXT records, enforces instruction integrity, and validates attenuated capability-delegation tokens.

Defines combinations of US NIST ML-KEM in hybrid with the traditional algorithms RSA-OAEP, ECDH, X25519, and X448. These composite combinations are tailored to meet security best practices and regulatory guidelines. Composite ML-KEM applies to any application using X.509 or PKIX data structures that accept ML-KEM but where the operator wants extra protection against breaks or catastrophic bugs in ML-KEM.

Notes that the Robots Exclusion Protocol (RFC 9309) can say which automated clients may fetch content but cannot express purpose (retrieving a page to answer a person differs from copying it for training or acting on the site) and cannot prove who published the policy. It defines the BotCentral Card, one JSON record per domain stating which purposes the owner consents to — "retrieve", "train", and "act" as separate answers — backed by proof of domain control via a DNS TXT record or a /.well-known/botcentral.txt URI. Cards are written to a registry by authenticated publishers and read by any client over HTTP or MCP; clients never write cards, and a card is permission to be found, not a ranking or a training grant.

Formalizes "Agentic Saturation Stridency" (SAS), a measurable system condition defined by the ratio between the arrival rate of unverified agentic traffic over an observation interval and the empirically sustainable admission capacity of the target boundary, addressing high-frequency synthetic traffic from autonomous agents that can force a system to allocate memory or run application logic before an incoming request is eligible. It defines three operational regimes (Subcritical, Critical, Supercritical) and a pre-runtime structural admission architecture called Reality Layer 0 (RL0) that drops unverifiable traffic before protected execution, using bounded-state replay protection, out-of-band key-revocation checks, constant-time crypto, and standard wire encodings, driven by a signed Reality-Token and an Invariant Reality Prism admission predicate.

Defines a YANG data model to configure and manage OSPFv3 Segment Routing over the IPv6 data plane (SRv6). It provides operators a standardized way to provision and monitor OSPFv3 SRv6 features. The model complements existing OSPF and segment-routing YANG work.

Notes that RPC-with-TLS assumes DANE is available where deployed and recommends that a client under an opportunistic-security policy check for a TLSA record before an association, without specifying how. This document supplies the missing details so a TLSA record can authenticate an RPC server with no certification-authority trust anchor provisioned on the client. It updates RFC 9289.

Updates RFC 6211 to correct an error in the definition of the id-aa-CMSAlgorithmProtection ASN.1 object identifier. The document notes that the IANA registry entry has always been correct; the error was only in the RFC text. It is a small, focused correction to the CMS Algorithm Protection attribute definition.

Introduces a subset of STB (STandards of Belarus) cryptographic algorithms and defines their use in TLS 1.3. The document is self-contained: it fully describes the required STB algorithms. It can therefore be used to build STB-compliant TLS 1.3 implementations without referring to the original STB standards.

Defines provider-independent conformance requirements for AID-1. It specifies the execution model for a deterministic, machine-readable test-vector corpus, covering canonicalization, cryptographic, identity-binding, delegation, authorization, temporal, revocation, replay, attestation, provenance, and integration cases. The corpus contains 69 vectors, including six replay cases that are architectural boundary tests — among them R5, which requires AID-1 verification to succeed while a downstream scientific-admissibility decision rejects the same evidence.

Serves as the working document for the CDDL 2.0 effort, gathering the features migrated from the CDDL "freezer" that are directly part of that next-generation CDDL work. It builds on CDDL as defined by RFC 8610 and its extensions to add capabilities that could not be expressed through the original single extension point. (Summary based on the draft's role and companion documents; the archived abstract text was condensed here.)

Defines the Agent Action Decision Protocol (AADP), which separates per-action authorization from an agent's identity and standing capabilities and gives that authorization semantics a stateless permission cannot express: whether a specific proposed action, with specific argument values, may run now given mutable state such as cumulative budgets, live reservations, approval lifecycle, and a kill switch. It defines a two-phase wire contract between a Policy Decision Point and Policy Enforcement Points: verdicts with machine-readable reasons, fail-closed obligations, atomic budget reservation, an approval lifecycle, idempotency, re-derivable evidence, and evaluation invariants — including that an irreversible action is never executed autonomously. The protocol is transport-agnostic and composes with identity-focused agent-security work.

Specifies BGP mechanisms for discovering SD-WAN (Software-Defined WAN) edge-node attributes. These comprise a new tunnel type and associated Sub-TLVs for the BGP Tunnel Encapsulation Attribute. They also include a new Subsequent Address Family Identifier (SAFI) carrying a typed NLRI for advertising SD-WAN underlay tunnel information.

Notes that CDDL (RFC 8610) provides data models for JSON- or CBOR-shaped data, while another popular representation is the CSV file as defined by RFC 4180. The document shows a way to use CDDL to provide a data model for CSV files. This extends CDDL's applicability to tabular comma-separated data.

Notes that the ACME protocol requires a PKCS#10 CSR at the finalization stage, and defines an optional extension letting a client prove possession of a private key directly without constructing a CSR. This addresses cases where CSR-based flows are problematic, such as KEM-only keys that cannot self-sign, constrained devices benefiting from reduced encoding, and issuance models that build certificates from order and profile data. The mechanism adds a popKey field in newOrder and a dedicated pop authorization with a single pop-01 challenge; once all authorizations are valid the server issues without a CSR. The extension is optional and additive, and non-users continue with the standard CSR flow.

By its name and the IVY (network inventory YANG) context, this individual submission probably concerns representing or applying equipment capability information for network inventory management, likely in a YANG-modeled form. The official abstract page was not reachable on this run (404), so this description is approximate and based on the draft name alone; specific data nodes, scope and terminology are not confirmed. It will be grounded from its abstract on a future run.

By its name and the NMOP (Network Management Operations) context, this individual submission probably sets out generalized principles for describing device or service capabilities in network management. The official abstract page was not reachable on this run (404), so this description is approximate and based on the draft name alone; the exact principles, scope and terminology are not confirmed. It will be grounded from its abstract on a future run.

Notes that NFSv4.2 clients commonly cache file data for performance, that applications can sometimes influence this, but that no standardized way lets a server or administrator mark particular file data as not to be cached for performance or correctness. The document introduces a new file-data caching attribute for NFSv4.2; files marked with it are meant to be accessed with client-side data caching suppressed, supporting workloads that need predictable data visibility. It extends NFSv4.2.

Describes the problem of sharing optical impairment information across administrative domains for monitoring in multi-domain all-optical WSONs, where end-to-end services cross domains run by different operators. Monitoring needs visibility into impairments that accumulate across boundaries, yet detailed metrics such as attenuation, noise, nonlinear effects, and filtering penalties can expose sensitive topology, equipment, or utilization data. The document frames the tension between operational visibility and confidentiality and outlines considerations for abstraction, information granularity, and trust relationships among participating operators.

Proposes a generic hybrid signature construction that achieves strong unforgeability under chosen-message attack (SUF-CMA) provided its second (typically post-quantum) component is SUF-CMA secure. Unlike the current composite hybrid approach, it binds the second signature to the concatenation of the message and the first (traditional) signature, so the hybrid stays SUF-CMA even when the first component only offers EUF-CMA. The draft also proposes a non-black-box variant tailored for Fiat-Shamir-based schemes that is SUF-CMA secure as long as only one component is SUF-CMA secure.

Defines a YANG data model for representing, retrieving, and manipulating MPLS-TE network topologies, building on and augmenting existing network and TE packet-topology YANG models. It also defines a collection of common YANG data types and groupings specific to MPLS-TE, intended for import by modules that model MPLS-TE technology-specific configuration and state. The models can also be used for MPLS Transport Profile (MPLS-TP) topologies.

Describes a portable JSON evidence-record format for representing bounded scientific claims, preregistered procedures, admissibility evaluations, provenance artifacts, lifecycle events, and cryptographic integrity metadata. It deliberately keeps these layers separate: implementations can validate structure, integrity, and declared cross-field invariants, but must not infer scientific truth merely from successful serialization, signature verification, or schema validation. The document clarifies that it defines no network transport, establishes no scientific truth, and assigns no decision authority to automated systems.

Describes a zero-configuration protocol for dynamically assigning IPv6 multicast addresses that are unique at the link layer. Applications randomly assign multicast group IDs from a specified range and prevent collisions by using Multicast DNS (mDNS) to publish resource records under a new "eth-addr.arpa" domain. The protocol is stated to satisfy all of the criteria listed in RFC 10019.

Describes a protocol for identifying automated (bot) traffic using HTTP Message Signatures, letting automated HTTP clients cryptographically sign outbound requests so servers can verify their identity with confidence. It defines the Signature-Agent header field for in-band key discovery. It also defines a JWKS-based key-directory format and a well-known URI at which that directory is served.

Defines an extension to the Open Cloud Mesh (OCM) protocol to support federated groups as receiving parties of shares, using Messaging Layer Security (MLS, RFC 9420) as a group-management layer. MLS establishes and rotates a shared group key across federated members and maintains group state, providing both federated group membership and a cryptographically secure way to distribute encryption keys so shared files can optionally be encrypted and decrypted. In effect, MLS in OCM is a vehicle for group management that gives users optional encryption for resources shared with federated groups.

Defines the Open Cloud Mesh Integration Protocol (OCM-IP), specifying how an OCM Server integrates supporting servers — such as SSH/SFTP servers, web application platforms, or standalone WebDAV servers — to do protocol-specific work on its behalf. This lets existing OCM Servers offload protocol interactions or run OCM as a lightweight server handling only discovery, share creation, and token issuance/signing. It defines three integration modes: provisioned (share info pushed over a signed back channel), self-contained (share info embedded in the signed token so the Protocol Server needs no per-share state), and introspected (credentials validated via a token introspection endpoint). The Receiving Server is unaware of OCM-IP.

Defines Open Cloud Mesh (OCM), a server-federation protocol used to notify a receiving party that they have been granted access to some resource, with similarities to authorization flows like OAuth and social protocols like ActivityPub and email. A core use case is a user on one system sharing a resource such as a file with a user on another system without transferring the resource or requiring the recipient to log in to the first system. OCM handles interactions only up to the point where the receiving party is informed of their access; actual resource access is then managed by other protocols such as WebDAV.

Defines a JSON format for machine-readable Coordinated Vulnerability Disclosure (CVD) policies. It also defines a proposed CVD-Policy field for discovery through security.txt and requests registration of the application/cvd-policy+json media type. The format complements security.txt and human-readable policy documents, and the document is explicit that a policy does not prove ownership and does not establish legal authorization to test, legal safe harbor, or the safety of an activity.

Motivated by the need, once a client signal is configured on a transport (server-layer) network that provides connectivity to its client, to monitor performance such as latency and bit error rate for network operation. The document describes a YANG data model to support these performance-monitoring functions for client signals. It gives operators a standardized way to configure and retrieve client-signal performance-monitoring data.

Provides a mechanism to request path computation in Wavelength-Division Multiplexing (WDM) optical networks composed of Wavelength Switched Optical Network (WSON) and Flexi-Grid DWDM switched technologies. It defines a YANG model that augments the RPCs for optical path computation. This lets controllers request feasible optical paths across WSON and flexi-grid domains.

Addresses OAuth deployments where resource servers receive application-layer authorization evidence digitally signed by the subject an access token represents, requiring the resource server to obtain a trusted public signing key bound to that subject. It defines the subject_keys parameter, by which an authorization server conveys one or more subject public signing keys to a resource server, carried either as a JWT access-token claim or as a member of a token-introspection response. The resulting key binding is scoped to the authorization server, token subject, resource-server audience, and token validity. It defines no key-enrollment protocol or evidence syntax and does not use the OAuth cnf claim.

Defines a YANG data model for control and management of radio-link interfaces and their connectivity to packet (typically Ethernet) interfaces in a microwave/millimeter-wave node. The data nodes for managing interface protection functionality are broken out into a separate, generic YANG model so they can be reused for other interface types as well. This document obsoletes RFC 8561.

Defines the Simple Agent Management Protocol (SAMP), a lightweight management-plane protocol for heterogeneous AI agents. SAMP lets a management system discover agents, query their state, receive and subscribe to event streams, and optionally configure or execute explicitly exposed operations under policy control. Inspired by operational protocols such as SNMP, it is designed for AI-agent concepts such as dynamic profiles, autonomy classes, enrollment, trust states, and policy-gated execution, and is explicitly not an agent-to-agent, tool-use, or agent-framework specification. This document defines SAMP version 0.1 as Experimental for controlled environments and interoperability testing.

Defines a new set of IP Flow Information Export (IPFIX) Information Elements for exporting Base Transport Header (BTH) information for RDMA over Converged Ethernet version 2 (RoCEv2) traffic. These extensions let network monitoring systems collect and analyze the characteristics of RDMA traffic. Such traffic is widely used in high-performance computing, storage, and artificial-intelligence applications.