Window: last 48 hours (2026-09-26 to 2026-09-28 UTC) · generated 2026-09-28 UTC · 100% group coverage
Defines a protocol for real-time interactive communication between users and AI agents over Media over QUIC Transport (MOQT). It specifies how streaming inference outputs (ASR transcripts, LLM tokens, TTS audio) map to the MOQT object model, defines a turn-taking control protocol with barge-in support for voice interactions, and establishes track-structure conventions for live agent sessions. The protocol operates as an application-layer profile on top of MOQT without modifying transport semantics.
A deliberately non-technical Internet-Draft whose point is procedural: anyone can publish an I-D, and publication does not mean "the IETF thinks" or "the IETF is planning" anything. It exists to make that distinction concrete and is not a specification of any protocol or mechanism.
Presents an operator-perspective framework for building and running IPv6-only underlay networks that span multiple domains (interconnected Autonomous Systems). To carry residual IPv4 traffic, it proposes stateless IPv4/IPv6 address mapping as the basis for IPv4-as-a-Service (IPv4aaS), translating IPv4 packets at the network edge and forwarding them across the IPv6-only underlay without per-flow state or conversion gateways on the data path. It is framed as a problem statement, guidance and requirements rather than a protocol specification, covering applicability, trust boundaries, mapping-prefix allocation options, and operational, manageability and security considerations.
Defines a Traceroute Extension Block (TREB) for Bundle Protocol version 7 (BPv7). Each participating node along a bundle's path appends a hop-record with its Node ID, the next hop it selected, the event time, and link characteristics; the same block copied into bundle status reports returns the traceroute data to the source. The mechanism is opt-in and intended for designated diagnostic bundles on scheduled, bandwidth-constrained paths. In delivery-report-only operation a single status report returns the full recorded path and also records its own return path, giving a round-trip trace. Status-report generation remains governed by RFC 9171.
Proposes BGP SAVNET, extending BGP for source address validation (SAV). Existing SAV mechanisms suffer from inaccurate validation or high operational overhead in some scenarios; this document lets SAV-related information be propagated through BGP messages so that edge/border routers can automatically generate accurate SAV rules. Those rules build a validation boundary for the network and help check the validity of source addresses on arriving data packets.
Argues, with evidence, that early (pre-handshake) attestation fails in practice even without physical access to the machine, and that because continuous attestation is generally required, early attestation adds unnecessary complexity. The work cites multiple published CVEs and GitHub Security Advisories (including CVSS 9.1 issues) and is supported by formal analysis artifacts using ProVerif. It reports that all but two early-attestation implementations have been archived, withdrawn or moved to post-handshake attestation, and that the two remaining ones it names remain vulnerable; users are advised to evaluate their systems carefully.
The SCONE protocol relies on the receiver of SCONE packets to return bandwidth estimates to the sender via unspecified application-layer messages. Some peers have SCONE receive capability at the QUIC layer but do not implement the necessary application-level functionality. This document defines a new QUIC frame that directly reports the contents of received SCONE packets to address those cases. There is no change to the interaction with SCONE Network Elements.
By its name, this draft (part of the author's ATTP series) probably concerns applying an agent/trust transport-style protocol to industrial control systems. The official abstract could not be retrieved this run (the archive page returned 404), so this summary is approximate and avoids asserting specific mechanisms; it will be grounded on the next run.
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 be performed now given mutable state such as cumulative budgets, live reservations, approval lifecycle and a kill switch. It specifies a two-phase wire contract between a Policy Decision Point and the Policy Enforcement Points that act: verdicts with machine-readable reasons, fail-closed obligations, atomic budget reservation, an approval lifecycle, idempotency, re-derivable evidence, and invariants including that an irreversible action is never executed autonomously. The protocol is transport-agnostic and lets decision and enforcement points be implemented independently.
Provides an algorithm-independent description of the format and use of RSVP's INTEGRITY object, which is widely used to give hop-by-hop integrity and authentication of RSVP messages, particularly in MPLS deployments using RSVP-TE. The document obsoletes both RFC 2747 and RFC 3097.
Over IPv6's history various classful address models have been proposed, none of which lasted. The last remnant of IPv6 classful addressing is the rigid /64 network interface identifier boundary. This document removes the fixed position of that boundary for interface addressing.
Argues, with evidence, that early (pre-handshake) attestation fails in practice even without physical access to the machine, and that because continuous attestation is generally required, early attestation adds unnecessary complexity. The work cites multiple published CVEs and GitHub Security Advisories (including CVSS 9.1 issues) and is supported by formal analysis artifacts using ProVerif. It reports that all but two early-attestation implementations have been archived, withdrawn or moved to post-handshake attestation, and that the two remaining ones it names remain vulnerable; users are advised to evaluate their systems carefully.
Defines Wallet State Attestation: an issuer reads on-chain state for a wallet address, evaluates operator-defined conditions, and returns a cryptographically signed boolean (or structured fact profile) that any verifier can check offline using a published JWKS endpoint. This enables condition-based access decisions without identity presentation, credential exchange, or contact with the issuer at verification time beyond its published key set. It describes the request/response surface, the signing-algorithm posture, the JWKS discovery pattern, and security and privacy considerations. It defines no new wire protocol; it profiles existing building blocks (JWT, JWKS, JOSE).
Defines the Capability Language Core (CLC), a minimal executable language for describing what an agent is authorized to do: a capability-identifier grammar, the entailment relation between a grant and an operation, intersection of grants from multiple sources, a constraint model, and a deterministic decision function with stable reason codes and a three-valued verdict (allow, deny, allow_unresolved). The language is carrier-neutral (trust models, verification, lifecycle and token formats are out of scope). Conformance is exercised by a published corpus; the document notes that the three named implementations share an author, so the independent-implementation maturity threshold is explicitly recorded as unmet. This revision also folds in a delegation-containment relation (Contains) with its own conformance class.
Specifies the well-known URI /.well-known/button.json, which describes a web site's "buttons" — the familiar 88x31 pixel images (text, logos, artwork, animations) that represent a site. The file facilitates sharing buttons between site owners and alleviates issues commonly encountered when doing so, and its standardized machine-readable format lets automated tools use the provided information.
Defines a governance framework for systems that use AI services, specifically large language models, to autonomously detect, diagnose and remediate operational anomalies on network devices. As AI-driven automation moves from advisory tooling to closed-loop autonomous operation on production infrastructure, the industry lacks common principles on what such systems may and may not do. The framework establishes thirteen governance areas — human authority, harm prevention, management-plane protection, minimum necessary action, bounded autonomy, transparency, reversibility, graceful degradation, escalation, AI-specific constraints, startup safety, absolute prohibitions, and review — as a reference architecture for implementers and operators.
Specifies the Chorale Protocol, a secure packet-transmission system with active integrity assurance for use cases needing resistance to interception, traffic analysis, replay, tampering and retrospective (future quantum) decryption. It defines three confidentiality regimes — computational, everlasting and information-theoretic — and the keying conditions for each; a conforming implementation fails closed and refuses to report a regime its keying cannot support. The protocol composes a per-session secret graph topology that orders packets without transmitting ordering data, cascade-integrity witnessing, cover packets, per-packet verifiable-delay-function time-lock sealing, multi-source one-time-pad composition, multi-substrate flight with threshold reconstruction, and a tombstone ledger preventing pad reuse. It is aimed at intelligence agencies, central banks, treaty-bound corridors and similar high-assurance settings.
Specifies the Continuity Binding: a structure that carries a verified conformance claim across a boundary while preserving evidence provenance, attributing every equivalence judgement to a named party, and enumerating the residual that did not carry. A conformance claim is about a subject, against a baseline, at a time — and all three move. Three specialisations are defined: a Transition Binding (across supersession of a baseline), a Recognition Binding (between different issuers' baselines in concurrent force), and a Mutation Binding (across change in the subject's composition). It also defines Baseline Profiles, Provenance Classes, a verdict taxonomy, a Verification Reconciliation Object, cryptographic-agility requirements, and supporting registries, using the Australian Essential Eight's evolution as the worked example.
Defines a record format for AI-agent authorization decisions: one in-toto predicate type, signed inside a DSSE envelope. It carries the seven minimum audit fields the WIMSE AI Identity Management System framework requires, plus two properties that make those fields checkable — a canonicalization contract, and both the authorization decision and the observed effect together with a derived three-valued agreement between them. The framework itself places the record format out of scope; this document supplies that format and defines no policy.
The Incident Detection Message Exchange Format version 2 (IDMEFv2) defines a data representation for security incidents detected on cyber and/or physical infrastructures, agnostic enough to be used in standalone or combined cyber (SIEM), physical (PSIM) and availability (NMS) monitoring, and able to represent man-made or natural-hazard threats. IDMEFv2 improves situational awareness by letting many event types be correlated in one base format. This document defines how to transport IDMEFv2 alerts over HTTPS and, if approved, would obsolete RFC 4767.
Specifies the Delay-Tolerant Payload Conditioning (DTPC) protocol, an end-to-end, connectionless, expandable application-service protocol designed to run directly above Bundle Protocol version 7 (BPv7). It provides transparent application data conditioning across challenged networks: controlled aggregation of Application Data Units, application-specific elision, transmission-order tracking, end-to-end positive/negative acknowledgments, and duplicate suppression, while preserving the end-to-end principle where intermediate nodes do store-and-forward.
Defines terminology for human oversight of automated and agentic systems, which today is often recorded as a single undifferentiated event (an approval flag or confirmation) that fails to say whether a person was shown an output, checked a named property of it, made a decision, or permitted an action. It defines four kinds of oversight act — observation, check, decision and release — plus related concepts (the overseer, named property, standing authority, oversight record, undifferentiated approval, check step, error detectability, fail-open check step, and check test), states what a record of each is and is not evidence of, and relates the terms to existing vocabularies. It defines terminology only — no protocol, format or procedure.
Reports a measurement rather than specifying anything. A signed COSE_Sign1 statement can be serialized into many byte sequences that all decode to the same data item; when a protocol identifies such a statement by a digest over its wire octets (a data-hash), that identifier is sensitive to framing while the signature is not. Re-emitting one 165-octet COSE_Sign1 object under every combination of six CBOR encoding freedoms yields 64 distinct octet sequences that all carry an identical, valid signature yet produce 64 distinct data-hash values with no collisions; a stock decoder rejected none and silently repaired 31 into the original form. It publishes the reproduction recipe and points at prior work that addresses the problem.
Defines the measurement capsule: a small deterministic JSON record in which a party that is neither the subject of a claim nor a participant in the action records what the subject declared, what the measuring party observed, and the difference between them. A capsule carries digests of its evidence, treats "could not be checked" as a first-class measurement state, and carries no decision, approval or authorization. Capsules are identified by the SHA-256 of their JCS serialisation and batched under an RFC 9162 Merkle Tree Hash; the document describes their registration as SCITT Signed Statements (RFC 9943), how they refer to rather than restate receipts, and one implementation.
Defines the Disclosure Envelope, an out-of-band wrapper for revealing the raw content behind a digest-only Agent Action Capsule field to a verifier without altering the capsule's bytes or recomputing its capsule_id. The Capsule profile commits some fields as an RFC 8785-canonicalized SHA-256 digest only, so the content is never carried in the signed record (initially the compute-attestation input and output digests). An envelope wraps an unmodified capsule alongside a sibling disclosures object; the verifier recomputes the JSON-DIGEST of each disclosed value with the same canonicalization and compares it to the committed digest. This differs from per-field selective disclosure: it reveals content behind a field that was always present as a digest.
Defines the AAC Evidence Bundle, a portable presentation and verification container for an Agent Action Capsule and the records that make its evidentiary claim intelligible. A permalink can carry a bundle in its URL fragment, an offline HTML report in its shell, and a hosted report at its URL. The bundle does not alter any enclosed capsule; it declares its citation closure and any missing cited records, carries verified disclosure preimages as a bundle-level overlay, separates three different completeness claims, and permits independently specified extension blocks and neutral third-party countersignatures.
Defines a transport-agnostic request/response interaction for verifiable evidence between parties that do not trust each other. A request names its subject and a coverage anchor; the outcome is exactly one of three things — the evidence artifact, a signed refusal carrying a machine-readable reason, or a recorded absence — so that one system's silence, another's error and a third's stale cache are no longer indistinguishable. Asking, granting and refusing are each attributable and checkable, and the same subject under the same coverage must yield a byte-identical artifact for every requester. The interaction is symmetric, and a responder may commit in a signed statement to keep a subject answerable until a stated time. It defines no evidence format, identity scheme, trust policy or availability guarantee.
Defines a SCITT statement profile — the Agent Action Capsule — for recording what an AI agent did: 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 that distinguishes 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 their Capsule ID can be made transparent via registration in a SCITT Transparency Service. A capsule is recorded on every verdict, including refusals: a blocked or denied capsule is auditor-grade evidence that a gate worked.
Specifies the Checkpointed Local Log (CLL): a producer-operated append-only log built on the Merkle Mountain Range structure, together with a small signed checkpoint that commits to the log's entire history. Many systems emit individually signed records and store them locally; each verifies alone but the collection proves nothing, since records can be deleted, reordered or backdated undetectably. Records of any format are appended as produced; checkpoints are emitted on a declared cadence and may be registered with one or more independent Transparency Services or witnesses using existing SCITT registration. A CLL upgrades a set of point receipts into a stream with provable order, contemporaneity and completeness, while defining narrowly what it does and does not establish.
Extends the Zero-Trust Fabric Layer (ZTFL), which verified a single autonomous agent issuing a single request, to the case where that agent delegates authority to a second or third agent — already standard in multi-agent orchestration. It proposes a chained authorization model using travel metaphors: a Passport establishes identity across the journey; a Ticket binds all subsequent hops to the authorized chain; per-hop Boarding Passes authorize individual legs while remaining traceable to the Ticket; and Visas provide explicit, narrowly scoped grants required only when crossing tenant boundaries. The model is a boundary-conditional evaluation function, implemented and validated against the Cedar policy language, giving chain-wide traceability and boundary containment that OAuth Token Exchange and ReBAC do not.
Argues, with evidence, that early (pre-handshake) attestation fails in practice even without physical access to the machine, and that because continuous attestation is generally required, early attestation adds unnecessary complexity. The work cites multiple published CVEs and GitHub Security Advisories (including CVSS 9.1 issues) and is supported by formal analysis artifacts using ProVerif. It reports that all but two early-attestation implementations have been archived, withdrawn or moved to post-handshake attestation, and that the two remaining ones it names remain vulnerable; users are advised to evaluate their systems carefully.
NFSv4.2 clients may cache the file attributes returned by READDIR alongside each directory entry. Such a cache is not invalidated by the directory's change attribute — which reflects changes to the directory and its entries but not writes to the files they name — so it can become stale when another client changes one of those files, producing incorrect size and timestamp values often enough to be a problem in some deployments. This document introduces an uncacheable dirent-metadata attribute for NFSv4.2 that lets a server mark a directory for which an honoring client reports each entry's attributes exactly as READDIR returned them, rather than from an earlier held value.
Defines Zero-Trust Data Sanitization (ZTDS), a formal architecture and execution protocol for client-side, in-memory de-identification and re-identification across generative-AI, retrieval-augmented-generation and autonomous-agent workflows. Sensitive information — PII, PHI, financial account numbers and developer secrets — is intercepted and transformed into synthetic surrogate tokens strictly within the volatile memory of the originating client or private host node before network serialization. The specification formalizes the threat model, four core invariants, surrogate-token syntaxes, cryptographic transport handoffs, and the verification procedures required for interoperable, zero-subprocessor implementations.
Service providers such as certificate authorities and social-media platforms often ask users to update their DNS zones to prove control or add features, and today they do so with human-language instructions describing the record type and values to enter. This document defines a text format, "DNS update with JSON" (DUJ), that a provider gives to a user with the expectation that the user copies and pastes it to their DNS operator to update the zone. DNS operators who understand DUJ strings can make the update process easier and more predictable for their users.
Existing transparency logs prove presence; TACET is a transparency map whose primary product is a portable, offline-verifiable proof of absence over time — that for a given subject no record satisfying a public predicate existed in the map, and none was found on the subject's monitored public surfaces, across a contiguous range of epochs bounded below by a public randomness beacon and above by a Bitcoin block. It specifies the map (a depth-256 sparse Merkle tree), the signed epoch sheet, surface snapshots and predicates, the delta-encoded silence proof with three strength levels, the monotonicity rule under which silence never accrues without observation, an anchor check needing no Bitcoin node, and receipt wrapping. It also defines PNX, a profile proving that labelled assets were not exfiltrated during an AI-agent run.
By its name this draft probably profiles the HTTP 402 ("Payment Required") status for a token/settlement web-payment scheme ("TSWP"). The official abstract could not be retrieved this run (the archive page returned 404), so this summary is approximate and does not assert specific fields or algorithms; it will be grounded on the next run.
The official abstract could not be retrieved this run (the archive page returned 404), and the short name "aer1" is not self-explanatory, so no reliable summary can be given yet. It will be grounded from the document's abstract on the next run.
Defines the Canonical Action IDentifier (CAID). Authorization, delegation, execution and audit artifacts often identify an action using format-local content and digests that are not directly comparable when formats encode material fields differently. CAID defines a typed action object, a canonicalization and digest suite, a compact identifier string, and immutable action-type definitions with required material fields; external enum definitions are bound to immutable, integrity-checked value-set snapshots. It also defines an Action-Mapping Profile for projecting independently verified native artifacts into a common action type, with the closed results EQUIVALENT_UNDER_PROFILE, NOT_EQUIVALENT and INDETERMINATE. CAID carries no trust semantics and establishes no identity, authority, authorization, execution, safety or legal reliance.
Describes an operational framework within Deepspace/TIPTOP protocols for using an external, standardized reference for celestial objects — an equivalent of ISO 3166 for interplanetary networking. To avoid operational overhead and duplication, the framework defers the definition, naming and tracking of celestial entities to the International Astronomical Union (IAU) and the Minor Planet Center (MPC), and outlines how these external identifiers guide hierarchical address allocation without IANA maintaining a dedicated astronomical registry. The goal is a clear definition of what constitutes a valid Celestial Body for networking purposes.
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 events, subscribe to event streams, and optionally configure or execute explicitly exposed operations under policy control. Inspired by operational management protocols such as SNMP, it is designed around AI-agent-specific concepts — dynamic profiles, autonomy classes, enrollment, trust states and policy-gated execution — and is explicitly not an agent-to-agent communication protocol, a tool-use protocol, or an agent framework. This document defines SAMP version 0.1 as an Experimental protocol for controlled environments and interoperability testing.
Deep-space communications involve long one-way delays (Earth to Mars is 4–24 minutes) and intermittent connectivity due to orbital dynamics. This document defines an SNMP profile for deep space: for each SNMP version and security model, it states what must be configured, provisioned or changed, and maps their applicability to deep-space connectivity scenarios.
Describes CTP/0, the definition layer of the Cognitive Time Protocol (CTP) family — an informational conceptual framework for naming, separating, comparing and referencing time-related claims in AI and agent systems. It defines terminology for profile-defined cognitive events, event-density claims, ordering claims, branching claims, sequential-computation evidence and declared temporal-structure claims. It defines no wire protocol, message or signature format, identity system, hash-chain protocol, governance process, physical theory of time, theory of consciousness or legal-accountability framework; where verifiable records are needed, CTP-compatible claims can bind to external evidence infrastructure.
Defines CEP-2, an optional profile of the Judgment Event Protocol (JEP) for binding declared AI, model, agent, policy, tool-chain or deployment changes to independently verifiable evidence and external anchor references. It defines one critical JEP record-binding extension, a minimal Evolution-Change Record, Subject and Change semantics, digest-first evidence references, typed external anchors and independent validation checks, with JEP remaining authoritative for event verbs, identity, hashing, signatures and acceptance. CEP-2 records declared change evidence only; it does not determine whether a change occurred, improved or degraded a system, was authorized, safe, lawful, reversible or acceptable.
Defines COE-2, an optional profile of the Judgment Event Protocol (JEP) for binding shared-observation records and shared-state claims across heterogeneous agents, sensors, world models, simulators and human-operated systems. It defines one critical JEP record-binding extension, two minimal digest-addressed record types, evidence-reference semantics and independent validation checks, with JEP authoritative for the core mechanisms. COE-2 provides verifiable shared-observation infrastructure only; it does not determine objective world truth, causality, consensus, authorization, legal effect, fairness, trust weights or regulatory compliance — a valid result establishes only the properties actually checked.
Defines JAC-2, a minimal declared-dependency-graph profile for the Judgment Event Protocol (JEP). It binds a signed JEP event to zero or more declared parent dependencies through one critical JEP extension, using JEP Event Identity for logical dependencies and Event Hash only when an exact signed artifact must also be pinned; digest-addressed receipt or external records can be linked without becoming JEP events. It defines dependency-link structure, partial-fragment semantics, cycle handling, chain-validation checks and non-inference boundaries, and does not determine factual causality, responsibility, fault, authorization validity, workflow correctness, legal effect or regulatory compliance.
Defines JEP Receipt Profile 1 (JEP-RP-1), a minimal receipt and evidence profile for the Judgment Event Protocol (JEP). It binds a JEP event to one digest-addressed receipt record through a critical JEP extension, and defines a small behavior-record format, portable receipt manifests and bundles, and independent receipt-validation checks, with JEP remaining authoritative for the core mechanisms. Receipt records are technical evidence about observable behavior and related artifacts; JEP-RP-1 assigns no legal liability, proves no subjective intent, and establishes no authorization validity, causality, governance outcome or regulatory compliance.
Defines JEP Action Mandate Profile 2 (JEP-AMP-2), a profile of the Judgment Event Protocol (JEP). It specifies how a JEP Delegation event can express a bounded, verifiable, terminable and auditable mandate for an agent, human, organization, workflow or system to attempt an action on behalf of a principal. It does not redefine JEP-Core event verbs, identity, hashing, signatures, validation, identity/credential systems, liability, payment clearing or global authorization validity; it defines a signed Action Mandate Descriptor and profile-level rules for evaluating mandate validity under explicit trust, policy, domain and relying-party context.
Defines semantic-interoperability requirements for the Judgment Event Protocol (JEP). Rather than redefining JEP-Core's signed J/D/T/V event semantics, identity, hashing, references and acceptance, it defines the minimum shared interpretation rules independent systems need to map, display, translate and consume JEP events without silently changing their meaning. The core rule is that a JEP event records a signed protocol statement with defined verb semantics; by itself it establishes no external truth, authority, legality, causality, completeness, policy consequence or external effect — stronger conclusions require an explicitly selected profile or external evidence rule.
Defines a profile model and optional interoperability bindings for the Judgment Event Protocol (JEP). JEP-Core defines a narrow signed-event protocol; profiles define deployment-specific rules for actor identifiers, key resolution, actor binding, credentials, authorization context, attestation, freshness, audience, replay-related mechanisms, archival evidence, chain interpretation and policy integration without changing JEP-Core semantics. Profiles are optional: a JEP-Core implementation must not require DID, Verifiable Credentials, X.509, OAuth, OpenID Connect, RATS, blockchain anchoring or any other optional profile for Core conformance.
Defines conformance classes, validation-result structure, schema requirements, test-vector categories, reference-validator behavior and implementation-testing guidance for the Judgment Event Protocol (JEP), as a companion to the JEP core document. It does not redefine JEP-Core semantics; its purpose is to make JEP-Core 0.7 implementations testable and interoperable across languages, platforms, trust profiles and deployment environments.
Defines the Judgment Event Protocol (JEP), a verifiable event format for judgment-related statements in human, organizational, software and autonomous-agent systems. It specifies four core event verbs — Judgment (J), Delegation (D), Termination (T) and Verification (V) — a signed JSON event structure, stable event identity, signature verification over JCS-canonicalized payloads, a detached JWS baseline profile, signed-artifact hash and reference semantics, independent validation checks, idempotent acceptance, structured validation results, extension handling, trust-profile interfaces and determinability boundaries. JEP-Core mandates no replay-protection mechanism (an acceptance processor must apply a given Event Identity's effect at most once per acceptance domain) and does not determine the substantive truth, authority, legality, policy consequence, causality or external effect of the statements it carries.
Presents an optional new type of link-state database synchronization packet, the Aggregated SNP Hash (ASH). When feasible it compresses traditional SNP exchanges into a dynamic Merkle-tree-like structure, speeding synchronization of large databases and adjacency counts while reducing the load from regular CSNP exchanges during normal operation. Like CSNPs and PSNPs, ASH packets come in two flavors: Complete ASH (CASH) and Partial ASH (PASH).
AI agents increasingly persist memory across sessions and, on the next turn, treat that memory as their own prior experience. This document defines a benchmarking method measuring whether an agent's memory subsystem detects that its persisted memory was altered, removed, reordered, replayed or forged at the storage layer, and refuses to serve it or reports it before serving. The method defines eight storage-level edits, three verdict classes, a read-time-versus-audit-time detection distinction, two control cases and a scoring rule. It is a laboratory method for controlled, reproducible measurement in the spirit of RFC 2544 and RFC 8239, intended as a test method for the BMWG "Protection of Memory Data Integrity" metric.
Describes a YANG data model for the management of Quality of Service (QoS) in IP networks.
Describes GAAP (pronounced "gap"), a lightweight decentralized multicast group-address allocation protocol. GAAP needs no centralized service or coordination for the allocation protocol itself, though it depends on ASM-capable multicast routing already provisioned in the domain, and deployments using encryption or administrative scoping may need extra configuration. It runs among group participants that need a unique group address to send and receive multicast packets, is tailored for IPv4 and IPv6, and offers a simple lightweight option rather than extending an existing protocol. The document is Experimental and states the rationale and criteria for concluding the experiment.
Describes a scheme for hybrid public-key encryption (HPKE), providing a variant of public-key encryption of arbitrary-sized plaintexts for a recipient public key, plus a variant that authenticates possession of a pre-shared key. HPKE works for any combination of an asymmetric Key Encapsulation Mechanism (KEM), key derivation function (KDF) and AEAD encryption function, and the document instantiates it with widely used, efficient primitives such as ECDH key agreement, HKDF and SHA-2. This document obsoletes RFC 9180.
Defines the Action Evidence Boundary (AEB), an executor-side processing model for consequential agent actions that cross identity, transport, authorization, policy and execution systems — where each system can produce a valid artifact yet the executor still lacks a safe rule for joining artifacts to the exact effect, consuming one-time authority, and handling an uncertain outcome. AEB requires native-artifact verification, exact-action binding, a relying-party authorization decision, durable atomic consumption or reservation, provider entry, closed effect outcomes and authenticated reconciliation. A relying-party-pinned authority namespace and native identifier stop a grant from being spent twice, and a durable same-action fence refuses a new attempt while an earlier one is in flight or uncertain. It uses CAID matching to join encodings and AEC evaluation for multi-leg policy, and defines no receipt/token format, policy language or new registry.