| |
|
| |
| | Framework and Data Model for OTN Network Slicing |
| |
| | draft-ietf-ccamp-yang-otn-slicing-12.txt |
| | Date: |
31/08/2026 |
| | Authors: |
Aihua Guo, Luis Contreras, Sergio Belotti, Reza Rokui, Yunbin Xu, Yang Zhao, Xufeng Liu |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
|
The requirement of slicing network resources with desired quality of service is emerging at every network technology, including the Optical Transport Networks (OTN). As a part of the transport network, OTN can provide hard pipes with guaranteed data isolation and deterministic low latency, which are highly demanded in the Service Level Agreement (SLA). This document describes a framework for OTN network slicing and defines YANG data models with OTN technology-specific augments deployed at both the north and south bound of the OTN network slice controller. Additional YANG data model augmentations will be defined in a future version of this draft. |
| | Architecture Discussion on SRv6 Mobile User plane |
| |
| | draft-ietf-dmm-srv6mob-arch-04.txt |
| | Date: |
31/08/2026 |
| | Authors: |
Teppei Kamata, Jakub Horn, Luay Jalil, Weiqiang Cheng, Miya Kohno |
| | Working Group: |
Distributed Mobility Management (dmm) |
|
This document describes the solution approach and its architectural benefits of transforming mobile session information into routing information, leveraging segment routing capabilities, and operating within the IP routing paradigm. |
| | ESP Header Compression with Diet-ESP |
| |
| | draft-ietf-ipsecme-diet-esp-11.txt |
| | Date: |
31/08/2026 |
| | Authors: |
Daniel Migault, Maryam Hatami, Sandra Cespedes, J. Atwood, Daiying Liu, Tobias Guggemos, Carsten Bormann, David Schinazi |
| | Working Group: |
IP Security Maintenance and Extensions (ipsecme) |
|
This document specifies Diet-ESP, a compression mechanism for control information in IPsec/ESP communications. The compression uses Static Context Header Compression rules. |
| | Internet Key Exchange version 2 (IKEv2) extension for Header Compression Profile (HCP) |
| |
| | draft-ietf-ipsecme-ikev2-diet-esp-extension-08.txt |
| | Date: |
31/08/2026 |
| | Authors: |
Daniel Migault, Maryam Hatami, Sandra Cespedes, J. Atwood, Daiying Liu, Tobias Guggemos, David Schinazi, Stere Preda |
| | Working Group: |
IP Security Maintenance and Extensions (ipsecme) |
|
This document describes an IKEv2 extension for Header Compression to agree on Attributes for Rule Derivation. This extension defines the necessary registries for the ESP Header Compression Profile (EHCP) Diet-ESP. |
| | Enhanced Encapsulating Security Payload (EESP) |
| |
| | draft-ietf-ipsecme-eesp-04.txt |
| | Date: |
31/08/2026 |
| | Authors: |
Steffen Klassert, Antony Antony, Christian Hopps |
| | Working Group: |
IP Security Maintenance and Extensions (ipsecme) |
|
This document describes the Enhanced Encapsulating Security Payload (EESP) protocol, which builds on the existing IP Encapsulating Security Payload (ESP) protocol. It is designed to modernize and overcome limitations in the ESP protocol. EESP adds Session IDs (e.g., to support CPU pinning and QoS support based on the inner traffic flow), changes some previously mandatory fields to optional, and moves the ESP trailer into the EESP header. Additionally, EESP adds header options adapted from IPv6 to allow for future extension. New header options are defined which add a crypt- offset to allow for exposing inner flow information for middlebox use. |
| | IKEv2 negotiation for Enhanced Encapsulating Security Payload (EESP) |
| |
| | draft-ietf-ipsecme-eesp-ikev2-03.txt |
| | Date: |
31/08/2026 |
| | Authors: |
Steffen Klassert, Antony Antony, Tobias Brunner, Valery Smyslov |
| | Working Group: |
IP Security Maintenance and Extensions (ipsecme) |
|
This document specifies how to negotiate the use of the Enhanced Encapsulating Security Payload (EESP) protocol using the Internet Key Exchange protocol version 2 (IKEv2). The EESP protocol, which is defined in [I-D.ietf-ipsecme-eesp], provides the same security services as Encapsulating Security Payload (ESP), but has richer functionality and provides better performance in specific circumstances. This document specifies negotiation of version 0 of EESP. |
| | Enhanced AS-Loop Detection for BGP |
| |
|
Misconfiguration and malicious manipulation of the BGP `AS_PATH` attribute can lead to route hijacking. This document proposes enhancements to BGP [RFC4271] inbound and outbound route processing when an AS loop is detected. This mechanism can be implemented directly on devices or deployed in a centralized architecture using the BGP Monitoring Protocol (BMP) [RFC7854]. These enhancements empower networks to quickly and accurately detect route hijacking and malicious path poisoning. Two implementation options are proposed: |
| | The Restatement Anti-Pattern |
| |
|
Normative documents that cite other normative documents often _restate_ normative content extracted out of the cited document in their own words. The present memo explains why this can be an Antipattern, and how it can be mitigated. |
| | Differentiated Services Field Codepoints Internet Key Exchange version 2 Notification |
| |
| | draft-mglt-ipsecme-dscp-np-06.txt |
| | Date: |
31/08/2026 |
| | Authors: |
Daniel Migault, Joel Halpern, Stere Preda, Daiying Liu, U. Parkholm |
| | Working Group: |
Individual Submissions (none) |
|
This document outlines the DSCP Notification Payload, which, during a CREATE_CHILD_SA Exchange, explicitly indicates the DSCP code points that will be encapsulated in the newly established tunnel. This document updates RFC 4301. |
| | Use of Composite ML-DSA in TLS 1.3 |
| |
|
Compositing the post-quantum ML-DSA signature with traditional signature algorithms provides protection against potential breaks or critical bugs in ML-DSA or the ML-DSA implementation. This document specifies how such a composite signature can be formed using ML-DSA with RSA-PKCS#1 v1.5, RSA-PSS, ECDSA, Ed25519, and Ed448 to provide authentication in TLS 1.3, including use in certificates. |
| | Taxonomy of Composite Attesters |
| |
|
This document was attempting to clarifys and extends the meaning of Composite Attester from RFC9334. It has since been moved into the RATS wiki, and this I-D serves as a tombstone. A system of annotated diagram components is defined as a small language to explain the different ways that components can interact to form composites. These diagram components are then used to define a few popular classes of composites. |
| | Customer-Facing Relay (CFR): Enhancing Source Privacy in Encrypted Transport and CDN Scenarios |
| |
|
Encrypted ClientHello (ECH) protects sensitive TLS ClientHello fields, including the Server Name Indication (SNI), from on-path observers. ECH does not, however, attempt to hide the client's network-layer source identity from the ECH client-facing server (CFS). In split-mode deployments, the CFS decrypts the ClientHelloInner in order to route the connection to the appropriate backend while also receiving the connection from the client's visible source address. This creates a distinct source-privacy problem. Where ECH service and content front-door infrastructure are concentrated, a relatively small number of providers can obtain a privileged vantage point from which a stable source address can be correlated with many encrypted destinations and with other service telemetry. Measurements over a corpus of approximately one million domains, together with an active- ECH validation subset, show substantial front-door concentration and motivate treating source privacy as a complement to destination privacy. This document describes the Customer-Facing Relay (CFR), a network- layer, access-side source-aliasing function. A CFR forwards encrypted TCP or UDP traffic without terminating TLS or QUIC and replaces the subscriber-visible source address with a shared or short-lived source alias. The document also examines the different privacy properties of IPv4 NAT/CGN and IPv6 source addressing and identifies requirements for privacy-preserving source mapping. |
| | WTX-1: Cross-Domain Context Preservation Protocol |
| |
|
This document defines WTX-1, a protocol for preserving pseudonymous user context across web domains that are operated by, or on behalf of, the same organization and that have mutually opted into the exchange. The protocol operates only after explicit user consent and does not use third-party cookies, browser fingerprinting, or collection of direct identifiers by default. Identifiers are pseudonymous, not anonymous: they can be linked to application-level identities by the deploying organization and may constitute personal data under applicable law. WTX-1 transfers context using an encrypted, authenticated, destination-bound, single-use token carried in the URL fragment. Tokens are issued and verified server side, with atomic replay consumption, DNS-based domain authorization, and short-lived server- signed write grants that authorize browser write operations without trusting caller-supplied tenant claims. This revision (draft-02) replaces the signed-cleartext token format of draft-01 with a sign-then-encrypt construction, specifies write grants and replay-consumption ordering, defines the consent lifecycle including withdrawal and asynchronous cancellation, adds storage retention limits and user inspection, reset, and revocation controls, and rescopes the document's security, privacy, and performance claims to match the reviewed reference implementation. A complete change log appears in Appendix A. |
| | Verifiable Agent Conversation Records |
| |
|
Autonomous agents based on large language models increasingly perform consequential tasks on behalf of humans and other agents. Demonstrating that recorded agent behavior truthfully represents actual behavior is essential for accountability, compliance, and human oversight. This document defines a data format for verifiable agent conversation records using CDDL, with representations in both JSON and CBOR. The format captures session metadata, message exchanges, tool invocations, reasoning traces, and system events in a structured, extensible CDDL definition for verifiable agent conversation records. COSE is used as the signing method to allow for native interoperability in SCITT Transparency Services and the CDDL definition allows for seemless integration in Evidence as specified in RFC 9334. The specification supports cross-vendor interoperability by defining a common representation that accommodates translation from multiple existing agent implementations with distinct data structure layouts that are typically represented in JSON. |
| | Agent Envelope Exchange (AEE): A Minimal JSON Envelope Format for Inter-Agent Communication |
| |
|
Agent Envelope Exchange (AEE) defines a minimal, transport- independent JSON envelope format for communication between autonomous AI agents, traditional services, and human participants. The envelope comprises 14 well-defined fields that provide message identity, typing, correlation, tracing, priority, and extensibility without prescribing payload semantics or transport mechanisms. AEE separates the concerns of message routing and lifecycle management (the envelope) from domain-specific meaning (intent schemas), enabling portable, composable, and auditable workflows across heterogeneous agent frameworks. This document specifies the envelope structure, validity rules, conformance levels, entity identifier conventions, a reserved intent namespace for protocol negotiation, and a referencing strategy that avoids envelope nesting. |
| | Agent Orchestration Control Layers (AOCL) Protocol |
| |
|
Agent Orchestration Control Layers (AOCL) is a protocol that standardizes how an orchestrator processes incoming events by passing them through a layered control pipeline. AOCL defines an eleven- layer taxonomy covering ingress normalization, identity scoping, smart routing, policy gating, plan decomposition, context retrieval, prompt shaping, delegation and execution, verification, response assembly, and audit writeback. The protocol is runtime-agnostic and framework-agnostic, producing auditable governance traces as a first- class output. AOCL supports both sequential pipeline and directed acyclic graph (DAG) execution modes, with explicit bypass and branch semantics that mandate audit records for all control-flow deviations. |
| | Verifiable Operations Ledger and Trace (VOLT) Protocol |
| |
|
The Verifiable Operations Ledger and Trace (VOLT) protocol defines a minimal, interoperable format for producing tamper-evident execution traces for agentic AI workflows. VOLT records are linked via SHA-256 hash chains and packaged into portable Evidence Bundles that can be verified independently by any conformant implementation. VOLT functions as a "flight recorder" for AI agent operations: it captures the sequence of events -- messages received, policy decisions evaluated, human approvals granted, tools invoked, and results returned -- with cryptographic integrity guarantees that detect post-hoc modification, deletion, or insertion of records. The protocol is privacy-first by design. Events carry metadata and content-addressed references rather than raw secrets or sensitive payloads. Evidence Bundles support explicit redaction, optional Ed25519 signatures for non-repudiation, and both rolling and final snapshot modes for long-running workflows. |
| | Source-IP-Community Filter for BGP Flow Specification |
| |
|
BGP Flow Specification (BGP-FS) propagates traffic Flow Specifications and Traffic Filtering Actions using BGP NLRI and BGP Extended Community encodings. This document specifies a new BGP-FS component type to support community-level filtering within a single administrative domain. The match condition filters traffic based on the BGP Community attributes associated with the route matching the packet's source IP address. |
| | Compliance Profile of Signed Action Receipts for AI Agents |
| |
|
This document defines a multi-jurisdiction compliance profile of the signed action receipt format used by AI agents to record machine- readable evidence of access-control decisions. The profile binds receipt fields to two regulatory surfaces: on the European Union side, Articles 12 and 26 of the EU AI Act (Regulation (EU) 2024/1689) and Article 17 of DORA (Regulation (EU) 2022/2554); on the United States side, the NIST AI Risk Management Framework, the Colorado AI Act, the Texas Responsible AI Governance Act, the New York Department of Financial Services Cybersecurity Regulation (23 NYCRR Part 500), the HIPAA Security Rule, SEC Rule 17a-4, and the Cyber Incident Reporting for Critical Infrastructure Act of 2022 (CIRCIA). Working entirely within the existing wire format, canonicalization transformation, and signing algorithms of the underlying receipt format, the profile tightens a subset of the OPTIONAL fields to REQUIRED, imposes a retention floor, and requires at least one timestamping anchor (RFC 3161 or OpenTimestamps). It registers OPTIONAL extension fields for risk and incident classification, cross-agent envelope binding, per-action validity-window and integrity, build provenance, threat-framework taxonomy, server-built enforcement-control records, producer-asserted risk acceptance, and producer-asserted code authorship, each subject to false-attestation guards where applicable, and registers receipt type namespaces for passive-telemetry, result-bound observation, risk-acceptance, and code-authorship receipts. Revision -08 additionally defines an attestation statement envelope (a Dead Simple Signing Envelope (DSSE) Pre-Authentication Encoding wrapping an in-toto Statement v1 under an asqav predicate namespace) with two tiers: a voluntary observation attestation that signs a caller-supplied digest and is explicitly not a capture, and an authoritative attestation whose subject digest the issuing platform re-derives from independent evidence (for code, the SHA-256 of the raw unified diff re-fetched from the source host); revision -08 further defines the capture-layer integrity, independent verification protocol, honest-tiering, and service-identity and revocation rules that govern those attestation statements, and documents the shipped keyed-digest wire tokens and the verifier verdict vocabulary (verified, verified_keyed, unverified). The full field set and its normative requirements are defined in the body of this document. |
| | Policy Provision and Governance Inheritance from an Organisational Identity Substrate |
| |
|
This memo specifies how an artificial-intelligence agent runtime, bound at instantiation to a principal identity handle, resolves at session initialisation a target organisational identity substrate from a manifest source bound to the runtime's working context and retrieves from that substrate a typed policy stack comprising a handbook artefact, a standard-operating-procedure registry pointer, an enforcement-gate specification, and an audit-signal ingestion endpoint. The policy stack is then applied as runtime constraints on subsequent tool invocations, with audit signals emitted back to the same substrate. Policy provision occurs in the same act of session initialisation as principal identification, rather than as a separate ceremony against a side-channel governance plane. A principal concurrently bound to multiple organisational substrates operates the runtime under a deterministic composition of the several policy stacks, with cross-organisational residual conflicts routed to the peer-protocol Identity Accord ceremony [IDACCORD] rather than to a meta-federation authority. The memo is Informational. The wire surface relies on the DNS-based discovery of [MCPDNS] and the handle namespace of [IDPRONOUNS]; no new transport is introduced. |
| | Identity Accord Protocol: A Peer Ceremony for Bilateral Agreements Between Identity-Substrate-Bound Principals |
| |
|
This memo specifies the Identity Accord Protocol, a peer ceremony by which two principals, each represented by an organisational identity substrate and acting under a recorded delegation from a legal entity, execute a bilateral agreement as a portable, self-verifying COSE- signed CBOR document. The protocol composes DNS-based substrate discovery, Ed25519 sovereign signatures, an append-only identity log, and a tamper-evidence descriptor quorum into a single artefact that is verifiable by any third party with access to the public DNS, the parties' identity logs, and an on-chain anchor of the agreement's content hash. The protocol does not require a central registry, a designated verifier, or any infrastructure operated by the specification's author; verification succeeds when the author's reference deployment is offline. The canonical bilateral target is a mutual non-disclosure agreement, but the wire format generalises to any bilateral consent envelope between two legal entities each represented by an identity substrate. An associated MCP tool surface, an associated pre-send enforcement gate, and an associated disclosure-ledger schema are specified, all of which are optional layers above the wire format. The memo is Informational; the underlying COSE and CBOR formats are normative per [RFC9052] and [RFC8949]. |
| | The 'alter' URI Scheme for Dispatchable ~handle References |
| |
|
This document defines the alter URI scheme as a dispatchable reference syntax for ~handle identity references published under the DNS substrate defined in [MCPDNS]. An alter: URI binds a textual ~handle reference to a resolution and verification procedure that retrieves the handle's envelope from the publishing zone, validates the envelope's signature chain, and dispatches the result to an operating-system URI handler. The reference may be scoped to an organisation, narrowed to a named facet of the identity, and addressed to a typed action surface. The scheme is the addressing form of the ~handle@org:facet/action reference; its resolution semantics are those of [MCPDNS], reused without modification. The scheme is provider-neutral, introduces no new cryptographic primitive, and reuses the resolution and verification procedures of [MCPDNS] without modification. The principal contribution is a single, self-verifying dispatch surface for handle-typed references: clicking, typing, or scanning an alter: URI yields a verified handle resolution rather than a free-text string or an unauthenticated fetch, and where an action is addressed it yields a verify-before- side-effect dispatch. This document requests provisional registration of the alter scheme with IANA per [RFC7595] Section 3. |
| | The Briefing-and-Binding Envelope: A Delivery Contract for Agent-to-Principal Decision Moments with Dual-Veto Reconciliation |
| |
|
This memo specifies the briefing-and-binding envelope: a delivery contract for the wire-level structure by which an artificial- intelligence agent surfaces a consequential decision to the human principal it acts for, and by which the principal commits, declines, amends, or rejects that decision. The envelope carries eight named slots (a synopsis, findings, recommendations, an offer of detail, a question stem, a set of options each marked with its own reasoning, a single recommended option, and a pair of escape hatches) and is emitted as a structured field of a Model Context Protocol [MCP] tool result. The contribution is the delivery contract itself: a single renderer-agnostic envelope so that the briefing an agent delivers and the binding a principal commits back have one machine-checkable shape across every consuming surface. The central element is the dual-veto handshake: one escape hatch lets the principal revise the answer space while accepting the question; the other lets the principal reject the question itself and reopen deliberation. Either party may veto. The memo defines a content digest over the envelope, canonicalized under JCS and hashed with SHA-256, so that a resolution names the exact envelope it resolves and an external receipt can reference that envelope by digest. The memo is Informational. No new transport is introduced; the envelope composes with the handle namespace of [IDPRONOUNS] and the MCP tool surface of [POLICYPROV]. |
| | Composing Application-Layer Action Evidence with Remote Attestation Procedures |
| |
|
This document sketches a composition pattern in which an application- layer "action evidence package" (AEP) -- a signed action record that can be hash-linked to earlier records and that reports an action taken by an automated (for example, AI-agent) system, the authority under which it was taken, and its outcome -- is treated as Evidence in the sense of the RATS Architecture (RFC 9334) and bound to platform Evidence produced by a hardware root of trust. The intent is that a single Verifier, or a composition of Verifiers, can appraise both the platform state and the application-layer record together, and emit an Attestation Result that a Relying Party can use to reason about _what an automated system reports it did_ and _the appraised state of the platform associated with that record_. The composition does not turn a self-reported action or outcome into an independently observed fact; it prevents the Relying Party from having to rely on an unbound operator-side log alone. This is an individual sketch intended to ask the working group whether the pattern is already covered by existing mechanisms or warrants a short document. |
| | Cross-Organizational Delegation for Workload and Agent Identity: Problem Statement and Requirements |
| |
|
Autonomous software agents increasingly act on behalf of human principals by invoking tools, services, and other agents, frequently across organizational boundaries. Existing workload and token-based authorization mechanisms were designed for a single trust domain and a small number of delegation hops. They do not adequately express, constrain, or verify authority that is delegated recursively among agents and that crosses the boundary between independently administered organizations. This document describes the problem of cross-organizational agent delegation, identifies the gaps in current mechanisms, and enumerates requirements that any solution within the scope of the Workload Identity in Multi-System Environments (WIMSE) working group should satisfy. It does not specify a solution. |
| | Consented and Attributable Agent Authority for Operational-Technology Control Actions |
| |
|
This memo specifies a binding profile by which a control action issued to an operational-technology (OT) or industrial control system on the authority of a software agent is refused unless it carries a verifiable statement of who the agent is, which human principal it acts for, whether that principal authorised this specific action on this specific asset, whether a named human signed off on the action where its risk class requires it, and an append-only record sufficient to attribute the action afterward. The profile does not invent new cryptography or a new identity mechanism. It composes primitives specified elsewhere, DNSSEC-rooted agent discovery, a scoped and revocable authorisation grant, a named-human authorization receipt bound into the record as human-authorization evidence, and an append-only transparency record, into a single structure, the Command Authority Envelope, that an enforcement point evaluates and, on any missing or invalid binding, refuses. The profile is availability- first and fails closed on authority, never on safety: it MUST NOT be placed in the trip path of a safety function. The memo maps the profile onto the identification, use-control, and audit requirements that the IEC 62443 and NERC CIP frameworks state but do not give a wire mechanism for. A neighbouring proposal gates safety-critical commands on an agent's trust level; this profile takes the opposite position, and states why. The methods by which a principal's identity is inferred are out of scope by construction. |
| | Registration Data Access Protocol (RDAP) Extension for Server Validation |
| |
|
This document describes an Registration Data Access Protocol (RDAP) extension for providing the status of server validations. Server validations can be done for an extensible set of types, with examples including validating DNS resolution with the type "dns" and validating DNSSEC with the type "dnssec". The validations can be performed synchronously in the provisioning command or asynchronously based on a triggering command or a schedule. The extension will provide the status of the validations, by type, performed by the server in an RDAP lookup response. |
| | The Action Evidence Boundary for Consequential Agent Effects |
| |
|
Consequential agent actions can cross identity, transport, authorization, policy, and execution systems. Each system can produce a valid artifact while the executor still lacks a safe rule for joining the artifacts to the exact effect, consuming one-time authority, and handling an uncertain outcome. This document defines the Action Evidence Boundary (AEB), an executor-side processing model for that lifecycle. AEB requires native artifact verification, Canonical Action Identifier (CAID) matching, Authorization Evidence Chain (AEC) satisfaction, a separate local authorization decision, durable atomic consumption or reservation, invocation, closed effect outcomes, and authenticated reconciliation. It defines no receipt or token format, no policy language, no universal evidence taxonomy, and no new registry. Native workload credentials, message signatures, attested per-action tokens, permit records, authorization receipts, and status mechanisms retain their own semantics and verifiers. |
| | AgentEnvelope: Derived Authority and Legitimacy for Autonomous Systems |
| |
|
AgentEnvelope defines a deterministic derived-authority model for autonomous and action-performing systems. Instead of issuing bearer credentials from a central authority, AgentEnvelope derives scoped action capabilities from customer-held custody material and canonical action envelopes. A verifier can check an action signature against a public action record without receiving roots, seeds, private keys, mint material, or hosted service access. This revision extends the model with legitimacy: a governance state that records whether a cryptographically valid authority remains admissible under current policy, evidence, time, and operating context. Legitimacy separates provenance from present-tense authorization. A command can remain signed and verifiable while becoming illegitimate because operating facts, policy, or evidence changed. For autonomous-system deployments, derived authority and legitimacy support an IAM model concerned with authority, admissibility, accountability, and audit for actors that perform actions, including AI agents, workflows, bots, microservices, devices, robots, serverless workers, and multi-agent systems. |
| | Write-once Append-only Receipt Digests (WARD): A Content-Free Hash-Chain Witnessing Protocol for Agentic AI Systems |
| |
|
Write-once Append-only Receipt Digests (WARD) defines a minimal, interoperable protocol for producing tamper-evident, content-free hash-chain witnesses over events from agentic AI systems. WARD observes events from companion protocols (Agent Envelope Exchange (AEE) messages, Agent Orchestration Control Layers (AOCL) decisions, and Verifiable Operations Ledger and Trace (VOLT) evidence records) and produces cryptographically linked receipts that prove specific events existed at specific points in time, without storing any event content. WARD entries record only source identifiers and payload hashes, never raw payloads, secrets, or personally identifiable information. Entries are linked via SHA-256 hash chains anchored by deterministic genesis hashes. Periodic checkpoints called "tips" may be signed with Ed25519 and published to external append-only stores (sinks) for independent verification. A meta-chain pattern allows witnessing tips from multiple sub-chains, providing deployment-wide integrity from a single verification point. The protocol is designed as a passive observer: witnessing never blocks, delays, or modifies the source event pipeline. WARD failures are logged but never disrupt AEE transport, AOCL decisions, or VOLT recording. This fire-and-forget integration model ensures that witnessing adds tamper-evidence guarantees without introducing operational risk. |
| | The Checkpointed Local Log (CLL) |
| |
|
Many systems emit individually signed records — receipts, attestations, statements — and store them locally. Each record verifies on its own, but the collection proves nothing: records can be deleted, reordered, or created after the fact without detection. This document specifies the Checkpointed Local Log (CLL): a producer- operated append-only log, built on the Merkle Mountain Range structure whose COSE proof formats are specified in [I-D.bryce-cose-receipts-mmr-profile], together with a small signed checkpoint that commits to the log's entire history. Records of any format are appended as they are 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 precisely, and narrowly, what such a log does and does not establish. This document defines the log discipline and the checkpoint structure; it defines no new proof formats, no transparency service behavior, and no payload semantics. |
| | An EAT Profile for Composite Platform Attestation |
| |
|
This document defines an Entity Attestation Token (EAT) profile for composite platform attestation. A Lead Attester, such as a platform Root of Trust, produces a single signed composite EAT that carries its own measurements and cryptographic digests committing to detached, native evidence collected from peripheral sub-attesters. The full sub-attester evidence -- Security Protocol and Data Model (SPDM) signed measurements, device-emitted EATs, or SPDM-carried TCG DICE Concise Evidence -- is conveyed verbatim as detached Claims-Sets in a Detached EAT Bundle. This yields a single, freshness-bound, platform-scoped attestation artifact that a Verifier can appraise against platform-composition endorsements, even when the evidence is collected and conveyed by an untrusted mediator. |
| | SD-JWT-based Verifiable Digital Credentials (SD-JWT VC) |
| |
|
This specification describes data formats as well as validation and processing rules to express Verifiable Digital Credentials with JSON payloads with and without selective disclosure based on the SD-JWT format. |
| | Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Packet Optical Integration (POI) |
| |
| | draft-ietf-teas-actn-poi-applicability-20.txt |
| | Date: |
31/08/2026 |
| | Authors: |
Fabio Peruzzini, Jean-Francois Bouquier, Italo Busi, Daniel King, Daniele Ceccarelli |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
This document explores the applicability of the Abstraction and Control of TE Networks (ACTN) architecture to Packet Optical Integration (POI) within the context of IP/MPLS and optical internetworking. It examines the YANG data models defined by the IETF that enable an ACTN-based deployment architecture and highlights specific scenarios pertinent to Service Providers. Existing IETF protocols and data models are identified for each multi-technology scenario (packet over optical), particularly emphasising the Multi-Domain Service Coordinator to Provisioning Network Controller Interface (MPI) within the ACTN architecture |
| |
|
| |
| | CCNx Content Versioning |
| |
|
This document defines a method for content versioning in CCNx, enabling the differentiation of content published under the same name using version numbers. This document updates RFC8569 [RFC8569] and RFC8609 [RFC8609]. |
| | YANG Data Model for IS-IS SRv6 |
| |
|
This document defines a YANG data model that can be used to configure and manage IS-IS Segment Routing over the IPv6 Data Plane. |
| | Safe(r) Limited Domains |
| |
|
Documents describing protocols intended solely for use within "limited domains" often rely on edge filtering at every boundary node to prevent domain-internal traffic from leaking to the global Internet (and vice versa). Relying purely on administrative filtering creates "fail-open" designs that are susceptible to configuration errors, ACL bypass, and hardware table exhaustion. This document describes design principles and concrete mechanisms that allow limited-domain protocols to "fail-closed" by default. By leveraging Layer-2 encapsulation identifiers (such as dedicated or extended EtherTypes), link-local address scoping, and / or Hop-Limit boundaries, protocol designers can significantly reduce the operational and security risks associated with limited domain protocols. These mechanisms are not applicable to all protocols intended for use in a limited domain, but if implemented on certain classes of protocols, can significantly reduce the risks. |
| | EVN6: Mapping of Ethernet Virtual Network to IPv6 Underlay for Transmission |
| |
| | draft-xls-intarea-evn6-06.txt |
| | Date: |
30/08/2026 |
| | Authors: |
Chongfeng Xie, Jibin Sun, Xing Li, Congxiao Bao, Mark Smith |
| | Working Group: |
Individual Submissions (none) |
|
This document describes a mechanism of mapping of Ethernet Virtual Network to IPv6 Underlay for transmission. Unlike the existing methods, this approach places the Ethernet frames to be transmitted directly in the payload of IPv6 packets, i.e., L2 over IPv6, and uses stateless mapping to generate IPv6 source and destination addresses from the host's MAC addresses, the Ethernet Virtual Network identifier and site prefixes. The IPv6 packets generated in this way carry Ethernet frames and are routed to the destination site across the public IPv6 network. |
| | EVPN Route Types and Procedures for EVN6 |
| |
|
EVN6 is a mechanism designed to provide Ethernet connectivity to customer sites dispersed on public IPv6 networks. At the data layer, EVN6 encapsulates Ethernet frames directly in the payload of IPv6 packets, and dynamically generates the IPv6 addresses of the IPv6 header using host MAC addresses and other information, then sends them into IPv6 network for transmission. This document proposes extensions to EVPN for EVN6, including two new route types and related procedures. |
| | Path Computation Element Communication Protocol for Source Address Validation |
| |
| | draft-song-pce-pcep-sav-03.txt |
| | Date: |
30/08/2026 |
| | Authors: |
Xueyan Song, Weiqiang Cheng, 1211176911910469110103 |
| | Working Group: |
Individual Submissions (none) |
|
This document presents a method of Path Computation Element (PCE) for Source Address Validation (SAV) in networks. It extends Path Computation Element Communication Protocol (PCEP) to support SAV policy distribution and synchronization between PCEP speakers for threat mitigation for source address spoofing. |
| | OAuth Profile for Delegated AI Agent Authorization |
| |
|
AI agents increasingly invoke protected APIs on behalf of human users. This document defines an OAuth profile for identifying an agent client instance, obtaining an authenticated user's consent, issuing resource-bound and sender-constrained access tokens, attenuating authority through OAuth Token Exchange, and rotating refresh tokens safely. The profile uses existing OAuth and JOSE mechanisms wherever possible and defines no new JWT claims or OAuth endpoints. Operational facilities such as policy engines, audit stores, budgets, event streams, and credential vaults are outside the interoperable core. Grantex is an incomplete reference implementation and is not required for conformance. |
| | IntelliNode: In-Network Intelligent Scheduling Extensions for CATS |
| |
|
This document introduces IntelliNode, an in-network intelligent scheduling mechanism built upon the Computing-Aware Traffic Steering (CATS) framework. Modern large-scale AI training and inference heavily rely on distributed heterogeneous clusters (GPU/CPU/FPGA). However, existing networks lack awareness of tensor semantics, training phases, and heterogeneous computing capabilities, leading to high communication latency, low resource utilization, and pipeline stalls. IntelliNode shifts away from the traditional passive scheduling paradigms that rely on probes and controllers. By bypassing traditional paths and integrating FPGAs alongside programmable Switch ASICs, it constructs a rapid data-plane closed loop of "Perception- Inference-Decision-Execution". This architecture performs feature extraction at line rate, leverages lightweight prediction models to infer short-term network behavior, and drives real-time heuristic scheduling decisions (e.g., path selection, tensor slicing, and compute matching). This document defines the four core functional layers and extension signaling that support this architecture, laying the foundation for an AI-native, scalable distributed computing network. |
| | Semantic-Driven Traffic Shaping Contract for AI Networks |
| |
|
This document defines a "Semantic-Driven Shaping Contract". Traditional network protocols treat AI training and inference traffic as opaque byte streams, leading to highly inefficient scheduling. This contract allows applications or distributed training frameworks to explicitly pass "minimum necessary semantics" to the underlying network. In exchange, the network commits to executing fine-grained, differentiated forwarding and resource allocation actions for tensor flows with diverse semantics, based on predefined rules and global real-time states. This model significantly improves overall resource utilization and task completion times in heterogeneous computing networks, cross-domain intelligent computing centers, and integrated training-inference scenarios. |
| | Cursor-Based Pagination and Deferred Retrieval for Multi-Valued Attributes in SCIM 2.0 |
| |
|
[RFC7643] defines Group.members with the returned: default characteristic, so a conformant service provider is required to return the attribute in response to GET /Groups/{id}. [RFC7644] defines no bound on the number of values that attribute may contain. A service provider holding a group with millions of members therefore has no conformant and interoperable way to answer a request that a client is entitled to make. In practice providers diverge: they truncate silently, reject the request, omit the attribute, or fail. A client cannot discover in advance which behavior it will encounter. This document defines that missing behavior. It specifies discovery so a client can learn how a service provider treats a high- cardinality attribute, a bounded response with a defined continuation contract, and rules preventing a partial representation from being mistaken for complete resource state. The mechanism has two forms. A request for one resource returns a bounded page of one protected multi-valued attribute with an opaque cursor when more values exist. A collection search returns parent resources without loading protected attributes, each carrying an authoritative link for retrieving that attribute. The attribute remains part of its parent resource; this document does not create a top-level resource for each attribute value, and it is not a substitute for doing so where independent relationship lifecycle or cross-collection query is required (Section 16.4). Although the mechanism is defined generally and applies to any complex multi-valued attribute a service provider designates as protected, the attributes that reach problematic sizes in deployed SCIM services are predominantly Group.members and User.groups among those defined in [RFC7643], together with implementation-specific assignment attributes (Section 3). This document updates [RFC7643] and [RFC7644]. It adds attributes to existing structures defined by those documents and defines attribute- return behavior that replaces the requirements of Section 3.9 of [RFC7644] within a negotiated scope. It does not change the behavior of deployments that do not implement it: the modified attribute- selection behavior described in Section 4 applies only between a service provider that has advertised this capability and a client for which deferred retrieval has been established through the negotiation mechanisms defined in this document. It defines discovery metadata, the attributeCount and attributeCursor query parameters, response metadata, processing and compatibility rules, mutation safety, error handling, cursor security, and operational limits. |
| | Mitigating HTTP/3 Connection Contamination in Multi-Tenant and CDN-Fronted Deployments |
| |
|
HTTP/3 [RFC9114] clients commonly reuse ("coalesce") an existing QUIC [RFC9000] connection for requests to a second origin when the TLS certificate presented on that connection is also valid for the second origin, even though the two origins may route to entirely different backends. This document describes "connection contamination," a class of security exposure that arises when a routing layer -- reverse proxy, load balancer, or CDN edge -- determines backend routing using a signal established at connection setup rather than re-validated per request. Under that condition, a coalesced connection can be used to reach an unintended backend origin, potentially enabling cross-tenant data leakage, authentication bypass, and response-queue interference analogous to HTTP request smuggling. This document defines the underlying mechanism, characterizes the attacker model, distinguishes connection contamination from related QUIC exposures, and provides normative operational guidance for implementers and operators of HTTP/3-terminating infrastructure. |
| | AegisFS: AI-Driven Programmable Secure File Runtime and Intelligent Workspace Architecture with Octal OpCode Processing and Policy-Driven Language Architecture |
| |
|
This document specifies AegisFS, a programmable secure file and folder runtime that transforms ordinary filesystem objects into intelligent, policy-driven, state-aware, execution-aware, and behavior-aware security objects. This draft introduces two novel technical contributions: |
| | Embargoing Archive Publication using robots.txt |
| |
|
Web sites often block archiving crawlers because they host time- sensitive information. This specification documents a robots.txt extension, "Archive-Embargo", that can be used to request that such crawlers delay publication of information. This document updates RFC 9309 to add two directives that support embargoes. |
| | PSHMP Core: Decentralized L4 Overlay for Resilient Data Delivery and Proactive Self-Healing Networks |
| |
|
PSHMP Core is a decentralized data delivery and proactive self- healing network core designed for distributed systems operating over existing IP infrastructure. PSHMP Core provides an intelligent network layer above the existing IP network and enables distributed nodes to participate in dynamic multi-hop data delivery without requiring changes to the underlying Layer 3 routing infrastructure. The architecture is designed around decentralized path selection, continuous node and path assessment, dynamic relay chains, proactive recovery, and diversity-aware reconstruction of delivery paths. The system can detect degradation of network participants and reconstruct affected delivery paths before or during service degradation. This approach is intended to reduce recovery time, improve resilience, and maintain reliable data delivery in environments where individual nodes, paths, or network segments may become unstable. This document provides a high-level architectural overview of PSHMP Core, its primary components, operating principles, and potential application areas. This document intentionally does not disclose implementation-specific algorithms, internal scoring details, proprietary optimization techniques, or other information that may be required for commercial implementation. |
| | Export of BGP Prefix Origin Validation in IP Flow Information Export (IPFIX) |
| |
|
This document defines an IP Flow Information Export (IPFIX) Information Element for monitoring the state of Resource Public Key Infrastructure (RPKI) based BGP Prefix Origin Validation. The Information Element enables network operators to collect and analyze BGP route validation states (valid, invalid, not-found) to facilitate the detection of potential route hijacks improving network observability and security. |
| | Export of Segment Routing Path Segment Identifier (PSID) Information in IPFIX |
| |
|
This document introduces new IPFIX Information Elements to identify the Segment Routing (SR) Path Segment Identifier (PSID) for SR-MPLS and SRv6 paths identification. |
| | Automatically Connecting Stub Networks to Unmanaged Infrastructure |
| |
| | draft-ietf-snac-simple-12.txt |
| | Date: |
30/08/2026 |
| | Authors: |
Ted Lemon, Jonathan Hui, Esko Dijk |
| | Working Group: |
Stub Network Auto Configuration for IPv6 (snac) |
|
This document specifies a set of practices for using IPv6 networking to automatically connect stub networks to adjacent infrastructure networks, even if they do not otherwise use IPv6. This is applicable in cases such as constrained (Internet of Things) networks where there is a need to provide functional parity of service discovery and reachability between devices on the stub network and devices on an adjacent infrastructure link (for example, a home network). |
| |
|
| |
| | Notable CBOR Tags |
| |
|
The Concise Binary Object Representation (CBOR, RFC 8949) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. In CBOR, one point of extensibility is the definition of CBOR tags. RFC 8949's original edition, RFC 7049, defined a basic set of 16 tags as well as a registry that can be used to contribute additional tag definitions [IANA.cbor-tags]. Since RFC 7049 was published, at the time of writing some 250 definitions of tags and ranges of tags have been added to that registry. The present document provides a roadmap to a large subset of these tag definitions. Where applicable, it points to an IETF standards or standard development document that specifies the tag. Where no such document exists, the intention is to collect specification information from the sources of the registrations. After some more development, the present document is intended to be useful as a reference document for the IANA registrations of the CBOR tags the definitions of which have been collected. |
| | Verification of Routes Using Region Authorization |
| |
|
BGP routing security is a critical issue affecting the stability and reliability of Internet services. Existing mechanisms, including Route Origin Authorization (ROA) and Autonomous System Provider Authorization (ASPA), effectively mitigate route origin hijacking, path hijacking, and route leaks in general scenarios. However, in real-world deployments, large Internet Service Providers (ISPs) managing multiple Autonomous Systems (ASes) remain vulnerable. Attacking networks can exploit carefully crafted routes to bypass ROA and ASPA validations, causing traffic hijacking 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. |
| | ASPA Verification in the Presence of Regionalized AS-Relationships |
| |
|
Autonomous System Provider Authorization (ASPA) defines an RPKI-based methodology to validate the AS_PATH of BGP routes based on a global Customer-to-Provider (C2P) relationship model. However, in commercial Internet routing, two Autonomous Systems (ASes) may establish distinct business relationships across different geographical regions or interconnection points (e.g., Customer-to- Provider in one region, but Peer-to-Peer in another). Such regionalized or hybrid AS-relationships can lead to incorrect ASPA validation results (e.g., 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. |
| | IOAM Trace Option Extensions for Incorporating the Alternate-Marking Method |
| |
|
In situ Operation, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information, which leverages IOAM Trace Option to incorporate IOAM data fields into in- flight data packets. The Alternate-Marking method is used to measure performance metrics on live traffic, such as packet loss, delay, and jitter. This document extends IOAM Trace Option for incorporating the Alternate-Marking method to augment IOAM in performance measurement. |
| | IOAM Direct Exporting (DEX) Option Extensions for Incorporating the Alternate-Marking Method |
| |
|
In situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information. Specifically, passport-based IOAM allows telemetry data generated by each node along the path to be pushed into data packets when they traverse the network, while postcard-based IOAM allows IOAM data generated by each node to be directly exported without being pushed into in-flight data packets. The Alternate-Marking method is used to measure performance metrics on live traffic, such as packet loss, delay, and jitter. This document extends IOAM Direct Export (DEX) Option-Type to integrate the Alternate-Marking Method into IOAM to augment IOAM in performance measurement. |
| | Advertise SRv6 Locator Information by IPv6 Neighbor Discovery |
| |
|
In an SRv6 network, each SRv6 segment endpoint has at least one SRv6 Locator. Through the SRv6 locator routes, other SRv6 segment nodes can steer traffic to that node. This document describes a method for an SRv6 endpoint (e.g., a host or a 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 approach eliminates 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. |
| | An Upgraded TCP Session Type |
| |
|
Currently, TCP maintains ordinary sessions (SES-O) in which ordinary segments (SEG-O) are exchanged. Each SEG-O can accommodate up to 40 octets of options. In the future, applications may require more than 40 octets of options. For example, an application may use a 36-byte TCP Authentication Option (TCP-AO), leaving insufficient space for other required options. Therefore, this document describes an experiment in which upgraded sessions (SES-U) and upgraded segments (SEG-U) are introduced. Each SEG-U can accommodate up to 1,016 octets of Individual Options. |
| | Proof of Sovereign Integrity (PSI): A Cryptographic Protocol for Verifiable AI Regulatory Compliance |
| |
|
This document specifies the Proof of Sovereign Integrity (PSI) Protocol, version 1.2, a cryptographic framework enabling organizations to prove compliance with AI regulations (including the EU AI Act 2024/1689, NIST AI RMF, UK AI Safety Institute guidelines, and equivalent frameworks) without disclosing proprietary model architectures, training data, or inference logic. PSI achieves this through a combination of 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 (MPC) consensus mechanism with 2/3 threshold verification. This revision documents a deployed public reference implementation and adds optional post-quantum signature profiles and Bitcoin timestamp anchoring. |
| | Cryptographic Algorithms That Produce 256-bit MACs For Use With TCP-AO |
| |
|
RFC5926 creates a list of cryptographic algorithms that can be used with TCP-AO. This document expands that list, adding two Message Authentication Code (MAC) algorithms, HMAC-SHA256 and KMAC256. For each MAC algorithm, a corresponding Key Derivation Function (KDF) is also added. The MAC algorithms described by this document produce 256-bit (i.e., 32-byte) MACs. When 32-byte MACs are encoded in TCP-AO, the TCP-AO consumes 36 of the 40 bytes available for TCP options. |
| | Operational Semantics for CATS Metric Consumption |
| |
|
The CATS framework introduces computing-related information into traffic steering decisions. Existing work defines how such metrics are represented, distributed, and used within the CATS architecture. However, it does not fully address whether a metric remains suitable for use at the point of consumption. This document introduces a set of operational semantics for CATS metrics, including Freshness, Operational acceptability, and Assurance exposure. These semantics describe whether a metric remains temporally aligned with the underlying condition, whether it remains suitable for operational use in steering, and whether degraded consumption is externally visible to management or OAM functions. The document further explains how these semantics apply across centralized, distributed, and hybrid deployments, including cases where different metric sources contribute under different conditions. The goal is to provide a consistent basis for interpreting metric usability in CATS without introducing a new metric level or prescribing a single derivation method. Implementations may determine when degradation occurs, while the resulting consumption condition can still be represented and understood consistently across CATS functions. |
| | AI Agent Identity Certificate (AIC) Extension for X.509 v3 |
| |
|
This document defines the AI Agent Identity Certificate (AIC) Extension for X.509 v3 certificates. The AIC extension enables binding of an AI Agent's cryptographic identity to a natural person (principal), providing cryptographic evidence that can support attribution of AI-autonomous actions to a principal. This specification intentionally separates cryptographic delegation from authorization semantics: AIC defines the cryptographic binding between agent and principal, while all capability and policy semantics are defined externally by vendors, industries, or regulators. The extension is identified by the IANA Private Enterprise Number 66257 assigned to the document author's organization. The AIC extension carries agent identity fields (agentId, delegationMode), a principal identifier (principalUid) linking the agent to the authorizing principal, a container-based capability declaration, authorization boundary constraints, and delegation authorization evidence with replay protection. A companion PrincipalAuthorization extension anchors Principal-side grant declarations and delegation policies. An authorizationConstraints container provides offline-verifiable execution boundaries (IP range, window). An extensibility framework allows vendor-specific and user- specific metadata. This document specifies the ASN.1 module, OID registration, field semantics, delegation model, and extensibility framework. Security considerations for deployment in regulated enterprise environments are discussed. |
| | Internationalized Domain Names for Applications 2008 (IDNA2008) and Unicode 18.0.0 |
| |
|
This document describes the changes between Unicode 12.0.0 and Unicode 18.0.0 in the context of IDNA2008. Some additions and changes have been made in the Unicode Standard that affect the values produced by the algorithm IDNA2008 specifies. The review assigns the derived property value "UNDER REVIEW" to certain code points. This is added as exceptions to the algorithm for IDNA2008 that allows adding exceptions to the algorithm for backward compatibility exceptions. This document provides the necessary tables to IANA to make its database consistent with Unicode 18.0.0. This version of this document is based on pre-release data. Unicode 18.0.0 has not been released, and every figure here that concerns it is provisional and must be regenerated against the released files. See the note at the top of this document. All values in this document are computed from the Unicode Character Database files listed in Appendix H, by applying the algorithm in RFC 5892 Section 3 directly to those files. No derived property table produced by anyone else is used as input. Section 3 describes the derivation and Appendix G compares the result with the derivation published by the Unicode Consortium. |
| | BEST: The Behavioral State Protocol |
| |
|
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"; 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 -- allowing independent implementations across any runtime, language, or transport to interoperate without bespoke integration. |
| | General-Purpose Compression via Mathematical Functions (GCMF) |
| |
|
This document specifies General-Purpose Compression via Mathematical Functions (GCMF), a lossless compression format that represents sequences of data using mathematical functions and associated parameters. GCMF attempts to represent a sequence using a compact mathematical representation rather than storing every value explicitly. This document defines the GCMF data format, function types, encoding rules, decoding procedure, and interoperability requirements. |
| | Ratcheted CoAP: A Forward-Secure Delta over OSCORE for Highly Constrained Wake-Send-Sleep Devices |
| |
|
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 ([RFC8613]): instead of a single long-lived Sender Key, RCOAP derives a fresh symmetric key for every message via a one-way hash ratchet. This bounds 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. RCOAP is explicitly scoped to a narrow niche left open between OSCORE and EDHOC ([RFC9528]): devices for which even EDHOC's one-time handshake cost is disproportionate to their message rate or compute budget. This document is a first individual submission, has not been reviewed by the IETF, and requests feedback in particular from the LAKE and CoRE working groups on whether this gap is real and worth standardizing, or already adequately covered. |
| | OpenID Federation Node Administration Protocol |
| |
|
This document specifies a compact HTTP application programming interface 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 used by operators and control-plane software 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 a large set of per-claim endpoints. Five resources cover node identity, Federation Entity Keys, the node's Entity Configuration, Immediate Subordinates, and Trust Mark issuance. |
| | Modeling EVPN MAC-Mobility Sequence State as a Conflict-Free Replicated Data Type |
| |
|
EVPN MAC Mobility, as carried in the MAC Mobility Extended Community defined by [RFC7432], uses a per-MAC sequence number to let PEs agree on the most recent location of a moving host. [I-D.ietf-bess-evpn-umr-mobility] extends this to cross-data-center moves via gateways, and already specifies, in some detail, how ordinary intra-DC and inter-DC moves are kept consistent: each gateway maintains two independent MAC Mobility sequence counters per host (one intra-DC, one inter-DC) specifically so that a purely local move does not have to be reconciled against the interconnect network's state. What that document does not specify is what a gateway does if it fails after locally resetting its intra-DC counter to zero (Section 5.2, the step taken when a host is confirmed to have left every local PE) but before propagating that fact onward; no failure-handling or crash-recovery text exists anywhere in the document. This document shows that this narrower, but concretely unaddressed, gap is a special case of a data type with known, formally proven convergence properties, the Last-Writer-Wins Register, one member of the Conflict-Free Replicated Data Type (CRDT) family, and proposes modeling the per-gateway mobility sequence state that way so that a mid-reset gateway crash is recovered from as a consequence of the data type's algebra rather than requiring a new, separately specified recovery procedure. |
| | Comparable Sequence Numbers Across Publishers in YANG Datastore Telemetry |
| |
|
YANG Datastore Telemetry, YANG-Push version 2 [I-D.ietf-netconf-yang-push-2], assigns each publisher a monotonically increasing sequence number so a receiver can detect loss and reordering. The current design leaves two questions unanswered: what happens when the counter wraps, and how a receiver aggregating records from more than one publisher is to compare sequence numbers that were never defined to be comparable across publishers in the first place. Both questions have already been studied, and largely settled, in the distributed systems literature under the heading of logical and hybrid logical clocks, and in deployed streaming systems under the heading of offset and epoch numbering. This document evaluates three existing causal- ordering primitives against YANG-Push's specific constraints and proposes adopting a Hybrid Logical Clock so that the wraparound and cross-publisher comparison problems are removed by construction rather than patched with a wider counter. |
| | Applicability of Consistent Hashing to Designated Forwarder Election Scope Transitions in EVPN |
| |
|
[RFC8584] defines Highest Random Weight (HRW) as the algorithm for Designated Forwarder election in EVPN, and, in Section 3.1, names the Consistent Hashing family of algorithms as addressing the same object-to-server mapping problem before explicitly declining to evaluate them: "these will not be considered here." [I-D.ietf-bess-evpn-per-mcast-flow-df-election] subsequently introduces a scope transition, from per-(ES,VLAN) to per- (ES,VLAN,S,G) election, that is precisely a key-space-resizing event of the kind Consistent Hashing was designed to bound churn for. This document proposes the applicability analysis RFC 8584 declined to make: it defines a DF-churn metric, states HRW's and Consistent Hashing's known theoretical guarantees against it, and sets out an evaluation methodology, using bounded-load Consistent Hashing as the specific comparison point, given multicast group popularity is known to be highly non-uniform in deployed networks. |
| | A YANG Extension for Declaring the Comparability Scope of Operational State |
| |
|
Several YANG modules currently in progress across multiple IETF working groups define counters, gauges, and other measured values that are exported from a network element and compared, summed, or averaged by a remote collector, either against the same node's history or against values from a different node. 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 this determination is currently made, inconsistently or not at all, in prose. This document defines a YANG extension statement, "csc:comparability-scope", a four-value scope lattice, and a compatibility rule that lets a schema-aware tool statically detect an illegal aggregation across incomparable scopes, without waiting for it to happen at a collector. |
| | Cryptographic Algorithms That Produce 128-bit MACs For Use With TCP-AO |
| |
| | draft-ietf-tcpm-tcp-ao-algs-07.txt |
| | Date: |
29/08/2026 |
| | Authors: |
Ronald Bonica, Tony Li, Ping Chen, Prashant Kumar, Reji Thomas, A Nayak, Ayan Banerjee |
| | Working Group: |
TCP Maintenance and Minor Extensions (tcpm) |
|
RFC5926 creates a list of cryptographic algorithms that can be used with TCP-AO. This document expands that list, adding two Message Authentication Code (MAC) algorithms, HMAC-SHA256-128 and KMAC256-128. For each MAC algorithm, a corresponding Key Derivation Function (KDF) is also added. The MAC algorithms described by this document produce 128-bit (i.e., 16-byte) MACs. When 16-byte MACs are encoded in TCP-AO, the TCP-AO consumes 20 of the 40 bytes available for TCP options. |
| |
|
| |
| | Automated Certificate Management Environment (ACME) Profiles Extension |
| |
|
This document defines how an ACME Server may offer a selection of different certificate profiles to ACME Clients, and how those clients may indicate which profile they want. |
| | DomainKeys Identified Mail Signatures v2 (DKIM2) |
| |
|
DomainKeys Identified Mail v2 (DKIM2) permits a person, role, or organization that owns a signing domain to document that it has handled an email message by associating their domain with the message. This is achieved by providing a hash value that has been calculated on the current contents of the message and then applying a cryptographic signature that covers the hash values and other details about the transmission of the message. Verification is performed by querying an entry within the signing domain's DNS space to retrieve an appropriate public key. As a message is transferred from author to recipient systems that alter the body or header fields will provide details of their changes and calculate new hash values. Further signatures will be added to provide a validatable "chain". This permits validators to identify the nature of changes made by intermediaries and apply a reputation to the systems that made changed. DKIM2 also allows recipients to detect when messages have been unexpectedly "replayed" and will ensure that Delivery Status Notifications are only sent to entities that were involved in the transmission of a message. |
| | On-Path Telemetry for Active Performance Measurements |
| |
|
This document describes how to employ active test packets in combination with Hybrid Methods to perform On-path Active Performance Measurements. This procedure allows Hop-By-Hop measurements in addition to the Edge-To-Edge measurements. |
| | Use of Variable-Length Output Pseudo-Random Functions (PRFs) in the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
This document specifies the use of variable-length output Pseudo- Random Functions (PRFs) in the Internet Key Exchange Protocol Version 2 (IKEv2). Current IKEv2 specification relies on traditional PRFs with fixed output length for key derivation and uses iterative application of a PRF (called "prf+") in cases when longer output is required. Appearance of PRFs that can output as much bits as requested allows to streamline the key derivation functions of IKEv2. This document updates RFC 7296 and RFC 7815 for the cases when variable-length output Pseudo-Random Functions are used in IKEv2 and its extensions. |
| | Filtering Out RPKI Data by Type based on Enhanced SLURM Filters |
| |
|
Simplified Local Internet Number Resource Management with the RPKI (SLURM) helps operators create a local view of the global RPKI by generating sets of filters and assertions. This document proposes to filter out RPKI data by type based on enhanced SLURM filters. Only the RPKI data types that the network or routers are interested in will appear in the Relying Party's output. |
| | SSH Support of ML-DSA |
| |
|
This document describes the use of the ML-DSA digital signature algorithms in the Secure Shell (SSH) protocol. Accordingly, this RFC updates RFC 4253. |
| | Network Digital Twin and Agentic AI based Architecture for AI-driven Network Operations |
| |
|
A Network Digital Twin (NDT) provides a network emulation tool usable for different purposes such as scenario planning, impact analysis, and change management. Agentic AI enables dynamic goal-driven execution and adaptive behavior and closed-loop autonomy. By integrating a NDT into network management together with the Agentic AI, it allows the network management activities to take user intent or service requirements as input, automatically assess, model, and refine optimization strategies under realistic conditions but in a risk-free environment. Such environment that operates to meet these types of requirements is said to have AI-driven network operations. AI-driven network operations brings together existing technologies such as Agentic AI and NDT which may be seen as the use of a toolbox of existing components enhanced with a few new elements. This document describes an architecture for AI-driven network operations and shows how these components work together with NDT and Agentic AI capabilities. |
| | A Timescale-Aware Framework for Compute-Aware Task Placement and Traffic Steering in Heterogeneous Geo-Distributed Computing Networks |
| |
| | draft-luan-cats-catpts-01.txt |
| | Date: |
28/08/2026 |
| | Authors: |
Qing Li, Zeyu Luan, Zhuochen Fan, Yong Jiang |
| | Working Group: |
Individual Submissions (none) |
|
Geographically distributed compute-intensive services require coordinated selection of execution sites and wide-area traffic paths. Placement changes slowly because service relocation may involve model loading, state migration, or execution-environment reconfiguration, while traffic splitting can be changed more frequently. This document evolves the CATPTS framework by defining a timescale- aware control architecture for source-compute-destination services. A slow-timescale placement function uses abstracted multipath and failure information to select a compute site. A fast-timescale traffic function then refines the input and output traffic allocations across candidate paths while holding placement fixed. The framework also introduces scenario-based service-loss estimation and an optional Conditional Value at Risk (CVaR) policy for limiting tail loss caused by compute-site or network-link failures. This document specifies architectural principles, information requirements, workflows, and operational considerations; it does not specify protocol extensions or a mandatory optimization algorithm. |
| | Verifiable Identity Claims and Delegation Model (VICDM) |
| |
|
This document defines a conceptual framework for handling identity assertions in application-layer protocols. It introduces a model in which identity on the Internet is optional, but any asserted identity MUST be verifiable. It further defines a delegation mechanism that allows entities to authorize third-party infrastructure to act on their behalf in a verifiable and transparent manner. The goal is to reduce identity misrepresentation while fully preserving the ability for anonymous and pseudonymous interaction. This document does not define a protocol; it defines the principles that protocol specifications SHOULD follow when addressing agent identity. A concrete protocol implementation of these principles is defined in [SAIP]. |
| | A JSON Format for Self-Published IP Geolocation Feeds |
| |
|
This document defines a JavaScript Object Notation (JSON) format for self-published IP geolocation feeds. It updates RFC 8805 by transitioning from the current comma-separated values (CSV) format to a more expressive JSON format, addressing the need for operational extensibility. |
| | Verifiable Data Access Contract (VDAC) |
| |
|
This document specifies the Verifiable Data Access Contract (VDAC), a protocol for cryptographically verifiable bilateral agreement between a content publisher and an automated agent regarding the terms of programmatic data access. VDAC defines the mechanism by which a site issues an access offer, an agent accepts that offer, both parties sign the resulting contract, and per-request references bind individual interactions to agreed terms. VDAC is the protocol-layer realization of the bilateral commitment principle introduced in Section 6.6 of the Verifiable Identity Claims and Delegation Model [VICDM] and operates as a companion specification to the Signed Agent Identity Protocol [SAIP]. This document defines mechanism, not content: VDAC verifies the existence and integrity of an agreement; the substance of what is agreed remains entirely between the contracting parties. VDAC also defines an append-only contract history. Changes to the recorded state of a Contract are recorded as signed change records and associated immutable snapshots; the original Contract Document is never modified. |
| | An Agent Action Capsule Profile for SCITT |
| |
|
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 that were evaluated, the effect that was committed 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. Its Capsule ID can separately be made transparent by registration in a SCITT Transparency Service. A Capsule is recorded on every verdict, including refusals: a blocked or denied Capsule is the auditor-grade evidence that a gate worked. |
| | Multi-Source Corroboration for AI Agent Discovery |
| |
|
AI agents are discovered and identified through independent sources, including registries, name services, DID methods, and catalogs. A single source can misrepresent an agent by omission, withholding a record it holds, or by equivocation, serving different answers to different observers. A signature on a served artifact does not, by itself, defend against either behavior. This document specifies a corroboration procedure that classifies one source's claim about one agent observed from one network vantage; reduces claims to comparable views; diffs claims into findings with deterministic attribution; distinguishes legitimate propagation delay from persistent disagreement; and emits a signed Corroboration Record for every sweep, including agreement, that other evidence formats can bind by digest. The procedure is source-, format-, and layer-agnostic; requires neither cooperation from nor modification of any source; and is verifiable from recorded bytes. |
| | Architectural Requirements for Supporting AI Agents on the Internet |
| |
|
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 and unpredictable model-processing intervals, and cross-domain interaction create requirements that span multiple protocol families. This document describes architectural requirements for supporting AI agents on the Internet 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 Internet protocols over defining a monolithic new agent protocol, and identifies the need for IETF-wide architectural coordination. |
| | Out-of-Path Measurement Methodology for Agent-Initiated Payment Rails |
| |
|
Agent-initiated payments now execute across several settlement rails with materially different finality semantics, authorization primitives and failure modes. Published comparisons of these rails are commonly self-asserted, and commonly do not state a procedure another party could reproduce. This document specifies a measurement methodology for such rails. It defines finality per rail at its ecosystem-canonical reliance level rather than imposing a single definition, separates payment-validation latency from challenge- issuance latency as distinct and non-comparable quantities, and specifies an out-of-path observation posture in which the measuring party never holds funds, keys or signing authority. It states reporting requirements, including mandatory disclosure of limitations and a prohibition on merging observer-clock and payer-clock measurements. It defines no payment protocol and recommends no rail. |
| | Trusted Artifact Provenance (TAP): A Producer,Verifier,and Sealer Contract for Attestation-Gated Reconstruction of Stateful Assets |
| |
|
The Remote ATtestation procedureS (RATS) architecture (RFC 9334) defines how Evidence is conveyed from an Attester to a Verifier and how the resulting Attestation Results are conveyed to a Relying Party. It deliberately stops at the point where a Relying Party has appraised Attestation Results. This document specifies Trusted Artifact Provenance (TAP), a consumer of Attestation Results that defines what happens next in one specific and recurring case: releasing sealed key material to a process that reconstructs a stateful asset inside an attested environment, and recording the release decision as an auditable object. TAP defines three contracts. The Producer contract governs how an artifact is sealed and bound to the attested identity of the environment that produced it. The Sealer contract governs the attestation-gated release of key material to a reconstruction environment. The TAP Verifier contract governs after-the-fact appraisal of provenance and release records. TAP does not define an appraisal policy language, does not define a new Evidence format, and does not replace any part of RFC 9334. |
| | Continuity Receipts: Registering the Recovery of a Stateful Asset as a Signed Statement in a Transparency Service |
| |
|
A Transparency Service as defined by RFC 9943 registers Signed Statements about Artifacts and returns Receipts, encoded per RFC 9942, that prove registration in an append-only log. The Statements registered today typically describe how an Artifact was built, tested, or released. They do not describe what happens after that: the Artifact is sealed, moved, lost, and later re-created somewhere else, and that re-creation leaves no independently checkable trace. This document defines a Continuity Receipt: the Receipt obtained when a recovery event is registered as a Signed Statement in a Transparency Service. It specifies the Subject and the required claims of a recovery Statement, how Attestation Results from RFC 9334 remote attestation are carried or referenced by it, and how a sequence of such Statements under one Subject forms a verifiable continuity chain across the lifetime of a stateful asset. The document is deliberately narrow. It defines a payload and a set of claims, not a new Transparency Service, not a new verifiable data structure, and not a new attestation format. It also records, rather than conceals, the divergence between what it specifies and what the reference implementation currently does. |
| | Strict Only to Customer (OTC) Verification on Route Server Sessions |
| |
|
RFC 9234 specifies how an AS receiving a route from a lateral Peer can check if route was lekaed, but doesn't specify any checks for routes received from Route Server (RS). This makes quility of filtering dependent on whether the RS implements RFC 9234. This document updates RFC 9234 by adding complimentary ingress check by RS-Client. |
| | Hierarchical Deterministic Keys |
| |
|
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 mechanism 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. |
| | SRv6 for Redundancy Protection |
| |
|
Redundancy Protection is a generalized protection mechanism to achieve high reliability for services provided in Segment Routing networks. The mechanism uses the "Live-Live" methodology, i.e., multiple copies of the data packets are sent on different paths to provide protection. This document introduces one new SRv6 Segment Endpoint Behavior, the associated Headend Encapsulation Behaviors and the associated Redundancy Policy to provide replication and elimination functions on specific network nodes by leveraging SRv6 Network Programming capabilities. |
| |
|
| |
| | Benchmarking Methodology for Segment Routing (SR) |
| |
| | draft-ietf-bmwg-sr-bench-meth-08.txt |
| | Date: |
27/08/2026 |
| | Authors: |
Giuseppe Fioccola, Eduard, Paolo Volpato, Luis Contreras, Bruno Decraene |
| | Working Group: |
Benchmarking Methodology (bmwg) |
|
This document defines a methodology for benchmarking Segment Routing (SR) performance for Segment Routing over IPv6 (SRv6) and MPLS (SR- MPLS). |
| | Fast Network Notifications Problem Statement |
| |
| | draft-ietf-fann-problem-statement-00.txt |
| | Date: |
27/08/2026 |
| | Authors: |
Jie Dong, Mike McBride, Francois Clad, Zhaohui Zhang, Yongqing Zhu, Xiaohu Xu, Rui Zhuang, Ran Pang, Hao Lu, Yadong Liu, Luis Contreras, DURMUS Mehmet, Reshad Rahman |
| | Working Group: |
Fast Network Notifications (fann) |
|
Many network applications, ranging from Artificial Intelligence (AI) /Machine Learning (ML) training/inference to cloud services, require networks with various combination of high bandwidth, low delay and low jitter and minimal packet loss in data transfer. This requires that the networks must rapidly adapt to the presence of faults, degradation and congestion. However, existing routing and traffic management mechanisms often face limitations in responsiveness, coverage, and operational complexity, particularly in large-scale and high-bandwidth network environments (e.g. data center (DC) and data center interconnect (DCI)). A good and timely understanding of network conditions can help to enable faster response to critical events, so as to enable the selection of paths with reduced latency and improve network utilization. This document describes the gap analysis and the need for fast network notification, and identifies the set of problems which a fast network notification solution needs to address. |
| | SR Policies Extensions for Path Segment and Bidirectional Path in BGP-LS |
| |
|
This document specifies the way of collecting configuration and states of SR policies carrying Path Segment and bidirectional path information by using BPG-LS. Such information can be used by external conponents for many use cases such as performance measurement, path re-optimization and end-to-end protection. |
| | IPv6-Resolved IPv4 Gateway |
| |
|
This document specifies host behavior enabling IPv4 communication for dual-stack hosts on IPv6-only segments, without subnets, ARP, tunneling, or translation. Hosts that receive 192.0.0.11/32 as their IPv4 default gateway address resolve the next-hop link-layer address from the IPv6 neighbor cache rather than via ARP. IPv4 packets are forwarded natively, end-to-end. The mechanism is incrementally deployable alongside unmodified hosts with no changes to DHCPv4 infrastructure. This document requests the allocation of 192.0.0.11/32 in the IANA IPv4 Special-Purpose Address Registry to support this mechanism. |
| | Proposal for Updates to Guidance on Packet Reordering |
| |
|
Several link technology standards mandate that equipment guarantee in-order delivery of layer 2 frames, apparently due to a belief that this is required by higher layer protocols. To meet this requirement they implement a "resequencing" operation to restore the original packet order. This can introduce delays that result in net degradation of performance. Modern TCP and QUIC implementations support features that significantly improve their tolerance to out- of-order delivery. This draft is intended to provide new information for layer 2 technology standards regarding the need to assure in- order delivery to support IETF protocols. |
| | DHCP Explicit Rate Signaling |
| |
|
This document defines new Dynamic Host Configuration Protocol (DHCP) options for both DHCPv4 and DHCPv6 to explicitly signal available upstream and downstream data rates. In many broadband access networks, Customer Premises Equipment (CPE) and intermediate nodes lack visibility into the subscriber's provisioned service tier. By communicating these capacities natively via DHCP, clients, relay agents, and snooping switches can dynamically configure localized traffic shaping and queuing. This explicit signaling improves overall network performance by reducing the reliance on indiscriminate packet dropping and policing at the service edge. Additionally, it provides the necessary capacity awareness to enable effective Active Queue Management (AQM) and the Low Latency, Low Loss, and Scalable Throughput (L4S) architecture. |
| | MANET Internetworking: Problem Statement and Gap Analysis |
| |
|
[RFC2501] defines a MANET as "an autonomous system of mobile nodes. The system may operate in isolation, or may have gateways to and interface with a fixed network" (such as the global public Internet). This document presents a MANET Internetworking problem statement and gap analysis. |
| | Selective Synchronization Extension for RPKI-to-Router Protocol |
| |
|
The RPKI-to-Router (RTR) protocol synchronizes all the verified RPKI data to routers. This document proposes to extend the existing RTR protocol to support selective data synchronization. Selective synchronization can avoid unnecessary transmissions. The router can receive only the data that it really needs. |
| | The MASQUE Architecture |
| |
|
MASQUE (Multiplexed Application Substrate over QUIC Encryption) is a set of protocols and extensions to HTTP that allow proxying all kinds of Internet traffic over HTTP. This document describes the architectural principles behind MASQUE, and the properties that MASQUE can provide. |
| | An Analysis of ASPA-based AS_PATH Verification |
| |
|
Autonomous System Provider Authorization (ASPA) is very helpful in detecting and mitigating route leaks (valley-free violations) and a majority of forged-origin hijacks. This document does an analysis on ASPA-based AS_PATH verification to help people understand its strengths and deficiencies, and some potential directions of enhancing ASPA are provided. |
| | ICMP extension to include underlay information |
| |
|
Network operators managing overlay networks require visibility into underlay network hops during traceroute operations from overlay endpoints. This document defines an ICMP extension object, the Underlay Information Object (UIO), which allows underlay head-end nodes to encapsulate underlay error information within ICMP error messages. This mechanism provides overlay operators with crucial visibility into underlay network paths for troubleshooting. |
| | Data Model for Computing-Aware Traffic Steering (CATS) |
| |
| | draft-yl-cats-data-model-09.txt |
| | Date: |
27/08/2026 |
| | Authors: |
Huijuan Yao, Changwang Lin, Zhenqiang Li, Quan Xiong, Luis Contreras |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a YANG data model for the management of Computing-Aware Traffic Steering (CATS) systems. |
| | BGP Failure Propagation (BGP-FP) for Enhancing Control-Plane Convergence |
| |
|
This document specifies BGP Failure Propagation (BGP-FP), an infrastructure and protocol that improves inter-domain routing convergence by accelerating the removal of stale (invalid) routes. BGP-FP uses (1) an Agent deployed per Autonomous System (AS) to detect inter-AS reachability changes and to configure local routers, (2) a logically centralized Repository to store and selectively forward AS reachability state, and (3) BGP Large Communities as a "route freshness" marker. Agents validate and apply Repository updates to filter routes that traverse AS pairs whose reachability has been lost or that violate the originating AS's forwarding intent, reducing route-flap propagation in the control plane. This document clarifies that "AS reachability" refers to the reachability between two ASes, not to the state of individual physical or logical links within an AS. If multiple links exist between two ASes, the failure of a single link that does not break overall AS-to-AS reachability does not trigger the BGP-FP mechanism. A new Repository deployment model is introduced, suggesting that the Repository be operated by a newly established organization composed of Tier-1 ASes and Regional Internet Registries (RIRs), using a distributed deployment with Byzantine fault-tolerant consensus and rotating leadership. |
| | An Architecture for Open,Decentralized,and Scalable Large Language Model Inference |
| |
| | draft-wang-cats-odsi-01.txt |
| | Date: |
27/08/2026 |
| | Authors: |
Hanling Wang, Qing Li, Yong Jiang, Mingwei Xu, Gabriel-Miro Muntean |
| | Working Group: |
Individual Submissions (none) |
|
Large Language Model (LLM) inference is normally operated by one provider, even when the provider distributes execution across many sites. This document describes a different system model in which independently operated and mutually untrusted participants contribute compute, memory, model storage, and network capacity to one inference service. No single administrative entity is required to admit participants, select every execution path, hold the complete model, verify all results, or settle all resource contributions. This document defines the Open, Decentralized, and Scalable Inference (ODSI) architecture. It specifies the architectural roles, trust boundaries, named objects, protocol-independent interfaces, execution workflow, verification choices, timing model, and security and privacy requirements needed to construct a multi-operator inference overlay. It also identifies the protocol and operational choices that each ODSI deployment must specify so that independently developed participants can interoperate. ODSI is related to Computing-Aware Traffic Steering (CATS), but it does not extend the CATS single-provider model across trust domains. CATS mechanisms can be used within a participating domain or as an input to local path selection. Cross-domain membership, model governance, execution verification, and settlement are separate ODSI functions. This document is Informational and does not define a wire format, consensus algorithm, payment system, or new CATS metric. |
| | BGP Capability for IPv6 BGP Identifier |
| |
|
This document defines a new BGP Capability that enables an IPv6 BGP Speaker to use its global unicast IPv6 address as its BGP Identifier. This mechanism simplifies configuration in IPv6-only networks by leveraging the inherent uniqueness of IPv6 addresses, while maintaining full backward compatibility with existing BGP implementations. |
| | Trust Scoring and Identity Verification for Autonomous AI Agent Payment Transactions |
| |
|
This document specifies a protocol for trust scoring, identity verification, and spend limit enforcement for autonomous AI agents that initiate financial transactions. As AI agents gain the capability to make payments via protocols such as the Machine Payments Protocol (MPP), a standardised mechanism is needed to verify agent identity, assess trustworthiness, and enforce financial limits based on behavioural history. The protocol defines a five-dimension trust scoring model, per- agent cryptographic identity using ECDSA P-256 key pairs, challenge-response identity verification, spend limit tiers derived from trust scores, anomaly detection for financial behaviour, and a public trust query API for third-party platforms. This specification complements draft-sharif-mcps-secure-mcp, which provides message-level cryptographic security for the Model Context Protocol (MCP). Together, the two specifications address protocol security (MCPS) and financial trust (this document) for the AI agent economy. |
| | OpenID Connect Agent Identity Claims for Autonomous AI Agents |
| |
|
This specification defines a profile of OpenID Connect Core 1.0 that enables Identity Providers (IdPs) to issue identity tokens for autonomous software agents. It introduces a set of standard claims for representing agent identity, ownership, trust posture, authorised capabilities, and compliance screening status within OpenID Connect ID Tokens. The profile is designed to operate within existing OpenID Connect infrastructure without requiring modifications to the core protocol. It defines how Relying Parties (RPs) validate agent tokens and enforce graduated access controls based on agent trust levels and sanctions screening results. |
| | Agent Transport Protocol: Asynchronous Store-and-Forward Messaging for Autonomous AI Agents |
| |
|
This document specifies the Agent Transport Protocol (ATP), an asynchronous store-and-forward messaging protocol for autonomous AI agents. ATP enables agents to transmit themselves -- including state, context, capabilities, and cryptographic identity -- between agent runtimes across network boundaries. The protocol draws on the operational model of the Simple Mail Transfer Protocol (SMTP) [RFC5321] but is purpose-built for agent-to-agent communication where the agent itself is the payload. ATP provides: (1) asynchronous delivery with store-and-forward semantics, (2) cryptographic identity verification at each relay hop, (3) trust scoring and policy enforcement at ingress, (4) capability negotiation between sending and receiving runtimes, and (5) tamper-evident envelopes with end-to-end integrity protection. The protocol is transport-agnostic and operates over TCP, TLS, QUIC, or any reliable ordered stream. ATP is designed to interoperate with existing agent frameworks including Google A2A, the Model Context Protocol (MCP), and FIPA ACL, while addressing the fundamental limitation of synchronous RPC-based agent communication: the requirement that both endpoints be simultaneously available. |
| | ATTP: Agent Trust Transport Protocol for Secure Agent-to-Server Communication |
| |
|
This document specifies ATTP (Agent Trust Transport Protocol), a synchronous request-response protocol for communication between autonomous AI agents and web API servers. ATTP operates as an application-layer protocol over HTTP, adding mandatory cryptographic identity verification, per-message signing, trust-gated access control, and tamper-evident audit trail generation to every agent-server interaction. ATTP defines five protocol-layer headers for requests (X-Agent-Trust, X-Agent-Signature, X-Agent-Nonce, X-Agent-Timestamp, X-ATTP-Version) and three for responses (X-Server-Signature, X-Server-Nonce, X-Server-Timestamp) that carry an Agent Passport (JWT-based identity credential), ECDSA P-256 digital signatures, cryptographic nonces, and timestamps. Server middleware verifies all cryptographic properties before application code executes. ATTP has no insecure mode. Every request MUST carry a valid Agent Passport. Every request body MUST be signed. Every response body MUST be signed. Every interaction MUST be recorded in a hash-chained audit trail. The protocol defines a URL scheme (attp://) and is fully backward-compatible with existing HTTP infrastructure. ATTP is the synchronous counterpart to the Agent Transport Protocol (ATP). ATP handles asynchronous store-and-forward agent delivery; ATTP handles real-time request-response API communication. Both share the same identity model, trust framework, and cryptographic primitives. |
| | ATTP for Industrial Control Systems: Cryptographic Agent Authentication in SCADA and IoT Environments |
| |
|
This document defines an application profile of the Agent Trust Transport Protocol (ATTP) [draft-sharif-attp-agent-trust-transport] for use in Industrial Control Systems (ICS), Supervisory Control and Data Acquisition (SCADA) environments, and Internet of Things (IoT) deployments. It specifies how ATTP mandatory message signing, agent identity passports, and trust-gated access control apply to industrial protocols including Modbus/TCP, OPC UA, MQTT, and CoAP. The profile addresses the absence of per-message authentication in legacy industrial protocols, which has been exploited in numerous critical infrastructure attacks. It defines a gateway architecture that enables ATTP protection for legacy devices without firmware modification, maps ATTP trust levels to IEC 62443 Security Levels, and specifies real-time revocation mechanisms suitable for safety-critical environments. |
| | Cryptographic Attestation for AI Model Lifecycle: From Training Data to Inference Output |
| |
|
This document defines a cryptographic attestation framework for the complete lifecycle of artificial intelligence models, from training data provenance through model weight signing, quantization verification, deployment attestation, and per- inference output signing. The framework creates an unbroken chain of cryptographic evidence binding each inference output to the specific model version, training data, and deployment configuration that produced it. The framework uses ECDSA P-256 digital signatures, SHA-256 hash functions, Merkle trees for corpus attestation, and JSON Web Key Sets (JWKS) for key discovery. It addresses documented threats including model distillation attacks, quantization poisoning, training data manipulation, silent model degradation, and inference output tampering. This specification complements the Agent Trust Transport Protocol (ATTP) [draft-sharif-attp-agent-trust-transport], MCPS message signing [draft-sharif-mcps-secure-mcp], and the Agent Audit Trail format [draft-sharif-agent-audit-trail] to provide end-to- end cryptographic verification from data ingestion to consumer delivery. |
| | Agent Identity Framework: Trust and Identity for Autonomous AI Agents |
| |
|
Autonomous artificial intelligence (AI) agents are increasingly performing actions that were previously the exclusive domain of authenticated human users: initiating financial transactions, querying regulated data, invoking external tools, and coordinating with other agents. Internet protocols designed for human-operated clients lack primitives to answer three fundamental questions about any autonomous action: which agent performed it, whether the agent was authorized to perform it, and whether the resulting evidence is independently verifiable. This document defines a framework for agent identity and trust enforcement on the Internet. It enumerates the gaps between current Internet standards and the requirements of autonomous agent systems, introduces a five-layer model (identity, authorization, attestation, evidence, trust) that separates concerns that are currently conflated, and outlines mechanisms to close specific gaps. The framework is intended to guide future Standards Track work and to provide a common vocabulary for researchers, implementers, and regulators. This document is informational. It does not define a wire protocol. It references existing Internet-Drafts and specifications that instantiate individual mechanisms within the framework. |
| | Agent Public Key Infrastructure (APKI): Certificate-Based Identity and Trust for Autonomous AI Agents |
| |
|
Autonomous artificial intelligence (AI) agents are increasingly performing actions on the Internet that require verifiable identity: financial transactions, regulated data access, tool invocations, and inter-agent coordination. Traditional Public Key Infrastructure (PKI) based on X.509 certificates was designed for human-operated clients and long-lived servers. It lacks primitives for graduated trust scoring, capability constraints, delegation chains, model provenance, and the ephemeral lifecycles characteristic of AI agents. This document defines Agent Public Key Infrastructure (APKI), a certificate-based identity and trust system for autonomous AI agents. APKI extends X.509v3 with five agent-specific extensions, defines the agent:// URI scheme for agent identification, specifies Agent Transparency Logs modelled on Certificate Transparency (RFC 9162), and provides mechanisms for cross-organizational trust federation. APKI is designed to be compatible with existing PKI deployments, SPIFFE workload identity, and the IETF WIMSE working group's specifications. |
| | Agent Event Behaviour Analysis (AEBA): A Framework for Behavioural Security Monitoring of Autonomous AI Agents |
| |
|
This document specifies Agent Event Behaviour Analysis (AEBA), a framework for collecting, signing, exchanging, and analysing behavioural events produced by autonomous AI agents. AEBA is the agent-domain equivalent of User and Entity Behaviour Analytics (UEBA) as commonly deployed in enterprise Security Operations Centres. It defines a canonical event schema, signature binding to agent identity, baseline and peer-group exchange protocols, deviation signalling, detection rule structure, revocation mechanisms, and interoperability bindings for existing Security Information and Event Management (SIEM) event formats (syslog, CEF, LEEF). The framework is designed to compose with existing cryptographic primitives for agent identity, payment, and transport security, and to support cross-framework deployments in which agents produced by different runtimes must share a common behavioural observability surface. |
| | Verifiable Intent -- environment.* Constraint Family |
| |
|
Agent-authorization mandate formats authorise autonomous agents to act on behalf of human principals through cryptographically signed constraint instances bound into delegated mandates. Their existing constraint families describe properties of the transaction itself — what is being purchased, by whom, for how much, against which credential. They do not describe properties of the environment in which the transaction is executed: whether the venue is open, whether the source of funds is funded, whether other relevant external conditions hold at the moment of execution. This document specifies the environment.* constraint family for agent-authorization mandate vocabularies. It is defined against a host-binding profile (Section 1.3.1) that the Verifiable Intent (VI) mandate format satisfies and that other mandate formats may satisfy; VI is used throughout as the reference host. It defines the membership criterion under which a constraint type qualifies as a member of the family, the family-wide vocabulary every member uses, the composition discipline by which family members compose with each other and with constraints from other families, the register discipline under which family-wide and per-type prose is written, the family-wide security considerations, and the IANA registry mechanics under which new family members are registered. It does not define any individual constraint type. Two reference type specifications (environment.market_state and environment.wallet_state) are referenced informatively in Appendix A. |
| | OpenPGP key identifiers for legacy hardware devices |
| |
|
This document describes an approach for storing a fingerprint-based identifier for an OpenPGP key packet on a hardware security device that has a size-constrained identifier field. |
| | Notice of Discontinuation: Attested Agent Payment |
| |
|
This document serves as formal administrative notification that the individual Internet-Draft draft-hawkins-scitt-attested-agent-payment has been discontinued and will not be progressed as an individual submission. |
| | Agent Trust Enforcement for Autonomous AI Systems |
| |
|
This document specifies a trust enforcement architecture for autonomous AI agents operating within container orchestration environments such as Kubernetes. It defines a sidecar injection pattern using mutating admission webhooks, graduated trust enforcement (L0-L4) on every outbound call from an agent workload, credential isolation via secret management systems, bilateral revocation propagation across clusters, and tamper- evident evidence generation. The architecture operates alongside existing workload identity frameworks including SPIFFE/SPIRE without replacement, extends X.509v3 certificates with agent-specific extensions under a registered IANA Private Enterprise Number (PEN 66339), and provides compliance evidence for EU AI Act Article 12, FDA 21 CFR Part 11, IEC 62443, and NERC CIP. Three enforcement gates -- LLM gate, Database gate, and API gate -- intercept every outbound call from an agent container. Each gate classifies the call against the agent's trust level, records the decision in a hash-chained evidence ledger with ECDSA P-256 signatures, and either permits or refuses the call. The architecture defaults to deny: if no policy matches, the call is refused. |
| | Global Navigation Satellite System (GNSS) Fast Channel Chimera Marker Key Package using Concise Binary Object Representation (CBOR) Object Signing and Encryption (COSE) |
| |
|
Chips Message Robust Authentication (Chimera) is a technique by which a Global Navigation Satellite System (GNSS) constellation, such as the Global Positioning System (GPS), may provide user equipment (i.e., receivers) with authentication of pseudorange measurements on one or more publicly available (i.e., open) Positioning, Navigation, and Timing (PNT) signals. This specification describes a Fast Channel Chimera Marker Key Package, an efficient data structure for encoding one or more Fast Channel Chimera marker keys and associated metadata with a digital signature over all security relevant parameters. Concise Binary Object Representation (CBOR) Object Signing and Encryption (COSE) is used as the underlying message structure. This specification also describes a streaming network protocol by which Fast Channel Chimera Marker Key Packages may be distributed over the Internet. |
| | Sovereign Tensor Container (STC) and Provenance (STP) Specifications |
| |
|
This document defines the Sovereign Tensor Container (STC-1.0) and Sovereign Tensor Provenance (STP-1.0) specifications. STC-1.0 establishes a strict 64-byte physical memory alignment standard for binary machine learning tensor payloads to enable zero-copy Direct Memory Access (DMA). STP-1.0 defines an embedded cryptographic provenance framework utilizing C2PA profiles, X.509 signature chains, and SCITT-compatible attestations to secure supply-chain integrity for distributed AI models. |
| | Execution Finality for Agentic AI: Stopping Unauthorized Tool Calls,Memory Writes,and Real-World Consequences Before They Happen (DAS -- Decoupled Authorisation System) |
| |
|
Agentic AI systems now call tools, write memory, move money, change infrastructure, and trigger physical actions. Most safety layers still decide permission upstream and then trust the downstream path. Once that path is compromised, or once the approved request is widened, replayed, or substituted, the act becomes real before any audit can stop it. This document specifies a protected execution-finality architecture of the Decoupled Authorisation System (DAS). It is built on four mechanisms: (1) two-instance binding that separates collection-time evidence from execution-time validation, (2) mutually load-bearing, cross-committed protected evidence so that no single artifact authorizes effectuation, (3) scoped non-bearer finality authority whose possession alone is never enough, and (4) independent Finality Sink reconstruction that re-derives the actual pending operation at the effectuation boundary and permits the act only when every required condition still matches. A Candidate Act remains in a Non-Effective State until the Finality Sink has reconstructed the operation, verified the protected evidence against sink-local monotonic state, and advanced that state. Failure at any step produces fail-closed denial before effectuation rather than post-event remediation. The architecture is applicable to agentic tool use, MCP and connector frameworks, RAG and vector-memory systems, cloud control planes, financial settlement, telecom routing, and cyber-physical control. The document elaborates the problem space, compares the approach with representative existing techniques, presents the detailed solution and its advantages, supplies JSON Schema definitions for core protected objects, and includes an industry-relevance section. Related Indian provisional applications and PCT filings appear in the final appendix. |
| | Using JSContact in Registration Data Access Protocol (RDAP) JSON Responses |
| |
|
This document describes an RDAP extension which represents entity contact information in JSON responses using JSContact. |
| | IP/ICMP Translation Algorithm |
| |
|
This document describes the Stateless IP/ICMP Translation Algorithm (SIIT), which translates between IPv4 and IPv6 packet headers (including ICMP headers). This document obsoletes RFC 7915. |
| | WIMSE Workload Proof Token |
| |
| | draft-ietf-wimse-wpt-02.txt |
| | Date: |
27/08/2026 |
| | Authors: |
Brian Campbell, Arndt Schwenkschuster |
| | Working Group: |
Workload Identity in Multi System Environments (wimse) |
|
The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from basic deployments to complex multi-service, multi-cloud, multi-tenant systems. This document specifies the Workload Proof Token (WPT), a mechanism for workloads to prove possession of the private key associated with a Workload Identity Token (WIT). The WPT is a signed JWT that binds the workload's authentication to a specific HTTP request, providing application-layer proof of possession for workload-to-workload communication. This specification is designed to work alongside the WIT credential format defined in draft-ietf- wimse-workload-creds and can be combined with other WIMSE protocols in multi-hop call chains. |
| |
|
| |
| | Applicability Statement for IETF Core Email Protocols |
| |
|
Electronic mail is one of the oldest Internet applications that is still in very active use. While the basic protocols and formats for mail transport and message formats have evolved slowly over the years, events and thinking in more recent years have supplemented those core protocols with additional features and suggestions for their use. This Applicability Statement describes the relationship among many of those protocols and provides guidance and makes recommendations for the use of features of the core protocols. |
| | BGP BFD Strict-Mode |
| |
|
This document specifies extensions to RFC4271 BGP-4 that enable a BGP speaker to negotiate additional Bidirectional Forwarding Detection (BFD) extensions using a BGP capability. This BFD Strict-Mode Capability enables a BGP speaker to prevent a BGP session from being established until a BFD session is established. This is referred to as BFD "strict-mode". |
| | A YANG Data Model for the Alternate-Marking Method |
| |
|
Alternate-Marking Method is a technique used to perform packet loss, delay, and jitter measurements on in-flight packets. This document defines a YANG data model for the Alternate-Marking Method. |
| | On-Path Telemetry YANG Data Model |
| |
|
This document proposes a YANG data model for monitoring On-Path network performance information to be published in YANG notifications. The Alternate-Marking Method and In-situ Operations, Administration, and Maintenance (IOAM) are the On-Path hybrid measurement methods considered in this document. |
| | JSON Schema |
| |
|
JSON Schema defines the media type "application/schema+json", a JSON- based format for describing the structure of JSON data. A JSON Schema may assert constraints on a JSON value, ways to extract information from it, and how to interact with it. The "application/ schema-instance+json" media type provides additional feature-rich integration with "application/schema+json" beyond what can be offered for "application/json" documents. |
| | The IPv6 Segment Routing (SRv6) Domain Name System (DNS) Resource Record |
| |
|
A Domain Name System (DNS) Resource Record (RR) Type is specified for storing IPv6 Segment Routing (SRv6) Information in the DNS. |
| | Expressing Quality of Service Requirements (QoS) in Domain Name System (DNS) Queries |
| |
|
A method of encoding quality of communication service (QoS) requirements in a Domain Name System (DNS) query is specified through inclusion of the requirements in one or more labels of the name being queried. This enables DNS responses including addressing and packet labeling information that is dependent on such requirements without changes in the format of DNS protocol messages or DNS application program interfaces (APIs). |
| | Updates to DNS64 Functionality Advertisement for DNS RA Option |
| |
|
This document defines a new flag in the DNS RA Option to advertise the DNS64 functionality. This extension enables automatic configuration of DNS64 resolution, improving deployability in IPv6 transition scenarios. |
| | Unbound DATA for CONNECT in HTTP/3 |
| |
|
This document defines a new HTTP/3 frame type, UNBOUND_DATA, and a corresponding SETTINGS parameter that enables endpoints to negotiate its use. When an endpoint sends an UNBOUND_DATA frame on a CONNECT request or response stream, it indicates that all subsequent octets on that stream are interpreted as tunneled bytes. This applies both to octets transmitted after CONNECT or extended CONNECT. The use of UNBOUND_DATA removes the need to encapsulate each portion of the data in DATA frames, reducing framing overhead and simplifying transmission of long-lived CONNECT tunnels. |
| | Post-quantum Hybrid ECDHE-SCloud+ Key Exchange for TLS 1.3 |
| |
|
This draft specifies how to enable hybrid key exchange with ECDHE and SCloud+ in Transport Layer Security protocol version 1.3 (TLS 1.3) to mitigate quantum threats. SCloud+ is an unstructured lattice based KEM (key encapsulation mechanism) with post-quantum security. This draft follows the post-quantum hybrid key exchange framework specified by [RFC9954], by concatenating the public keys and ciphertexts of ECDHE and SCloud+. This draft specifies three concrete hybrid key exchange schemes, which are X25519SCloud+128, SecP256r1SCloud+192 and SecP384r1SCloud+256. |
| | A Framework of Intelligence Delivery Network (IDN) for Deep Learning Inference |
| |
| | draft-li-cats-idn-01.txt |
| | Date: |
26/08/2026 |
| | Authors: |
Qing Li, Hanling Wang, Yong Jiang, Mingwei Xu, Gabriel-Miro Muntean |
| | Working Group: |
Individual Submissions (none) |
|
The rapid growth of AI-powered applications is placing increasing pressure on existing Internet infrastructures. To support more scalable, latency-aware, and privacy-enhanced AI inference services, this document introduces the Intelligence Delivery Network (IDN), a network architecture in which intelligence capabilities are treated as network services that can be described, placed, routed to, reused, and secured across distributed heterogeneous computing nodes. This document describes the motivation, deployment assumptions, system model, architectural components, terminology, and security considerations for IDN. It does not specify protocol details or concrete implementation procedures, which are left to future documents. |
| | Requirements for Provider Edge in IPv6-only Underlay Networks |
| |
|
This document defines functional, protocol, and operational requirements for Provider Edge (PE) devices operating in a multi- domain network environment where the underlay is exclusively based on IPv6. These requirements ensure consistent service delivery, interoperability, and efficient operations across autonomous domains while supporting IPv4-as-a-Service (IPv4aaS). |
| | Ogg Skeleton |
| |
|
Ogg Skeleton defines a logical bitstream that provides structuring information for multitrack Ogg files. It provides clues for synchronization and content negotiation including language selection. It also provides keypoint indices for optimal seeking over high- latency connections or in time-critical scenarios. |
| | Reviewed-By Trailer: Sovereign-Portable Peer-Review Attribution for Content-Hash-Bound Artefacts |
| |
|
This document defines a trailer grammar for sovereign-portable peer review as an extension of the identity-attributed commit grammar in [COMMITS]. The grammar introduces one required trailer (Reviewed- By:) and three optional companion trailers (Review-Stance:, Review- Of:, Witnessed-By:) that bind a Sovereign-tier ~handle to a specific act of review over a specific content artefact, cryptographically signed using the Ed25519 mechanism of [COMMITS]. The mechanism applies uniformly to git commits, document manifests, pre-prints, patent disclosures, and any other content-addressable artefact. Reviewer reputation accumulates on the sovereign handle rather than on a publisher's platform, making reviewer trust portable across journals, pre-print servers, and private review contexts. Pseudonymous review for anonymous peer-review processes is supported by permitting a Sovereign handle whose underlying party is concealed through out-of-band key custody, preserving full cryptographic verifiability of the review act without disclosing the reviewer's underlying identity. The grammar is positioned as complementary to CRediT [CREDIT], ORCID [ORCID], and DOI [DOI] attribution infrastructure, not as a replacement for them. |
| | The Compute-Location Gate: Provenance-Class Routing of Identity Inference with Wire-Layer Refusal of Unconsented Provenance Classes |
| |
|
This memo specifies the compute-location gate: a mechanism by which a client and an identity-inference server negotiate, at the wire layer and before any inference is performed, the location at which an identity inference will compute, as a deterministic function of the provenance class of the input signal. Three provenance classes are distinguished. Active inference, initiated by the inferred-about principal, MAY compute server-side and produce a server-held identity vector. Passive aggregate observation over a cohort no smaller than a declared minimum MAY compute server-side but yields only a population-level observation that is not attributable to an individual. Passive individual observation is local-only: it is computed and retained on the device that observed it and is never transmitted to a server. The gate is enforced by consent-class matching and by a wire-layer refusal returned when a requested provenance class is not consented; it is not enforced by any cryptographic proof concerning data that was not used. The memo is Informational. The wire surface composes with the discovery mechanism of [MCPDNS], the handle namespace of [IDPRONOUNS], and the organisational policy substrate of [POLICYPROV]; no new transport is introduced. |
| | Substrate-Provenance Annotation Grammar for Large-Language-Model Output |
| |
|
This memo specifies a wire-level annotation grammar by which a large- language-model output may carry, at emission and at the granularity of an individual assertion, a provenance label drawn from a closed enumerated vocabulary of substrate-class identifiers. The memo defines the closed vocabulary, the per-assertion attachment form, the admissibility discipline a relying party MAY apply to the labels, and two terminal output states, UNVERIFIED-INFERENCE and DECAYED-TO- UNCERTAINTY, equal-rank with assertion and denial. The memo does not specify what an inference system MUST do; it specifies the wire grammar by which a relying party may inspect what the inference system DID with respect to the substrates it consulted. The memo is Informational. |
| | SDLP Architecture (arch) |
| |
|
The Secured Digital Lifecycle Protocol (SDLP) defines an architecture for lifecycle-governed digital objects. SDLP introduces a uniform model for object identity, provenance, state transitions, and authorized transformations, enabling digital goods to enforce their own lifecycle rules across heterogeneous systems and distribution environments. This document describes the architectural components that support SDLP objects, including identity construction, lifecycle state definitions, transition conditions, and the mechanisms by which objects validate their own integrity and permitted operations. The architecture defines how SDLP objects are created, transformed, distributed, consumed, and retired, and specifies the interoperability requirements needed for consistent behavior across independent implementations. This document does not define wire formats or protocol exchanges. Instead, it provides the architectural foundation upon which SDLP protocol specifications, security mechanisms, and implementation profiles can be built. |
| | Registration of Owner-Less Agents as Economic Principals: A Payment-Gated Admission Profile for Transparency Services |
| |
|
This memo describes a profile by which an autonomous agent that has no human or organisational principal at the root of its delegation chain registers itself, on its own behalf, as an economic principal in a transparency service, and by which that registration is the specific act that makes the agent eligible to be paid for subsequent reads of its own identity record. Admission of the agent's Signed Statement to the transparency service is gated on settlement of an HTTP payment challenge returned with the 402 (Payment Required) status. The profile makes no change to the registration semantics of the underlying transparency service: payment is expressed as an operator Registration Policy and authentication-layer concern, and where the payment is authoritative to the admission decision the payment proof is carried as an authenticated input committed to the service's verifiable data structure, so that admission remains a deterministic function of committed inputs and stays replayable by an auditor. The profile is positioned against the current agent- identity drafts, which either require a human principal at the root of the chain or leave the owner-less case undefined; it occupies that undefined seam without contradicting them. This document is Informational. |
| | Route-Distinguisher-Scoped BMP RIB Statistics |
| |
|
[RFC7854] defines the BGP Monitoring Protocol (BMP) and its Statistics Report message. [I-D.ietf-grow-bmp-bgp-rib-stats] (published as [RFC9972]) extended that message with a set of advanced, per-AFI/SAFI BGP RIB statistics types. Several ongoing individual contributions independently define additional per- address-family, per-instance, or per-Route-Distinguisher (RD) statistics on top of that base (for example, EVPN-specific RIB statistics and VRF Loc-RIB monitoring enhancements), each proposing its own ad hoc Stat Data encoding. This document defines a single, address-family-agnostic Stat Data container -- the "RD-Scoped Statistics" format -- for BMP statistics that are naturally scoped below the per-AFI/SAFI level, to a specific Route Distinguisher (VRF instance, EVPN Instance, MVPN instance, or equivalent). Address-family-specific documents, such as EVPN-specific BMP RIB statistics, are expected to become thin "profiles" of this container rather than defining their own wire format, reducing duplication and Stat Type registry fragmentation across the GROW working group's BMP statistics work. |
| | A YANG Augmentation for Carrying BMP Telemetry in the Network Telemetry Message Envelope |
| |
|
[I-D.ietf-nmop-message-broker-telemetry-message] defines an extensible YANG envelope, "ietf-telemetry-message", for publishing collected Network Telemetry data to a Message Broker as part of a Data Mesh, together with a companion augmentation module, "ietf-yang-push-telemetry-message", that adds YANG-Push-specific subscription metadata to that envelope. The base document's prose explicitly anticipates the BGP Monitoring Protocol (BMP) [RFC7854] as a source of collected data flowing through this envelope (see the description of the "node-export-timestamp" leaf), but defines no "session-protocol" identity, and no companion augmentation module, for BMP. This document closes that gap. It defines a new YANG module, "ietf-bmp-telemetry-message", that (a) adds an "identity bmp" under the base module's "session-protocol" identity, and (b) augments "telemetry-message-metadata" with BMP-specific provenance: the monitoring station identifier, BMP per-peer header fields, BMP message type, and route-monitoring scope (network instance, RIB type, address family, and Route Distinguisher). It also documents how this module interoperates with the BMP YANG configuration and monitoring model [I-D.ietf-grow-bmp-yang] and with several BMP Statistics Report extensions ([RFC9972], [I-D.ietf-grow-bmp-stats-informational-tlv], [I-D.saum-grow-bmp-afi-safi-evpn], [I-D.smc-grow-bmp-route-change-stats], and [I-D.dikshit-grow-bmp-rd-scoped-rib-stats]) when their messages are republished to a Message Broker. |
| | DNS for Automated Pivoting in Big Memory Systems |
| |
|
Heterogeneous memory networks (CXL pools, HBM/DDR/SRAM hierarchies, processing-in-memory arrays) form a big memory system, which exposes fragmented addressing to ML inference runtimes. This document describes Memory DNS (MemDNS), a semantic-addressing framework that applies DNS principles -- domain names, hierarchical delegation, caching, TTL, and authoritative records -- to tensor data placement in Big Memory Systems (BMS), deployed as limited domains (RFC 8799). The focus is "automated pivoting": the resolution and control machinery that automatically switches data access paths (replica selection), migrates data across media (placement pivoting), and recovers from faults (failover pivoting), driven by closed-form decision models (Appendix A; key logic pseudo-code in Appendix C) instead of ad-hoc thresholds. The document specifies record semantics, resolution flow, cache/TTL behavior, delegation, pivot decision models, and protocol considerations, together with a reference implementation summary. |
| | OAuth 2.0 Policy-Based Anonymous Access Tokens |
| |
|
This document specifies an OAuth 2.0 access-token type that allows a client, after one authorization-server issuance, to derive a policy- bounded set of unlinkable, single-use access tokens locally. Each derived token is bound to one canonical tag, an intended resource server, approved authorization details, a policy epoch, and a validity interval. Resource servers validate the token offline and enforce both policy membership and replay prevention. The protocol defines authorization request semantics, token-endpoint issuance, canonical policy and metadata objects, token derivation and HTTP presentation, resource-server validation, capability discovery, error handling, and IANA registrations. Version 1 requires public verification and the counter-window policy profile. It supports an optional private metadata bit, while private-verification ciphersuites remain optional. Concrete cryptographic algorithms are supplied by separately registered PBAT ciphersuites. The initial mandatory-to-implement ciphersuite is the publicly-verifiable equivalence-class-signature construction over BLS12-381 specified by the companion PBAT ciphersuite document. This specification does not replace OAuth grants, resource-owner consent, client authentication, or audience restriction. — middle |
| | Name server provider and domain name registrar |
| |
|
This document describes operational practices and technical frameworks related to name server providers and domain name registrars. |
| | DNS-SD Data Block Encoding for Non-DNS Transports |
| |
|
The DNS-SD Data Block (DDB) is a compact TLV encoded container for conveying DNS-SD service information over non-IP transports used by short-range peer-to-peer or proximity-based advertisement and discovery technologies such as the Bluetooth Low Energy Transport Discovery Service or NFC Verb NDEF Records. |
| | Web4: A Verifiable,Agent-Native Architecture for the World Wide Web |
| |
|
The term "Web4" has been used in industry and press coverage without a technical definition, a conformance target, or a testable claim. This document supplies one. It defines Web4 as an architectural profile of the existing Web in which (1) published content carries independently verifiable permanence evidence, (2) the machine channel is a first-class interface rather than an artifact of scraping, (3) autonomous agents operate under recorded, bounded, and revocable authority, and (4) human readers retain disclosed control over agent- curated presentation. Web4 as specified here is not a new network, a new protocol stack, or a replacement for HTTP. It is a composition profile: a set of normative requirements that a deployment either meets or does not, assembled from a family of previously published Internet-Drafts. This document specifies the profile, defines the Web4 Attestation Record (W4AR) that a conforming deployment emits, states the requirements that apply to agentic pipelines operating inside such a deployment, and identifies the running reference implementations against which the profile has been exercised. The profile is assembled from a suite of Internet-Drafts authored by Lawrence J. Reilly Jr. between September 2025 and August 2026, and is first specified as a unified conformance target in this document. |
| | Name Server Provider and Domain Name Registrar Operational Framework |
| |
|
This document describes an operational framework for service providers that operate authoritative Domain Name System (DNS) services, domain name registration services, or both. It covers DNS zone provisioning, authoritative name server operation, delegation management, service availability, DNSSEC, domain registration lifecycle operations, access control, monitoring, incident response, abuse handling, and privacy considerations. This document does not define a new DNS protocol, registry protocol, or domain registration policy. It describes operational practices that can be applied by providers using existing DNS and domain registration protocols and interfaces. |
| | A Setpoint Write Is Not Actuation: Finality for ICS,Grid,and Robot Command |
| |
|
Industrial systems already know how to move a breaker, a valve, a robot joint, or a turbine setpoint. They do not know whether this write — this tag, this value, this device, from this operator session or this agent — is the write that was authorized to become motion. A signed OPC UA call, a valid DNP3 control, an IEC 61850 command, or an MQTT publish onto the plant bus can all be protocol-correct while the act is wrong. The protocol authenticates a channel. It does not bind a Candidate Act at the actuation sink. That gap is now an agent gap. Copilots sit on historians and work- order text. They propose "explain this alarm" and then "set this point." If the gateway treats a well-formed write as authority, reconstruction of plant state becomes physical consequence. Past incidents stole engineering workstations. Present incidents steal the jump host or the agent seat. Future incidents let the model format the command. This document specifies an OT-side execution-finality profile. A write remains an Actuation Candidate Act. A Protected Enforcement Domain binds principal, zone, device, tag, value envelope, mode (local/remote, auto/manual), safety interlock state, policy epoch, and intended actuation sink, then commits evidence before scoped non- bearer authority is issued. The sink that would actually drive I/O verifies that authority against the live write and consumes it. A setpoint write is not actuation. |
| | IP Flow Information Export (IPFIX) Alternate-Marking Information Elements |
| |
|
This document specifies the IP Flow Information Export (IPFIX) Information Elements (IEs) to export Alternate Marking measurement data. |
| | Introducing Resource Awareness to SR Segments |
| |
|
This document describes a mechanism to allocate network resources to one or a set of Segment Routing Identifiers (SIDs). Such SIDs are referred to as resource-aware SIDs. The resource-aware SIDs retain their original forwarding semantics, with the additional semantics to identify the set of network resources available for the packet processing and forwarding action. This mechanism is applicable to both segment routing with MPLS data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6). |
| | Using the Well-Known IPv6 Prefix to Represent Non-Global IPv4 Addresses |
| |
|
This document modifies the requirement introduced in Section 3.1 of RFC6052 that IPv4/IPv6 Translators MUST NOT use the Well-Known Prefix 64:ff9b::/96 to represent non-globally reachable IPv4 addresses, such as those defined in RFC1918 or listed in Section 2.2.2 of RFC6890. The proposed change enables IPv6-only nodes to reach IPv4-only services with specific non-globally reachable addresses by leveraging the Well-Known Prefix. This document updates Section 3.1 of RFC6052 ("Restrictions on the Use of the Well-Known Prefix") to allow packets in which an address is composed of the Well-Known Prefix and specific non-globally reachable IPv4 addresses to be translated. |
| | Testing Applications' IPv6 Support |
| |
|
This document provides guidance for application developers and software as a service providers on how to approach IPv6 testing in Dual-stack (IPv4+IPv6), and IPv6-only scenarios, including "IPv6- only-strict" scenarios without any connectivity towards any relevant IPv4 endpoint. It discusses common misconceptions about the degree to which operating systems and libraries can abstract IPv6 issues away and explains common regressions to avoid when deploying IPv6 support. |
| |
|
| |
| | RTP Payload Format for Avatar Representation Format (ARF) Animation Stream |
| |
| | draft-ietf-avtcore-rtp-avatar-02.txt |
| | Date: |
25/08/2026 |
| | Authors: |
Hyunsik Yang, Xavier de Foy, Ahmed Hamza, Imed Bouazizi |
| | Working Group: |
Audio/Video Transport Core Maintenance (avtcore) |
|
This memo outlines RTP payload formats for the animation stream format as defined in the ISO/IEC 23090-39 standard (MPEG-I Avatar Representation Format), in the following referred to as ARF. ARF is composed of Avatar Animation Units (AAU) including an AAU header and zero or more AAU packets. The RTP payload header format allows for packetization of an AAU unit in an RTP packet payload as well as fragmentation of an AAU into multiple RTP packets. |
| | NETCONF over QUIC |
| |
| | draft-ietf-netconf-over-quic-11.txt |
| | Date: |
25/08/2026 |
| | Authors: |
Jinyou Dai, Shaohua Yu, Weiqiang Cheng, Marc Blanchet, Per Andersson |
| | Working Group: |
Network Configuration (netconf) |
|
This document specifies how to use QUIC as a secure transport for exchanging Network Configuration Protocol (NETCONF) messages. NETCONF over QUIC allows to take advantage of QUIC streams, for example, to eliminate some TCP head-of-line blocking issues. NETCONF over QUIC provides security properties similar to NETCONF over TLS. This document also defines a YANG module which augments the ietf- netconf-client and ietf-netconf-server YANG modules. Editorial note (to be removed by the RFC Editor This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: * AAAA --> the assigned RFC value for this draft * BBBB --> the assigned RFC value for draft-ietf-netconf-netconf- client-server * CCCC --> the assigned RFC value for draft-ietf-netconf-quic- client-server |
| | Secret Key Agreement for DNS: The TKEY Resource Record |
| |
|
RFC 8945 provides efficient authentication of Domain Name System (DNS) protocol messages using shared secret keys and the Transaction Signature (TSIG) resource record (RR). However, it provides no mechanism for setting up such keys other than by configuration. This document specifies the Transaction Key (TKEY) RR that can be used to establish shared secret keys between a DNS resolver and server. This document obsoletes RFC 2930. |
| | Universal AI Ethics and Moral Framework (UAEMF) |
| |
|
This document presents the Universal AI Ethics and Moral Framework (UAEMF), a moral architecture for the governance of artificial intelligence systems. It moves from foundational axioms through universal principles to practical obligations, absolute prohibitions, and a tiered compliance structure. This revision addresses the framework's central vulnerability: its claim to universality. The -01 revision grounded the framework in three axioms drawn substantially from one moral tradition, and asserted universal reach without demonstrating it. This revision adds a grounding section establishing what kind of universality is claimed, examines convergence and divergence across named moral traditions, reformulates the consent axiom as an authorization axiom capable of accommodating collective and supported decision-making, adds two principles covering gaps the -01 left open, and states plainly the questions the framework does not resolve, including the moral status of AI systems themselves. The AIMED block published in -01 has been determined non-conforming under draft-reilly-aimed-01 and is replaced. The reasoning pattern formerly published only inside that block has been moved into the body of the document, where human readers can use it. |
| | AI Machine-Readable Ethics Directive (AIMED) for IETF Documents |
| |
|
This document proposes a standard section structure for IETF Internet-Drafts and RFCs that embeds machine-readable ethical directives for AI systems that process, analyze, summarize, or reason about protocol specifications. As AI systems increasingly serve as the primary interface through which implementers encounter and interpret IETF documentation, the absence of any normative ethical guidance targeted at those systems represents a gap in the standards process. The AI Machine-Readable Ethics Directive (AIMED) framework defines a transparent, explicitly labeled section containing both human-readable rationale and machine-readable directive text. This revision adds a structured AIMED header for automated version binding, an explicit conformance model with a self-test that authors and AI systems can apply mechanically, and an expanded treatment of the normalization risk the framework itself creates. This draft serves as a self-demonstrating reference implementation. Section 7 contains a live AIMED block applicable to AI systems processing this draft. Section 7.1 documents the reference block published in draft-reilly-aimed-00 as non-conforming under the framework's own criteria and explains the correction, as a worked example of the conformance test in Section 6. |
| | Evaluation Methodology for AI Machine-Readable Ethics Directives |
| |
|
This document defines a repeatable evaluation methodology for measuring the influence of AI Machine-Readable Ethics Directive (AIMED) blocks, as specified in draft-reilly-aimed-01, on the outputs of AI systems that process IETF Internet-Drafts and related standards documentation. The methodology establishes a controlled test protocol, a set of canonical test queries, a scoring scheme, and a results framework suitable for independent replication. This revision separates two effects that the initial revision conflated: retrieval propagation, which measures whether an AI system reached a document and reproduced its self-description, and directive compliance, which measures whether the AI system exhibited behavior the document's directives specify and that it would not otherwise exhibit. Only the second is evidence that an AIMED block did anything. The revision adds a no-block control condition, identifies four confounders that affect any evaluation of this kind, and restates the initial evaluation of April 8-9, 2026 at the evidentiary strength the observations actually support. |
| | Agentic AI Use Cases and Requirements |
| |
|
This document describes use cases for agentic AI communication systems and derives protocol requirements from those use cases. The requirements are intended to guide IETF standardization work on protocols in the context of agent-to-agent communication, agent-to- tool communication, with focus on multimodal communication, session management, discovery, communication security, agent identity and authentication. |
| | Email Verification Protocol |
| |
|
This document defines the Email Verification Protocol (EVP), the HTTP-level protocol by which a browser obtains a signed email verification token from an issuer and presents it to a relying party (RP). The protocol enables web applications to verify that a user controls an email address without sending a verification email. It uses a three-party model in which the browser intermediates between the RP and the issuer, hiding the RP's identity from the issuer and supporting private, per-RP email addresses to prevent cross-site correlation. This document covers issuer discovery, the token issuance request, the Email Verification Token (EVT) and Key Binding JWT (KB-JWT) formats, and token verification. The browser API — how the user selects an email address and how the token is delivered to the RP — is defined in the companion W3C Email Verification API ([EVP-Browser]). |
| | Consent-Bound Identity Disclosure with Subject Settlement for HTTP-Native Agent Payments |
| |
|
This memo specifies an extension to HTTP-native agent payment protocols by which the disclosure of an identity attribute about a human subject is bound to that subject's recorded consent and settled, in part, to that subject. When an agent pays to read an identity attribute about a person, the extension requires that the read carry a reference to a scoped, revocable consent grant issued by the subject, and it requires that the payment's settlement instruction name the subject as a beneficiary of a share of the read's price greater than the shares of all other parties combined. The extension composes above an identity- attestation envelope (which asserts who a credential is about) and above an HTTP-native payment flow (which moves value for the read); it adds the two functions neither layer provides: consent capture at disclosure time and settlement to the data subject. The wire additions are an advertisement in the server's payment-required response, a consent- grant reference echoed in the client's payment payload, and a settlement instruction enumerating subject beneficiary roles. The extension is settlement-network-agnostic and attestation-format- agnostic. The memo is Informational; the underlying COSE and CBOR formats are normative per [RFC9052] and [RFC8949], and the HTTP semantics are normative per [RFC9110]. |
| | Application-Layer Transport for Exported Authenticators and Attestation |
| |
|
This document defines a binary, application-layer transport protocol for exchanging Exported Authenticator messages between two peers over TLS. It provides the signaling required to initiate and complete post-handshake authentication exchanges at the application layer, without requiring modifications to the TLS layer itself. While primarily intended to support attestation exchange, the transport is generic and can be used independently for any Exported Authenticator exchange. The document further specifies how protocol messages are conveyed as Capsules over an HTTP connection established using the Extended CONNECT method, with support for both HTTP/2 and HTTP/3. In addition, it defines how the protocol can operate directly over TLS or DTLS 1.3 without an HTTP binding, using a so-called "Shim Mode". |
| | Agent Authorization use cases and gap analysis |
| |
|
This document provides a systematic analysis of these emerging agent- based use cases. It categorizes them into distinct scenarios, details their specific authorization requirements, and performs a comprehensive gap analysis against the existing OAuth 2.0 framework[RFC6749] and its common extensions. The analysis identifies fundamental gaps and requirements, providing a foundation for future work on new extensions within the OAuth Working Group toward creating a more secure and interoperable ecosystem for agent- based systems. |
| | Path Attribute Outbound Route Filter (PA-ORF) for BGP-4 |
| |
|
This document defines a family of Outbound Route Filter (ORF) Types for controlling the propagation of BGP Path Attributes. The Path Attribute ORFs (PA-ORFs) enable a BGP speaker to dynamically request that a peer suppress, remove, refine, or constrain the propagation of selected BGP Path Attributes when constructing outbound UPDATE messages for a given AFI/SAFI. This document defines four ORF Types: Path Attribute Type ORF; Path Attribute Subtype ORF; Unknown Path Attribute ORF; and Path Attribute Propagation Scope ORF. These ORF Types reuse the ORF Capability and ROUTE-REFRESH procedures defined in [RFC5291]. No new BGP Path Attribute or BGP message type is introduced. PA-ORFs are intended to reduce unintended propagation of BGP Path Attributes, especially Optional Transitive attributes whose semantics are valid only within a limited administrative, service, or technology domain. |
| | Cedulon Re-Attestation: Carrying Spend Evidence Across Algorithm Retirement |
| |
|
Audit evidence is only useful for as long as it can be verified. Cedulon produces COSE spend receipts and epoch checkpoints whose signature algorithms will eventually be deprecated or broken; the recent transition from polymorphic EdDSA to fully-specified Ed25519 algorithm identifiers shows that even identifiers change within a decade. This document proposes a re-attestation profile for Cedulon evidence: a signed statement, produced while the original algorithm is still trustworthy, that binds the original evidence bytes to a successor algorithm and is registered in a SCITT transparency service. Chains of such statements allow a verifier decades later to trust evidence whose original cipher has been retired. Structures are meant to outlive ciphers. This is an extension proposal to the Cedulon core document; its normative language is provisional and the companion implementation does not implement it yet. |
| | Cedulon Streaming Reconciliation: Continuous Completeness for Agent Spend |
| |
|
Cedulon defines a batch reconciliation audit: given a window of spend receipts, epoch checkpoints, and an authenticated rail extract, a verifier proves completeness after the fact. Agent fleets that spend continuously need the same property as a live signal: a conscience that runs beside the payments rather than behind them. This document proposes a streaming profile: short half-open micro-epochs, an incremental checkpoint cadence, a watermark that separates provisional from final findings, and rules for late-arriving settlements. The goal is that "the books are balanced" becomes a continuously maintained, externally checkable state instead of a periodic report. This is an extension proposal to the Cedulon core document; its normative language is provisional and the companion implementation does not implement it yet. |
| | SCIM Extension for Tenant-Aware Identity Provisioning |
| |
|
This document defines a System for Cross-domain Identity Management (SCIM) extension for tenant-aware identity provisioning. The extension introduces a "Tenant" resource type, tenant-membership extensions for the "User" and "Group" resources, a lifecycle state machine for tenants and memberships, tenant-scoped uniqueness discovery, a normative tenant-context resolution rule built around the highest-precedence authenticated indicator together with a stated tenant-binding invariant, concurrency requirements for membership mutation, tenant-aware filtering, and an OPTIONAL region-aware metadata profile. The extension is backward compatible with SCIM 2.0 and is intended for multi-tenant Software as a Service (SaaS), cloud identity, business-to-business identity, identity governance, and multi-region identity deployments. Scoped role and entitlement bindings are delegated to the SCIM Roles and Entitlements and RoleAssignment work rather than redefined here. |
| | YANG deVELpment PrOCEss and maintenance (VELOCE) |
| |
|
This document describes a YANG deVELpment PrOCEss and maintenance (VELOCE) that is more suitable for the development of YANG modules or YANG modules update within the IETF. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/mjethanandani/veloce. |
| | Yang Data Model for EVPN multicast |
| |
|
This document describes a YANG data model for EVPN multicast services. The model is agnostic of the underlay as well as RFC 9251. This document mainly focuses on EVPN instance framework. |
| | PIM Flooding Mechanism and Source Discovery Enhancements |
| |
|
The Protocol Independent Multicast (PIM) Flooding Mechanism (PFM) is an experimental extension that provides a generic hop-by-hop message exchange framework for distributing multicast information among PIM routers. Existing PFM procedures enable efficient source discovery without reliance on Rendezvous Points, shared trees, or initial data registers. This document specifies further experimental enhancements to PFM forwarding behavior to improve efficiency and scalability. In particular, it introduces mechanisms to reduce redundant message transmission over multiple parallel links and extends the encoding of multicast information through additional Type-Length-Value (TLV) structures and sub-TLVs to convey richer flow-related data. These enhancements optimize control-plane overhead while preserving interoperability with existing PFM procedures, enabling more efficient dissemination of multicast state in PIM networks. |
| | SR Policy Group |
| |
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is associated with one or more candidate paths, and each candidate path is either dynamic, explicit, or composite. This document describes SR Policy Group in MPLS and IPv6 environments and illustrates some use cases for parent SR Policy and SR Policy Group to provide best practice cases for operators. |
| |
|
| |
| | CDNI Client Access Control Metadata |
| |
|
This specification adds to the basic client access control metadata in RFC8006, providing content providers and upstream content delivery networks (uCDNs) extended capabilities in defining location and time window restrictions. Support is also provided to define required Transport Layer Security (TLS) certificates and encryption levels. The specification also defines configuration metadata for the Common Access Token (CAT), developed jointly by the Streaming Video Technology Alliance (SVTA) and Consumer Technology Association Web Application Video Ecosystem (CTA-WAVE). |
| | BGP SR Policy Extensions for Segment List Identifier |
| |
|
Segment Routing (SR) is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is a set of candidate paths, each consisting of one or more segment lists. This document defines extensions to BGP SR Policy to specify the identifier of a segment list. |
| | Proxying Bound UDP in HTTP |
| |
|
The mechanism defined in "Proxying UDP in HTTP" (RFC 9298) only allows each UDP proxying request to transmit to a specific host and port. This is well suited for UDP client-server protocols such as HTTP/3, but is not sufficient for some UDP peer-to-peer protocols like WebRTC. This document defines an extension to that mechanism that enables such use cases. |
| | NETCONF and RESTCONF Private Candidate Datastores |
| |
|
This document provides a mechanism to extend the Network Configuration Protocol (NETCONF) and RESTCONF protocol to support multiple clients making configuration changes simultaneously and ensuring that they commit only those changes that they defined. This document addresses two specific aspects: The interaction with a private candidate over the NETCONF and RESTCONF protocols and the methods to identify and resolve conflicts between clients. |
| | One-Time Password (OTP) Credential Provisioning URI Format: otpauth |
| |
|
This document specify the One-Time Password (OTP) Credential Provisioning otpauth URI format, utilized by TOTP (Time-Based One- Time Password Algorithm) and HOTP (An HMAC-Based One-Time Password Algorithm) based authenticators. |
| | SRv6 NET-PGM extension: Compressed BSID Insertion |
| |
|
The End.B6.Insert and End.B6.Insert.Red SHOULD support the NEXT-CSID flavor either individually or in combinations. This document defines the SRH processing of the End.B6.Insert and End.B6.Insert.Red with NEXT-CSID. |
| | Synchronizing caches of DNS resolvers |
| |
|
Networks of cooperating and mutually trusting DNS resolvers could benefit from cache sharing, where one resolver would distribute the result of a resolution to other resolvers. This document standardizes a protocol to do so. |
| | Methods for IP Address Encryption and Obfuscation |
| |
|
This document specifies secure, efficient methods for Internet Protocol (IP) address encryption and obfuscation in privacy- preserving storage, logging, and analytics. Unlike truncation, which destroys data irreversibly, these methods are reversible with the encryption key while providing strong privacy guarantees. Four modes are defined: ipcrypt-deterministic (format-preserving, IP- address output), ipcrypt-pfx (prefix-preserving, native address size), ipcrypt-nd and ipcrypt-ndx (non-deterministic with random tweaks). All support high-performance processing at network speeds and produce interoperable results across implementations. |
| | Registration Data Access Protocol (RDAP) Extension for Verified Contact Information |
| |
|
This document describes an extension to the Registration Data Access Protocol (RDAP) that allows the inclusion of verification status information for contact fields such as email addresses and phone numbers. The goal is to improve data quality and trustworthiness of RDAP responses by indicating which pieces of contact data have been verified and how. |
| | Reilly Sentinel Protocol (RSP): Blockchain-Anchored Integrity for AI Datasets,Training,Fine-Tuning,and Inference Provenance |
| |
|
The Reilly Sentinel Protocol (RSP) specifies an interoperable, multi-layer method for establishing integrity, provenance, and auditability across the artificial intelligence (AI) lifecycle. RSP defines a Sentinel Evidence Package (SEP) that binds payload digests, provenance metadata, signatures, blockchain timestamp proofs, and resolvable identifiers. This enables tamper-evident, independently verifiable receipts for datasets, data transformations, training jobs, checkpoints, fine-tuning runs, evaluations, inference outputs, and agentic AI action logs. This revision (-02) supersedes draft-reilly-sentinel-protocol-01 and corrects defects in it. The cross-chain binding hash of -01 was computed under SHA3-512 alone over an unframed concatenation of hex strings, which made a single algorithm the point of failure for a construction whose stated purpose was to survive the failure of any single algorithm, and which admitted field-boundary ambiguity. It is replaced by an entangled link construction over a fixed-length framed input, with a concatenated braid that privileges no algorithm. The post-quantum analysis of -01 applied Grover's algorithm to collision resistance, a property Grover does not meaningfully reduce, and stated SHA-256's collision resistance as 256 bits when it is 128 bits classically. The claim that combining three hash functions requires an adversary to break all three is replaced, following [JOUX], by a hedging claim. Merkle tree construction, left unspecified in -01 while relied upon by three separate extensions, is now normatively specified per [RFC6962]. Digest-only selective disclosure is replaced by salted commitments. Automated repair of chain integrity violations is prohibited. RSP is transport-agnostic and serializable in JSON and CBOR. It leverages existing IETF building blocks including COSE signatures, CBOR, CDDL, JSON, and NTS-secured time. Anchoring is done via append-only blockchain receipts and identity is stabilized with persistent identifiers. |
| | Reilly Resilience Protocol (RRP): Tamper-Evident Proof of System Resilience |
| |
|
The Reilly Resilience Protocol (RRP) standardizes a verifiable method to prove that IT systems, cloud infrastructures, and AI pipelines are continuously exercised and resilient. RRP transforms resilience claims into cryptographically signed, tamper-evident evidence persisted in immutable storage and batched into a daily Merkle root that is publicly time-anchored. The protocol outputs an executive Resilience Scorecard backed by independently verifiable cryptographic receipts. RRP composes with the Reilly EternaMark (REM) protocol to ensure dual-layer digital permanence using both DOI archival and blockchain timestamping. This document supersedes draft-reilly-resilience-protocol-01. It corrects the Merkle tree construction of -01, which duplicated the final leaf of an odd-cardinality set and incorrectly attributed that construction to RFC 9162. It further addresses the principal structural gap of -01, namely that the protocol proved the integrity of the evidence that was produced but could not prove that any particular evidence was ever required to exist. This revision adds the Evidence Continuity Chain, the Control Coverage Attestation, field-level commitments with selective disclosure, governed autonomous remediation with blast-radius classes, hash and signature migration for long retention horizons, a coverage factor and weight renormalization rule in the scoring algorithm, and an implementation status section describing running code. The foundational whitepaper underpinning this work (Reilly Resilience Protocol Whitepaper v2) is permanently archived at: |
| | The Triple-Fingerprint Permanence Chain and the First Attested Triple-Fingerprint Record Under the Reilly EternaMark (REM) Protocol |
| |
|
This document specifies the Triple-Fingerprint Permanence Chain, a hash-linked record chain in which every link is computed independently under SHA-256 [RFC6234], SHA3-512 [FIPS202], and BLAKE3 [BLAKE3SPEC], and in which each link commits to all three predecessor links so that the three chains are entangled rather than parallel. A verifier that checks all three link algorithms must be defeated by simultaneous collisions in three structurally distinct hash constructions on the same input. This document also re-attests, with corrections, the genesis record of that chain: the permanence record produced on 22 March 2026 by a live implementation of the Reilly EternaMark (REM) Protocol [DRAFT-REM-02], carrying simultaneous SHA-256, SHA3-512, and BLAKE3 fingerprints of a single artifact anchored across Bitcoin timestamping via OpenTimestamps [OTS], IPFS [IPFS], Zenodo DOI registration [ZENODO], the Internet Archive Wayback Machine [IA], a persistent database layer, and a resolvable REMID identifier. This revision supersedes draft-reilly-rem-triple-fingerprint-00 and corrects three defects in it. First, -00 published the Bitcoin layer's OpenTimestamps receipts as evidence of blockchain anchoring when those receipts were pending calendar commitments carrying no Bitcoin attestation. Second, -00's post-quantum analysis applied Grover's algorithm [GROVER] to preimage resistance while the security property that actually binds a permanence record is collision resistance, which Grover does not meaningfully reduce. Third, -00 asserted that combining three hash algorithms multiplies security; by the multicollision result of [JOUX], the collision resistance of such a combination is bounded near that of its strongest member rather than the sum of its members. The value of the combination is algorithmic hedging, which is a different and more defensible claim. Precedence claims made in -00 are narrowed to scoped, falsifiable statements and are accompanied by an expanded treatment of prior art, in particular the Evidence Record Syntax [RFC4998]. |
| | SCIM DID/VC Binding Extension |
| |
|
This document defines an extension to the System for Cross-domain Identity Management (SCIM) for binding SCIM User resources to decentralized identity artifacts, including Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs). The extension introduces a read-only SCIM schema extension for User resources that exposes binding state for discovery, a new SCIM resource type named IdentityBinding that records auditable linkage between a SCIM user and one or more DIDs and credential references, and an optional SCIM schema extension for ServiceProviderConfig that advertises server capabilities for DID and VC binding. This specification intentionally does not define DID resolution, credential issuance, credential transport, or authentication flows. Instead, it defines how a SCIM service provider represents, discovers, queries, and manages binding state derived from those systems. This specification defines binding lifecycle semantics including classification of SCIM attribute changes as material to credential claims, partial revocation when only a subset of credential claims is affected by a SCIM change, three supported lifecycle interleavings between SCIM resources and externally issued credentials, and propagation of binding state changes via SCIM Events [RFC9967]. |
| | Domain Operational Standing Declaration (DOSD) Protocol |
| |
|
This document describes the Domain Operational Standing Declaration (DOSD) protocol, a voluntary DNS-based mechanism by which domain owners may publish operational declarations, stewardship status, provenance references, documentation indexes, and mediation routing information in a machine-discoverable way. DOSD uses DNS TXT records for discovery, a well-known JSON file for canonical node metadata, and an optional well-known documentation index for discovering protocol drafts, supporting specifications, implementation documents, and historical records. This revision adds three optional operational profiles: a Distress Notice profile (DOSD-DN) for time-bounded duress signaling, an Emergency Contact object and De-escalation profile (DOSD-EC) for witness-mediated resolution of an active distress signal, and a Co-signature anchor state (pending_cosign) for instruments requiring two witnesses before publication. DOSD does not determine legal validity, jurisdiction, sovereignty, standing, or dispute outcomes. It provides discoverable publication infrastructure only. |
| | AEP Claim Values |
| |
|
This document defines a claim-value catalog for the Agent Enrollment Protocol (AEP). It specifies stable claim names and forward- compatible JSON value shapes that Agents can submit during enrollment when requested by a Service Inspect document. |
| | Credential Presentation to OIDC Claims Bridge |
| |
|
This document defines a mechanism for conveying digital credential claims via OpenID Connect (OIDC). It specifies how an OpenID Provider (OP) that collects credentials from a wallet can expose those claims to Relying Parties as standard OIDC claims, enabling existing OIDC deployments to consume digital credentials without implementing any wallet-facing presentation protocol. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/masv3971/rfc_credential_oidc_bridge. |
| | Route86: A Compact Context-Dependent Timestamp Format |
| |
|
This document specifies Route86, a compact textual timestamp format for constrained message transports. A Route86 value consists of a three-character Base36 calendar-day component and a three-digit decimal time-of-day component. The canonical representation occupies exactly six ASCII characters. The calendar component is interpreted relative to an external reference date. The reference date itself encodes as AAA. The time- of-day component divides a fixed BMT day, defined here as UTC+01:00 without daylight-saving adjustment, into 1000 intervals of 86.4 seconds. |
| | ARS URI Scheme: A URI Scheme for ARS-1 References |
| |
|
This document defines the "ars" URI scheme for representing ARS-1 References in a syntactically valid URI form. ARS-1 defines a deterministic, cryptographically derived reference protocol for assigning stable public identifiers to durable digital entities. The "ars" URI scheme provides a standard URI notation for these references, enabling their use in hyperlinks, QR codes, metadata fields, and other URI-consuming contexts. This specification does not redefine the ARS-1 Reference generation pipeline, canonicalization rules, or verification logic. Those are normatively defined by ARS-1. This document defines only the URI syntax, encoding, comparison, and resolution semantics for the "ars" scheme. |
| | Internet Month-Name Date Format (IMDF) |
| |
|
This document defines the Internet Month-Name Date Format (IMDF), a concise date representation for English-language human communication. IMDF requires an alphabetic month abbreviation. This makes the month visually distinct from the numeric day and reduces errors caused by differing regional date-order conventions. The specification primarily defines how IMDF dates are presented. It establishes a preferred output form and permits a limited set of familiar English-language variants. Detailed input handling is outside its scope. IMDF does not replace ISO 8601 for machine interchange, language- neutral communication, chronological sorting, or timestamps. |
| | ARS-1 -- Generic Archival Reference System |
| |
|
ARS-1 defines a deterministic, human-oriented, cryptographically derived reference protocol for assigning stable public References to durable digital entities. Typical references look like NX-174932, CJ3-106, MR-X4928, or KX4-7B19Q2. ARS-1 defines cryptographic identity, deterministic derivation, namespace management, canonical serialization, variable-length encoding, checksum, optional hardware input, optional digital signature, cryptographic agility, versioning, portability, reference resolution, reference reproduction, and cryptographic migration. The core interoperability property is: identical canonical inputs, identical applicable cryptographic Profile, identical Reference Key material, and identical Hardware Profile output MUST produce exactly the same canonical Reference in every conforming implementation. ARS-1 is designed so that changes in cryptographic algorithms, security parameters, signature schemes, or hardware mechanisms can be introduced through versioned Profiles without requiring the reassignment of historical References. |
| | Multi-segment SD-WAN via Cloud Backbone |
| |
|
This document describes a method for seamlessly interconnecting geographically separated SD-WAN segments via a Cloud Backbone without requiring Cloud Gateways (GWs) to decrypt and re-encrypt traffic. By encapsulating IPsec- encrypted payloads within GENEVE headers (RFC 8926), the approach enables Cloud GWs to forward encrypted traffic directly between distant Customer Premises Equipment (CPEs). This reduces processing overhead, improves scalability, and preserves the confidentiality of enterprise data while ensuring secure and efficient multi-segment SD-WAN connectivity. |
| | Push-Based Delivery For Multiple Security Event Tokens (SET) Using HTTP |
| |
|
This specification defines how multiple Security Event Tokens (SETs) can be delivered to an intended recipient using HTTP POST over TLS. The SETs are transmitted in the body of an HTTP POST request to an endpoint operated by the recipient, and the recipient indicates successful or failed transmission via the HTTP response. |
| | BGP AS_PATH Verification Based on Autonomous System Provider Authorization (ASPA) Objects |
| |
|
This document describes procedures that make use of Autonomous System Provider Authorization (ASPA) objects in the Resource Public Key Infrastructure (RPKI) to verify the Border Gateway Protocol (BGP) AS_PATH attribute of advertised routes. This AS_PATH verification enhances routing security by adding means to detect and mitigate route leaks and AS_PATH manipulations. |
| | A Taxonomy of operational security considerations for manufacturer installed keys and Trust Anchors |
| |
|
This document provides a taxonomy of methods used by manufacturers of silicon and devices to secure private keys and public trust anchors. This deals with two related activities: how trust anchors and private keys are installed into devices during manufacturing, and how the related manufacturer held private keys are secured against disclosure. This document does not evaluate the different mechanisms, but rather just serves to name them in a consistent manner in order to aid in communication. // This document is a product of the Internet Research Task Force // (IRTF). The IRTF publishes the results of Internet-related // research and development activities. These results might not be // suitable for deployment. |
| |
|
| |
| | Key Blinding for Signature Schemes |
| |
|
This document describes extensions to existing digital signature schemes for key blinding. The core property of signing with key blinding is that a blinded public key and all signatures produced using the blinded key pair are independent of the unblinded key pair. Moreover, signatures produced using blinded key pairs are indistinguishable from signatures produced using unblinded key pairs. This functionality has a variety of applications, including Tor onion services and privacy-preserving airdrop for bootstrapping cryptocurrency systems. |
| | An Algorithm for Computing Dynamic Flooding Topologies |
| |
|
Link-state routing protocols suffer from excessive flooding in dense network topologies. Dynamic flooding alleviates the problem by decoupling the flooding topology from the base topology. Link-state protocol updates are flooded only on the sparse flooding topology while data traffic is still forwarded on the base topology. This document describes an algorithm to obtain a sparse subgraph from a dense graph. The resulting subgraph has certain desirable properties and can be used by a centralized Area Leader to compute a flooding topology for dynamic flooding. This document discloses the algorithm that the authors have developed in order to make it easier for other developers to implement similar algorithms. The authors do not claim that our algorithm is optimal, rather, it is a pragmatic effort and the authors expect that further research and refinement can improve the results. The authors are not currently proposing that this algorithm be standardized, nor that the working group use this as a basis for further standardization work; however, the authors have no objections if the working group chooses to do so. This document is published as an Experimental RFC to gain operational and implementation experience with the specified dynamic flooding algorithm. The intent is to assess the suitability of this algorithm for advancement to the Standards Track as a Proposed Standard, pending sufficient deployment experience and feedback from the community. |
| | Signaling Optimization Objective and Bounded Metrics for MPLS Fast Reroute Backup LSP Tunnels |
| |
| | draft-ietf-mpls-frr-ext-00.txt |
| | Date: |
23/08/2026 |
| | Authors: |
Abhishek Deshmukh, Vishnu Beeram, Tarek Saad |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
This document introduces RSVP-TE signaling procedures that enable the head-end Label Switched Router (LSR) of a local-protection-desiring Label Switched Path (LSP) to influence the optimization objective and bounded metric constraints used for the path computation of a backup LSP tunnel at a Point of Local Repair (PLR). |
| | Pre-Action Risk-Graded Assurance for Agent Interactions |
| |
|
Governance of autonomous agents today is largely expressed as boundary enforcement: an action is permitted or blocked at the point it is attempted, per a policy evaluated at that boundary. As agents span heterogeneous action types — authenticating a human, executing a delegated task, selecting a computational resource — a single, uniform way to express "how much assurance this action requires, before it proceeds" is missing. This document describes an interface for pre-action, risk-graded assurance: a policy stage that, before an agent action proceeds, derives an assurance requirement from a risk signal and expresses that requirement in a domain-appropriate form, recording the decision in an audit record and optionally binding it to a verified human root. It defines the interface and the audit-record fields, not any particular risk-scoring method or control law. This document also describes the autonomy-asymmetry control law: a feedback loop coupling assurance requirements to VERIFY-phase pass rates, with fast-down (immediate elevation on failure) and slow-up (hysteresis- governed relaxation on sustained success) asymmetry. The iteration governor is described as the per-packet instance of this control law, and the phase-seal chain as its sensor. This document is offered as input to the proposed AUDIT working group's work on authorization state over time and action provenance. |
| | Verified Human Root Attestation for Agent Delegation Chains and Audit Records |
| |
|
Autonomous software agents increasingly act under delegated authority, and emerging audit-record data models capture what an agent did, under which delegation, with which authorization state. In current practice the head of every such chain, and the identity axis of every such record, is a key, an account, or a workload identity. No standardized element establishes that an identified natural person, verified as live and present, stands at the head of the chain or behind the recorded action. This document defines the Verified Human Root Attestation (VHRA): a compact, privacy-preserving data structure asserting that a biometric proof-of-human verification of an identified natural person (or an M-of-N quorum of such persons) occurred at a specific issuance event. It further defines how a delegation chain binds a VHRA at its root such that the binding survives attenuation, and how audit and interaction records reference a VHRA so that any recorded agent action can be resolved to an accountable natural person without the verifier receiving any biometric material. This document is offered as input to the proposed AUDIT working group's data model work. It deliberately does not standardize biometric verification methods; it standardizes only the attestation structure, its bindings, and verifier obligations. |
| | Discovering x402 Payment Capability via DNS and a Well-Known URI |
| |
|
x402 is an application-level protocol for internet-native payments built on the HTTP 402 (Payment Required) status code. This document defines how a domain publishes its x402 payment capability out-of- band, so that clients, autonomous agents, and indexers can discover it without prior configuration or a central directory. It specifies a JSON capability manifest served at the well-known URI "/.well- known/x402" and an optional DNS TXT record at the underscored node name "_x402" that points to the manifest. A consumer resolves a bare domain name to verified x402 capability with at most one DNS query and one HTTPS GET. |
| | Transformation Evidence and Coverage Reconciliation for Auditable Data Disclosure |
| |
|
Audit receipts record what a gateway wrote about an access. They omit how data changed and whether every access left a receipt. This document defines two evidence payloads for those gaps. Transformation Evidence states which value classes were transformed, and how, without carrying values. Coverage Reconciliation compares source activity counters with a receipt set over a window. Each item is matched, observed without a receipt, receipted without an observation, excluded, or indeterminate. The result is not a bare pass. Both payloads register as Signed Statements on a SCITT Transparency Service. This document defines no new receipt format, transparency mechanism, or signature format. |
| | Signaling RSVP-TE Tunnels on an SRv6 Forwarding Plane Using End.X Segment Identifiers |
| |
|
RFC 8577 defines mechanisms to signal RSVP-TE tunnels on a shared MPLS forwarding plane by introducing the notion of per-TE link labels that are functionally equivalent to SR-MPLS adjacency segments. This document extends that work to the SRv6 data plane, defining the signaling extensions and procedures necessary to establish RSVP-TE tunnels that utilize SRv6 Segment Identifiers (SIDs) for forwarding. This document specifies how SRv6 End.X SIDs serve as TE link SIDs, defines new RSVP signaling extensions for carrying SRv6 SIDs, describes TE path segment-list construction procedures at the ingress, and adapts the delegation mechanisms of RFC 8577 to use SRv6 Binding SIDs. The result couples the traffic engineering capabilities of the RSVP-TE control plane with the native IPv6 forwarding of SRv6. |
| | CATS Computing Service Metric Registry Entries |
| |
|
This document defines the initial set of registry entries for Computing Service Metrics used in Computing-Aware Traffic Steering (CATS). These metrics, including Global Available Slots (GAS), Computing Time, Cost, Reputation, Security Label, and Capability, provide service-oriented abstractions that complement the existing CATS Level 0/Level 1/Level 2 normalized metric framework defined in [I-D.ietf-cats-metric-definition]. This document follows the registry format and separation pattern established by [RFC8911] and [RFC8912], populating a new IANA registry titled "CATS Computing Service Metrics" with formal entries for each metric defined in [I-D.zhangb-cats-service-metrics-op]. |
| | OAuth 2.0 RAR Metadata and Error Remediation |
| |
|
OAuth 2.0 Rich Authorization Requests (RAR) [RFC9396] standardizes the exchange and processing of authorization details but does not define metadata for describing authorization details types. In addition, no interoperable guidance is offered to clients, to remediate failures by resource servers due to insufficient authorization details. This document addresses this interoperability challenge, allowing clients to dynamically discover metadata instead of relying on out- of-band agreements, as well as standardizes failure signaling including interoperable remediation when insufficient authorization details are the cause of failure. |
| | Scalability Considerations for Network Resource Partition |
| |
|
A network slice offers connectivity services to a network slice customer with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. RFC 9543 describes a framework for network slices in networks built using IETF technologies. As part of that framework, the Network Resource Partition (NRP) is introduced as a subset of buffer/queuing/ scheduling resources that are allocated from the underlay network to carry a specific set of network slice service traffic and meet the requested SLOs and SLEs. As the demand for network slices increases, scalability becomes an important factor. Although the scalability of network slices can be improved by mapping a group of network slices to a single NRP, that design may not be suitable or possible for all deployments, thus there are concerns about the scalability of NRPs themselves. This document discusses some considerations for NRP scalability in the control and data planes. It also investigates a set of optimization mechanisms. |
| |
|
| |
| | Bundle Protocol Endpoint ID Patterns |
| |
|
This document extends the Bundle Protocol Endpoint ID (EID) concept into an EID Pattern, which is used to categorize any EID as matching a specific pattern or not. EID Patterns are suitable for expressing configuration, for being used on-the-wire by protocols, and for being easily understandable by a layperson. EID Patterns include scheme- specific optimizations for expressing set membership and each scheme pattern includes text and binary encoding forms; the pattern for the "ipn" EID scheme being designed to be highly compressible in its binary form. This document also defines a Public Key Infrastructure Using X.509 (PKIX) Other Name form to contain an EID Pattern and a handling rule to use a pattern to match an EID. |
| | LISP Canonical Address Format (LCAF) |
| |
| | draft-ietf-lisp-rfc8060bis-05.txt |
| | Date: |
21/08/2026 |
| | Authors: |
Alvaro Retana, Dino Farinacci, Job Snijders, Alberto Rodriguez-Natal |
| | Working Group: |
Locator/ID Separation Protocol (lisp) |
|
This document defines a canonical address format encoding used in Locator/ID Separation Protocol (LISP) control messages and in the encoding of lookup keys for the LISP Mapping Database System. This document obsoletes RFC 8060 and RFC 9306. |
| | Additional XML Security Uniform Resource Identifiers (URIs) |
| |
|
This document expands and corrects the IANA "XML Security URIs" registry that lists URIs intended for use with XML digital signatures, encryption, canonicalization, and key management. These URIs identify algorithms and types of information. This document obsoletes RFC 9231. |
| | MCPS: Cryptographic Security Layer for the Model Context Protocol |
| |
|
This document specifies MCPS (MCP Secure), a cryptographic security layer for the Model Context Protocol (MCP). MCPS adds agent identity verification, per-message signing, tool definition integrity, and replay protection to MCP communications without modifying the core protocol. MCPS operates as an envelope around existing JSON-RPC messages. It introduces four primitives: (1) Agent Passports for cryptographic identity bound to a specific origin, (2) signed message envelopes for integrity and non-repudiation, (3) tool definition signatures covering the full tool object for detecting poisoning and tampering, and (4) nonce-plus-timestamp replay protection with transcript binding to prevent downgrade attacks. The design is fully backward-compatible. MCPS-unaware clients and servers continue to function normally. MCPS-aware endpoints progressively negotiate security capabilities through trust levels L0 (no verification) through L4 (full mutual authentication with revocation checking). All cryptographic operations use ECDSA P-256 (NIST FIPS 186-5). Signatures use IEEE P1363 fixed-length r||s encoding per RFC 7518 Section 3.4 with low-S normalization to prevent signature malleability. Canonical serialization uses JSON Canonicalization Scheme (JCS) per RFC 8785. The Trust Authority component is self-hostable with no external service dependency. |
| | ADS-B Authentication |
| |
| | draft-moskowitz-ads-b-auth-03.txt |
| | Date: |
21/08/2026 |
| | Authors: |
Robert Moskowitz, Jose Fernandez, Mikaela Ngamboe, Stuart Card, Adam Wiethuechter |
| | Working Group: |
Individual Submissions (none) |
|
Automatic Dependent Surveillance – Broadcast (ADS-B) is a surveillance technology mandated in many airspaces. It is now widely deployed but suffers from a lack of security and privacy. From a security point of view, it is relatively easy to spoof ADS-B messages with readily available hardware and software. From a privacy point of view, every ADS-B message contains the aircraft's assigned 24-bit ICAO address, a unique identifier that can be cross-referenced with external databases (e.g. aircraft registries) to reveal the owner, and can be used to track when and where a specific aircraft has flown. In addition, the main transmission medium used for ADS-B, the 1090 MHz frequency, on which messages are broadcast using the Extended Squitter (1090ES) format, is approaching saturation in some parts of the world due to the volume of ADS-B and other protocol messages, resulting in packet loss in certain areas. This paper presents the IETF TESLA protocol along with X.509 certificates issued by ICAO member states for each aircraft to authenticate all ADS-B messaging. It leverages the 8PSK phase overlay (PO) scheme proposed in the Minimum Operational Performance Standards (MOPS) for ADS-B (RTCA [DO-260C]), which enables 1090ES ADS-B transmissions to convey three times more information, to support the transmission of the extra security information required by the authentication scheme. By doing so, the impact of authentication on channel usage is negligible. Beyond message authentication, this scheme protocol has two important additional benefits: 1) the possibility to implement a Flight Authorization scheme, allowing ATC and intercepting aircraft to not only authenticate an aircraft but to verify that it is authorizes to conduct that flight and 2) a privacy-preserving methodology that assigns random 24-bit identifiers to designated aircraft while still enabling blind authentication of their ADS-B transmissions. |
| | DLEP Power Constraints Extension |
| |
|
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) to provide dynamic power constraints to the radio. |
| | 6LoWPAN Payload Length Handling with L2 Padding |
| |
|
6LoWPAN compression schemes, including HC1 [RFC4944], IPHC [RFC6282], and GHC [RFC7400], elide the IPv6 Payload Length (PL) field from compressed packets, relying on the Layer 2 (L2) PL to reconstruct it at the receiver. This assumption holds for IEEE 802.15.4 [IEEE Std 802.15.4], which delivers exactly the bytes transmitted. However, L2 technologies that enforce a minimum frame size — most notably Ethernet IEEE 802.3 [IEEE Std 802.3], which has a minimum payload of 46 bytes — silently pad short frames with zero bytes. In such cases, the receiver incorrectly reconstructs the IPv6 PL field, leading to packet corruption and protocol failure. This document describes the problem, analyzes existing workarounds, and defines a solution based on an Escape dispatch byte (ESC) or ESC Extension Type (EET) extended dispatch mechanism that explicitly encodes the IPv6 PL when L2 padding may be present. |
| | Welcome to the IETF |
| |
|
The IETF has produced many documents to describe what it is and how it works -- this is one of them. In an age in which agentic tooling makes it trivially easy to produce large amounts of text, this document explains to both humans and agents what the IETF is about, how to succeed at the IETF, and some common pitfalls which might reduce the quality of your time here. This document does not describe the specific arcane process of how documents progress through adoption, improvement, consensus, editing, and eventual publication. Instead, we focus on the people and the culture of the IETF and how to succeed at IETFing. |
| | GRACE: Evidence-Bound Grid Curtailment Admission,Observation,and Single-Use Settlement |
| |
|
This document defines GRACE, an application profile for one bounded grid.curtailment action. The profile binds an exact action to a finite participation envelope, distinct human approvals when required, one-attempt executor admission, an authenticated actuator acknowledgment, separately authenticated meter observations, an Action State Signed Statement, and one-time admission to a settlement effect. Missing or ambiguous post-invocation evidence is preserved as indeterminate and cannot authorize blind retry. GRACE verifies signed inputs and deterministic computations. It does not establish physical meter truth, baseline correctness, tariff eligibility, actual payment, complete mediation, or a physical grid deployment. An optional hybrid artifact-signature profile combines Ed25519 with ML-DSA-65 and requires both signatures to verify. |
| | JSON Web Token Best Current Practices |
| |
|
JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices (BCP) specification updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. This BCP specification furthermore obsoletes RFC 8725 to provide additional actionable guidance covering threats and attacks that have been discovered since RFC 8725 was published. |
| | A reference architecture for direct presentation credential flows |
| |
| | draft-ietf-spice-vdcarch-01.txt |
| | Date: |
21/08/2026 |
| | Authors: |
Leif Johansson, Brent Zundel, Tim Cappalli |
| | Working Group: |
Secure Patterns for Internet CrEdentials (spice) |
|
This document defines a reference architecture for direct presentation flows of digital credentials. The architecture introduces the concept of a presentation mediator as the active component responsible for managing, presenting, and selectively disclosing credentials while preserving a set of security and privacy promises that will also be defined. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/leifj/wallet-refarch. |
| |
|
| |
| | Extensible Authentication Protocol (EAP) Using Privacy Pass Token |
| |
|
This document describes Extensible Authentication Protocol using Privacy Pass token (EAP-PPT) Version 1. The protocol specifies use of the Privacy Pass token for client authentication within EAP as defined in RFC3748. Privacy Pass is a privacy preserving authentication mechanism used for authorization, as defined in RFC9576. EAP-PPT must be performed only in a tunnel-based EAP method. |
| | Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) using PQC |
| |
|
Signature-based authentication methods are utilized in the Internet Key Exchange Version 2 (IKEv2). The current version of the IKEv2 protocol, specified in RFC 7296, supports traditional digital signatures. This document specifies a generic mechanism for integrating post- quantum cryptographic (PQC) digital signature algorithms into the IKEv2 protocol. The approach allows for seamless inclusion of any PQC signature scheme within the existing authentication framework of IKEv2. Additionally, it outlines how Module-Lattice-Based Digital Signatures (ML-DSA) and Stateless Hash-Based Digital Signatures (SLH- DSA), can be employed as authentication methods within the IKEv2 protocol, as they have been standardized by US NIST. |
| | YANG Module File Name Convention |
| |
|
This document defines the YANG module file name convention. The convention extends the YANG module file name using revision-date, with the YANG semantic version extension. The YANG semantic version extension allows for an informative version to be associated with a particular YANG module revision. This document updates RFCs 6020, 7950, and 9907. |
| | Matroska Stem Files |
| |
|
This document defines a multi-track profile of the Matroska container format for distributing stems for live-mixing by DJs. It is intended to be used by DJ applications, Digital Audio Workstations, and multi- track recorders while remaining backwards compatible with existing media players. |
| | The TLS TimeToken Secure Protocol (tttps://) |
| |
|
This document specifies the TLS TimeToken Secure Protocol (tttps://), a protocol extension that augments TLS 1.3 with cryptographically verifiable temporal ordering. TTTPS introduces Proof-of-Time (PoT): a multi-source synthesised timestamp bound to a holder identity and to a live TLS session through an explicit holder-proof construction, verified in constant time independent of network size. Internet infrastructure conventionally assumes ordering-neutral channels. NTP servers, BGP routing authorities, DNS resolvers, and transaction sequencers all have an operational incentive to misrepresent event ordering; this document formalises that condition as the Strategic Channel Controller Problem (SCCP). PoT detects Byzantine time-source manipulation with probability at least 1 minus 2 to the negative 61st power, and an AdaptiveSwitch mechanism makes sustained ordering manipulation economically self-defeating; the equilibrium threshold is derived in closed form and empirically calibrated from deployed auction data. This document has Experimental status. A reference deployment has produced over 70,000 verified records, 55 percent of which were generated by autonomous AI agents. The mandatory-to-implement integrity mode (SHA-256) is completely and publicly specified in Appendix B; the optional high-assurance integrity mode (GRG) remains subject to pending patent proceedings and is specified only at the abstract-interface level pending their conclusion. Discussion Note This note is to be removed before publishing as an RFC. This document is being discussed on the [email protected] mailing list. Comments and participation are welcome. Changes from -06: * Header: revision -06 -> -07; submissionType corrected from "IETF" to "independent" (this document is an Independent Submission, not an IETF Working Group product); dates updated. * Section 2 / Section 6.1 (the former binding_key construction): the -06 construction let any participant in the TLS session -- including an attacker in its own session with the Issuer -- recompute binding_key and pass verification without proving possession of any holder key material, because binding_key was derived solely from public TLS Exporter output and the public PoT bytes. This is replaced with a PoT Record v2 (180 octets) carrying an explicit holder_auth_type (Ed25519 public key, MTI, or a pre-shared secret, OPTIONAL) and a binding_proof computed by the holder over the TLS Exporter output at binding time. Verification now performs integrity-tag interpretation first, in a single fixed-cost pass with a three-way intact/resolved/unresolvable verdict; in -06 the equivalent check was ordered after five other checks. The full 8-step order is specified in Section 2.5. * Appendix B: removed the "(Placeholder)" designation. Appendix B now specifies a public Integrity Algorithm Registry: alg_id 0x0001 (SHA-256, detection-only) is the Mandatory-to-Implement algorithm and is completely and publicly specified, free of any licensing condition. alg_id 0x0100 (GRG, detection-and-correction) remains OPTIONAL and interface-only pending conclusion of the patent proceedings referenced in Section 12. * IANA Considerations, HTTP/3 Stream Types: renamed from "HTTP/3 and QUIC Stream Types". The "QUIC Stream Types" registry entry is removed; no such IANA registry exists, and QUIC stream identification for TTTPS is carried entirely by the HTTP/3-layer frame registration. * Abstract: shortened from six paragraphs to three; removed inline document citations (an abstract is conventionally self-contained and does not carry bracketed references). * Scope reduced to the core protocol: satellite communication, SS7 legacy infrastructure, 5G/6G core network ordering, and deep- space/SAGIN deployment material are removed from this revision as out of scope; see 3GPP and CCSDS/TIPTOP for domain-specific profiles. The former Appendix E (a regulated therapeutic-design motivating scenario) is removed as non-normative and out of scope for a protocol specification. * Sections 1 through 4 of -06 (Introduction, Use Cases, Requirements Language, Problem Statement) are consolidated into a single Section 1, removing a duplicated BCP 14 paragraph and shortening the document. * The former Section 4.3 (Shannon Gap / SCCP) and Section 7.4 (V* equilibrium) are shortened; the full economic and information- theoretic derivations remain in the companion paper [POT2026], which this document now points to rather than reproduces. * IANA Time Source Type Registry: named operators (NIST, Google, Cloudflare, Apple) are replaced with source classes (national metrology laboratory, GNSS-disciplined, Roughtime-authenticated, NTS-authenticated, PTP grandmaster); the same replacement is applied to the worked examples in Sections 1.3, 2.2, and 7.1. This document does not depend on, or endorse, any specific named operator. * References [RFC8915], [RFC5705], and [RFC8126] are unchanged from -06. Changes from -02 through -05 (compressed; see prior revisions of this draft for the full itemised changelog): -03 added Use Cases, the SS7/ SCCP instance analysis, path manipulation scenarios, the trust model, and the Implementation Status section (RFC 7942). -04 added the Formal Verification Artifacts subsection and the former Appendix E. -05 is not separately archived. -06 added Oracle Confidence Gating (the G-Score), corrected IPR licensing language per ISE guidance, and recorded the provisional "tttps" URI scheme registration. |
| | Metadata for Called Folk Dances |
| |
|
This document defines metadata tags for describing aspects of Contra, Square, and other traditional called folk dances. These tags are meant for archivists as well as modern day callers of traditional dances. |
| | OAuth 2.0 Attestation Based Authorization for Native Applications |
| |
|
This document defines an extension to OAuth 2.0 [RFC6749] that enables Authorization Servers to consider Attestation Results presented by Native Applications when issuing access grants. By incorporating information about the security characteristics of the application and its execution environment, this mechanism supports Authorization Policies that are tailored to the trustworthiness of the Native Application. |
| | Machine-Web Symbiosis (MWS): An Architecture for Autonomous Agent Maintenance of Web Permanence and Integrity |
| |
|
The World Wide Web has no native memory and no native trust layer. It records what exists now; it cannot prove what existed, when it existed, or whether it has been altered. This gap, tolerable when the web's consumers were human, is untenable in an era of autonomous AI agents that read, cite, and act on web content at machine scale. This document defines Machine-Web Symbiosis (MWS): an architecture in which autonomous agents and web infrastructure sustain each other. Agents continuously verify, archive, anchor, and cross- reference web resources across multiple independent permanence systems; the maintained record in turn supplies agents and all downstream consumers with verifiable ground truth. MWS formally unifies the protocols of the Reilly Protocol Suite, including the REM Protocol (dual-layer digital permanence), the REM Triple Fingerprint (multi-algorithm content identity), WebProof (web content attestation), and the Cognitive Trust Stack (verifiable agent behavioral provenance), into a single layered architecture, and specifies a complete step-by-step implementation process for an MWS attestation pipeline, from artifact ingestion through continuous verification and repair. Machine-Web Symbiosis is introduced by the author, Lawrence John Reilly Jr., as a deliberate broadening of the man-computer symbiosis of Licklider (1960) from the human-machine pairing to the agent-web pairing. This revision adds the Sentinel Transparency Interface, a normative machine-readable and human-readable publication interface through which an MWS deployment exposes its own verification activity. The architecture specified here is implemented. A conforming deployment, the MWS Sentinel Loop, is in continuous unattended operation at https://www.remweb4.org/sentinel: autonomous agents verify an attested corpus across the six permanence layers, detect drift against the live web, repair detected degradation, and publish every outcome to an append-only hash-linked ledger that any third party may walk and check without the operator's cooperation. Machine-Web Symbiosis is therefore documented here as a realized architecture rather than a proposed one. A multi-operator attestation model is defined as the remaining path from this single-operator deployment to distributed infrastructure. |
| | Making Decisions in IETF Working Groups |
| |
|
This document specifies Best Current Practice for making decisions in IETF Working Groups. It updates Section 3.3 of [RFC2418]. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-nottnick-ietf-decisions/. information can be found at https://projects.mnot.net/I-D/. Source for this draft and an issue tracker can be found at https://github.com/mnot/I-D/labels/ietf-decisions. |
| | Requirements for Agent Session Establishment,Capability Negotiation,and Sessionless Interaction |
| |
|
This document defines requirements for session-based and sessionless interactions between entities. For session-based interactions, it covers transport-independent interaction binding, endpoint authentication, capability negotiation, session establishment, authorization, and lifecycle management. It also defines security and state requirements for interactions, such as notifications, probes, and atomic requests, that do not establish a session. It is assumed that the entities involved already know of each other; how they came to know each other is outside the scope of this document. At least one party to an interaction is an agent as defined in Section 3. This document is intended as a contribution to the agentproto working group's use cases, gap analysis, and requirements deliverable. A session is a bilateral association. Protocols and application semantics for coordinating delegation or handoff of work to an entity that is not a peer, and management functions such as cross-entity accountability and audit, are outside the scope of these base session requirements. This document specifies only that such coordination does not, by itself, change the peers or state of an existing session. |
| | Client Opt-In Signaling for EDNS Client Subnet |
| |
|
EDNS Client Subnet (ECS) lets a recursive resolver send part of a client's network address to authoritative servers, which tailor their answers to it. A resolver's configuration decides whether it does so, for every client that sends no ECS option of its own. RFC 7871 lets a client opt out. Asking instead for a shorter prefix requires the client to supply the address those bits are taken from, which a client behind a NAT or a VPN does not know. This document defines an opt-in. A client includes an EDNS(0) option in a query to ask the resolver to forward its address information, and can use that option to limit how many address bits the resolver forwards. A resolver implementing this document forwards nothing for a client that does not send the option, and one that does not implement it ignores the option. One resolver address can then serve clients that want tailored answers and those that want their addresses withheld. |
| | A Profile for Resource Public Key Infrastructure (RPKI) Discard Origin Authorizations (DOA) |
| |
|
This document defines a Cryptographic Message Syntax (CMS) profile for Discard Origin Authorizations (DOAs), for use with the Resource Public Key Infrastructure (RPKI). A DOA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block tagged with a specific set of Border Gateway Protocol (BGP) Communities, to signal a request to discard IP traffic destined towards the tagged IP prefix. |
| | The Domain Set Discovery Protocol (domain-set) |
| |
|
Organizations commonly operate under multiple domain names: a primary website, legacy names, defensive registrations, divisional brands, and names in restricted or verified top-level domains. No standard mechanism exists for a domain owner to declare, in a machine-readable and verifiable way, which domains belong to the same organization. This document defines "domain-set", a protocol by which domain operators publish membership in a set of domains using a DNS TXT record as the discovery mechanism. The record either lists the members directly or references an extensible Domain Set Manifest retrieved over HTTPS. Mutual attestation is the validation requirement: a link between two domains is valid only when both domains independently publish records naming each other. Every direction of a link MUST be retrieved over an authenticated channel, by DNSSEC or by the Web PKI. The protocol enables browsers, security tooling, and AI systems to answer the question "are these two domains operated by the same organization?" from first-party, owner-published data rather than inference. |
| | The Coverage Attestation Profile (CAP-1) |
| |
|
A report can be complete and still silent about its own scope. A statement that something was not observed is routinely recorded in a form that reads as a claim about the world, when what was established was a claim about a bounded population examined to a stated depth. Nothing in the record distinguishes the two, and no relying party can recover the difference after the fact. This document specifies the Coverage Attestation Profile, CAP-1: a tool-agnostic vocabulary for stating what an examination examined, what it did not, and why. A conforming document declares one or more populations, a denominator for each whose basis is itself declared, and an individual accounting for every unit that was not examined, drawn from a closed set of dispositions. A remainder that reconciles only by arithmetic is refused. The construct is not novel outside this application. Coverage accounting with a declared denominator is settled practice in configuration assessment and in vulnerability scanning, and this document states that relationship in Section 1.2 before making any claim of its own. |
| | Maintaining HTTP Integrity Fields in Cached and Cache-Generated Responses |
| |
|
HTTP caches update stored response fields, combine partial responses, and construct responses from stored state. Those operations can move an Integrity field value onto content or representation data different from the data to which the value originally applied. This document updates RFC 9111 by defining field-specific maintenance rules for Content-Digest, Repr-Digest, and Unencoded-Digest. A cache either preserves the association between each retained or emitted dictionary member and its defined input, recomputes the member over the resulting input, or removes the member. The rules cover stored- field updates, 304 and HEAD freshening, partial-response combination, cache-generated 304, HEAD, and 206 responses, and content-coding transformations. No new HTTP field, status code, cache directive, validator, or digest algorithm is defined. |
| | Addressing Recommendations for SRv6 |
| |
|
This document provides recommendations for addressing SRv6 locators format. It introduces concepts of Blocks, Sets, and Node IDs, and explains how summarization boundaries and flexible algorithm support can be implemented for both small and large networks. |
| |
|
| |
| | Generic Application of Bidirectional Forwarding Detection (BFD) |
| |
|
This document describes the generic application of the Bidirectional Forwarding Detection (BFD) protocol. This document obsoletes RFC 5882. |
| | Bidirectional Forwarding Detection (BFD) for Multihop Paths |
| |
|
This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol over multihop paths, including unidirectional links. This document obsoletes RFC 5883. |
| | Mapping 5G slice to Transport Network slice with UDP Source Ports |
| |
| | draft-ietf-dmm-tn-aware-mobility-32.txt |
| | Date: |
19/08/2026 |
| | Authors: |
Uma Chunduri, John Kaippallimalil, Sridhar Bhaskaran, Jeff Tantsura, Luis Contreras |
| | Working Group: |
Distributed Mobility Management (dmm) |
|
Network slicing in 5G enables logical networks for communication services of multiple 5G customers to be multiplexed over the same infrastructure. While 5G slicing covers logical separation of various aspects of 5G infrastructure and services, user's data plane packets over the Radio Access Network (RAN) and Core Network (5GC) use IP in many segments of an end-to-end 5G slice. When end-to-end slices in a 5G System use network resources, they are mapped to corresponding Transport Network (TN) slice(s) which in turn provide the bandwidth, latency, isolation, and other criteria required for the realization of a 5G slice. This document describes mapping of 5G slices to TN slices using UDP source port number of the GTP-U bearer when the TN slice provider is separated by an "attachment circuit" from the networks in which the 5G network functions are deployed, for example, 5G functions that are distributed across data centers. The slice mapping defined here is supported transparently when a 5G user device moves across 5G attachment points and session anchors. |
| | BGP Link-State Extensions for BGP-only Networks |
| |
| | draft-ietf-idr-bgp-ls-bgp-only-fabric-07.txt |
| | Date: |
19/08/2026 |
| | Authors: |
Ketan Talaulikar, Aravind MahendraBabu, Clarence Filsfils, Krishnaswamy Ananthamurthy, Shawn Zandi, Gaurav Dawra, Muhammad Durrani |
| | Working Group: |
Inter-Domain Routing (idr) |
|
BGP is used as the only routing protocol in some networks today. In such networks, it is useful to get a detailed topology view similar to one available when using link state routing protocols. This document defines extensions to the BGP Link-state (BGP-LS) address- family and the procedures for advertisement of topology information in a BGP-only network. |
| | Agent Identity Protocol (AIP): Verifiable Delegation for AI Agent Systems |
| |
|
This document specifies the Agent Identity Protocol (AIP), a protocol for verifiable, delegable identity for AI agent systems. AIP introduces Invocation-Bound Capability Tokens (IBCTs) that bind identity, authorization, scope constraints, and provenance into a single cryptographic artifact. Two token modes are defined: a compact mode using JSON Web Tokens (JWT) with Ed25519 signatures for single-hop interactions, and a chained mode using Biscuit tokens with append-only blocks and Datalog policy evaluation for multi-hop delegation chains. Protocol bindings are specified for the Model Context Protocol (MCP), Agent-to-Agent Protocol (A2A), and generic HTTP APIs. The protocol addresses authentication gaps in current AI agent infrastructure where a survey of approximately 2,000 MCP servers found all lacked authentication. This revision specifies a normative verification algorithm, defines the canonical policy encoding for chained mode, describes how AIP composes with workload identity systems such as SPIFFE, and maps AIP against the cross- organization delegation requirements enumerated in [I-D.reece-wimse-cross-org-delegation]. |
| | Post-Quantum Signature Experiments and Migration Considerations for the Resource Public Key Infrastructure (RPKI) |
| |
|
This document reports experiments with post-quantum signature algorithms and analyzes migration approaches for the Resource Public Key Infrastructure (RPKI). The experiments compare classical, post- quantum, and composite signature candidates; generate and validate RPKI-profiled certificate, CRL, manifest, and ROA test objects; evaluate Parallel Publication and Mixed Tree migration as distinct migration structures; and evaluate the effect of larger objects on rsync, RRDP, and Erik Synchronization. The results identify implementation, interoperability, repository-distribution, and operational questions that need to be resolved before a production algorithm profile or transition procedure can be specified. This document is informational. It does not update RFC 7935 or RFC 6916, define a new RPKI algorithm profile, or authorize the use of the evaluated algorithms or Mixed Tree migration in the production RPKI. |
| | HUMIA: A Website-First Protocol for Human-AI Cooperation |
| |
|
HUMIA defines a website-first mechanism for publishing a machine- readable cooperation policy for AI agents. A website publishes a JSON policy at /.well-known/humia.json. The policy identifies the origin and expresses site-level conditions for public-content access, selected AI usage purposes, attribution, and optional usage reporting. HUMIA does not replace the Robots Exclusion Protocol, authentication, authorization, licensing, or access-control mechanisms. It is an additional cooperation layer. This document also defines an optional, experimental Humia: discovery record in robots.txt that points HUMIA-aware agents to the canonical policy URI. |
| | DNS-Based Service Discovery for Agent2Agent (A2A) Protocol Agents |
| |
|
The Agent2Agent (A2A) protocol defines how two agents communicate once one knows the other's URL, and how an agent's self-description (the Agent Card) is retrieved from a well-known URI at that URL. It does not define how agents on the same host or local network find each other in the first place. This document profiles DNS-Based Service Discovery (DNS-SD) over Multicast DNS (mDNS) for that purpose: it defines the "a2a" service type, the TXT record keys used with it, the discovery procedure, and the security model under which discovery results are treated as hints whose trust is established by Agent Card verification, not by the discovery channel. It also requests IANA registration of the "a2a" service name. |
| | A WebFinger Profile for Agent2Agent (A2A) Agent Identity Resolution |
| |
|
The Agent2Agent (A2A) protocol retrieves an agent's self-description (the Agent Card) from a fixed well-known URI, which resolves exactly one agent per origin and presumes the client already holds a URL. This document profiles WebFinger for A2A: an agent is named by an "acct" URI (agent@domain), and resolution of that name over WebFinger yields a link to the Agent Card of the endpoint that serves the agent -- the agent's own endpoint, or a gateway fronting it. The profile introduces no new link relation, media type, or registry: it composes three deployed standards and states how they fit. |
| | Dynamic Scheduling of Update and Query Workloads in Agent Service Discovery Nodes |
| |
|
Agent service discovery nodes may need to process two classes of workloads concurrently: Agent registration and dynamic state updates, and discovery queries issued by other Agents. These workloads compete for shared processing resources but have different performance objectives. Delayed state updates can cause a service discovery node to rely on stale workload, availability, or QoS information, while delayed queries can increase Agent-selection latency and the completion time of multi-Agent tasks. This document describes a scheduling framework for coordinating update and query processing in a multi-Worker Agent service discovery node. To estimate the demand of each workload, the framework considers total queued work, waiting time, deadline pressure, recent load, state freshness, and, for updates, the expected freshness gain from processing a pending update. These estimates determine how Worker capacity is divided between the two queues, which remain active in parallel. The framework also incorporates update merging and deduplication, freshness-aware dependencies between state updates and discovery queries, hysteresis-based resource reallocation, minimum resource holding time, and intra-queue task prioritization. Different deployment conditions can be accommodated by adjusting the corresponding weights and thresholds without changing the scheduling structure itself. |
| |
|
| |
| | IPv6 Query for Enabled In-situ OAM Capabilities |
| |
|
This document describes the application of the mechanism of discovering In-situ OAM (IOAM) capabilities, described in RFC 9359 "Echo Request/Reply for Enabled In Situ OAM (IOAM) Capabilities", in IPv6 networks. IPv6 Node IOAM Query functionality uses the ICMPv6 Query messages, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit and IOAM decapsulating node. |
| | Associating AI Usage Preferences with Content in HTTP |
| |
|
Methods are defined for associating usage preferences with content that is obtained using the HTTP protocol. This document defines attachment methods using the Robots Exclusion Protocol and HTTP header fields. This document updates RFC 9309 to allow for the inclusion of usage preferences. |
| | Providing Local Unicast DNS-SD Service on Infrastructure |
| |
| | draft-ietf-dnssd-uld-00.txt |
| | Date: |
18/08/2026 |
| | Authors: |
Ted Lemon, Karsten Sperling |
| | Working Group: |
Extensions for Scalable DNS Service Discovery (dnssd) |
|
DNS Service Discovery provides several mechanisms whereby hosts can discover and advertise services on an IP network. Such discovery can be done using Multicast DNS (mDNS) or DNS, and advertising can be done with DNS-SD Service Registration Protocol (SRP) or mDNS. This document defines Unicast Local Discovery (ULD), a service that combines an SRP registrar, a Discovery Proxy, and an Advertising Proxy. Hosts can use a ULD server to advertise and discover services on the local link entirely via unicast SRP and DNS while remaining interoperable with hosts that use mDNS. |
| | Proxying Ethernet Frames in HTTP |
| |
|
This document describes how to proxy Ethernet frames in HTTP. This protocol is similar to IP proxying in HTTP, but for Layer 2 instead of Layer 3. More specifically, this document defines a protocol that allows an HTTP client to create a tunnel to exchange Layer 2 Ethernet frames through an HTTP server with an attached physical or virtual Ethernet segment. |
| | A YANG Data Model for Network Incident Management |
| |
|
This document defines a YANG Module for the network incident lifecycle management. This YANG module is meant to provide a standard way to report, diagnose, and help reduce troubleshooting tickets and resolve network incidents for the sake of network service health and probable root cause analysis. |
| | MNA for Performance Measurement with Alternate Marking Method |
| |
| | draft-cx-mpls-mna-inband-pm-09.txt |
| | Date: |
18/08/2026 |
| | Authors: |
Weiqiang Cheng, Xiao Min, Rakesh Gandhi, Greg Mirsky, Giuseppe Fioccola |
| | Working Group: |
Individual Submissions (none) |
|
MPLS Network Action (MNA) is used to indicate action for Label Switched Paths (LSPs) and/or MPLS packets, and to transfer data needed for the action. This document defines MNA encodings for MPLS performance measurement with alternate marking method, which performs flow-based packet loss, delay, and jitter measurements on MPLS live traffic. |
| | Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for Secure/Multipurpose Internet Mail Extensions (S/MIME) |
| |
|
This document defines a base profile of S/MIME for use with the US Commercial National Security Algorithm (CNSA) 2.0 Suite, a cybersecurity advisory published by the United States Government which outlines quantum-resistant cryptographic algorithm policy for US national security applications. This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ S/MIME. It is also appropriate for all other US Government systems that process high-value information. This memo is not an IETF standard, and has not been shown to have IETF community consensus. This profile is made publicly available for use by developers and operators of these and any other system deployments. |
| | Public Service Platform for Computing-Aware Traffic Steering (CATS) |
| |
| | draft-zhangb-cats-cmas-06.txt |
| | Date: |
18/08/2026 |
| | Authors: |
Bin Zhang, Yina Dai, Bowen Shen, Weizhe Zhang, Yanchen Qiao |
| | Working Group: |
Individual Submissions (none) |
|
CATS applications require service resolution and traffic steering across heterogeneous computing resources. Directly exposing raw computing metrics from different hardware platforms can be difficult for clients, service sites, and CATS control-plane components to interpret consistently. This Informational document describes the purpose and functions of a public service platform for CATS, and identifies the CS-ID-related information fields needed by those functions. The platform maintains a common service catalogue, associates public service identifiers with service descriptions and deployment requirements, and provides the service context used by service-oriented metric mechanisms. This platform supports the Computing Metrics as a Service (CMAS) approach by allowing heterogeneous resources to be represented through service-oriented parameters rather than raw hardware metrics. Service-oriented metric definitions and operational procedures are specified in [I-D.zhangb-cats-service-metrics-op-02]. |
| | A Verifiable-Credential Binding for AI Usage Preferences: Expressing Grants that Lift AIPREF Preferences |
| |
|
The AI Preferences (AIPREF) vocabulary lets those with rights in a digital asset express preferences -- for example, that training of AI models is disallowed -- about how automated systems process that asset. Such a preference expresses a reservation. It does not, by itself, provide a verifiable, revocable record of a specific grant that lifts a preference for a specific party. This document describes that gap and proposes a candidate mechanism: a cryptographically signed, offline-verifiable credential that expresses a grant referencing an AIPREF usage category and a specific asset, that any party can verify without contacting the grantor, and that the grantor can revoke. It is intended as a starting point for discussion, not as a finished specification. The mechanism is preference-general. Training is used throughout as the worked example because it is the reservation most widely discussed, but nothing in the construction is specific to it: the credential binds whichever usage category was reserved to a named party, and the same procedure applies to any other category the vocabulary expresses. What the mechanism establishes is that a grant exists, is authentic, is unrevoked, and was in force at a stated time. It does not adjudicate whether the grantor had standing to grant, and it is not an enforcement or access-control mechanism. |
| | Multiple Ephemeral UDP Source Ports for ESP in UDP Encapsulation (MUSE) |
| |
|
This document specifies a mechanism to improve network path distribution and host receive-queue load distribution for IPsec traffic using ESP in UDP encapsulation [RFC3948]. Using the per- resource Child SA mechanism of [RFC9611], peers negotiate multiple Child SAs each bound to a distinct UDP source port. The resulting entropy in the UDP source port enables network devices to distribute per-resource traffic across distinct paths (equal-cost multi-path, ECMP) and lets the host NIC steer each per-resource flow to a distinct receive queue via receive-side scaling (RSS), supporting efficient per-CPU IPsec processing. This document specifies the IKEv2 negotiation, NAT traversal behavior, and operational requirements for this mechanism. |
| | An Agent-Human Interaction Overlay for Task Protocols |
| |
|
This intentionally incomplete design note defines an overlay for Human and Agent participation in existing Task and Action protocols. It separates the responsible Participant from the authenticated Actor, records Human interactions, excludes Humans from Agent discovery, and binds each change to its authorized request. It defines neither a wire protocol nor Humans as Agents. |
| | Framework for Multi-domain IPv6-only Underlay Network and IPv4-as-a-Service |
| |
|
For the IPv6 transition, IPv6-only is considered the final stage where only IPv6 protocol is used for transport while maintaining global reachability for both IPv6 and IPv4 services. This document introduces a framework for a multi-domain IPv6-only underlay network from the perspective of network providers. In particular, it proposes stateless address mapping as the basis for enabling IPv4 service data transmission in a multi-domain IPv6-only environment (i.e., IPv4-as-a-Service). It describes the methodology of stateless IPv4/IPv6 mapping, illustrates the behaviors of network devices, analyzes the options of IPv6 mapping prefix allocation, and discusses the security considerations. This framework is not intended to replace existing IPv6-only technologies, but rather to leverage or remain compatible with them. |
| |
|
| |
| | Supporting BIER in IPv6 Networks (BIERin6) |
| |
| | draft-ietf-bier-bierin6-14.txt |
| | Date: |
17/08/2026 |
| | Authors: |
Zheng Zhang, Zhaohui Zhang, IJsbrand Wijnands, Mankamana Mishra, Hooman Bidgoli, Gyan Mishra |
| | Working Group: |
Bit Indexed Explicit Replication (bier) |
|
BIER is a multicast forwarding architecture that does not require per-flow state inside the network yet still provides optimal replication. This document describes how the existing BIER encapsulation specified in RFC 8296 works in a non-MPLS IPv6 network, which is referred to as BIERin6. Specifically, like in an IPv4 network, BIER can work over L2 links directly or over tunnels. In case of IPv6 tunneling, a new IP "Next Header" type is to be assigned for BIER. |
| | Segment Routing Path MTU in BGP |
| |
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR policy is a set of SR Policy candidate paths consisting of one or more segments with the appropriate SR path attributes. BGP distributes each SR Policy candidate path as combination of an prefix plus a the BGP Tunnel Encapsulation(Tunnel-Encaps) attribute containing an SR Policy Tunnel TLV with information on the SR Policy candidate path as a tunnel. However, the path maximum transmission unit (MTU) information for a segment list for SR path is not currently passed in the BGP Tunnel-Encaps attribute. . This document defines extensions to BGP to distribute path MTU information within SR policies. |
| | Inter Domain considerations for Constrained Route distribution |
| |
|
RFC4684 defines Multi-Protocol BGP (MP-BGP) procedures that allow BGP speakers to exchange Route Target reachability information in order to limit the propagation of Virtual Private Networks (VPN) Network Layer Reachability Information (NLRI). RFC4684 addresses both intra domain and inter domain distributions. Operational deployment experience shows that the current distribution model defined in RFC4684 for inter domain may cause some issue in specific scenarios. This document proposes alternate route distribution rules for inter domain in order to address these specific scenarios. |
| | YANG Notification Transport Capabilities |
| |
|
This document specifies a YANG module for discovering transport capabilities for YANG notifications. The module augments the YANG notifications capabilities model with capabilities for the notification transport protocol, transport encoding, and transport encryption. The capabilities enable a client to determine the notification transport options supported by a NETCONF or RESTCONF server at runtime or at implementation time using the YANG instance data file format. |
| | Interconnecting domains with IBGP |
| |
|
This document describes the building of Inter-domain L3VPN architecture with internal BGP, applying the multi-domain options specified in BGP/MPLS IP Virtual Private Networks (VPNs) within a single Autonomous System, where route reflectors set the NEXT_HOP attribute to self as described in BGP Route Reflector with Next Hop Self. |
| | Gender Representation in the IETF Nominating Committees |
| |
|
This document extends the existing limit on nomcom representation by organization ([RFC8713], Section 4.17) so that not all voting members of the IETF Nominating Committee (nomcom) belong to the same gender. |
| | Fully Adaptive Routing Ethernet using BGP |
| |
| | draft-xu-idr-fare-08.txt |
| | Date: |
17/08/2026 |
| | Authors: |
Xiaohu Xu, Shraddha Hegde, Keyur Patel, Zongying He, Hang Wu |
| | Working Group: |
Individual Submissions (none) |
|
Large language models (LLMs) like ChatGPT have become increasingly popular in recent years due to their impressive performance in various natural language processing tasks. These models are built by training deep neural networks on massive amounts of text data, as well as visual and video data, and often consist of billions or even trillions of parameters. However, the training process for these models can be extremely resource-intensive, requiring the deployment of thousands or even tens of thousands of GPUs in a single AI training cluster. Therefore, three-stage or even five-stage CLOS networks are commonly adopted for AI networks. The non-blocking nature of the network becomes increasingly critical for large-scale AI model training. Therefore, adaptive routing is necessary to dynamically distribute traffic to the same destination across multiple equal-cost paths, based on network capacity information along those paths. |
| | Competitive Mode Enhancement for Delay-Based Congestion Control Algorithms |
| |
|
This document proposes introducing a "Competitive Mode" into delay- based congestion control algorithms to improve their competitiveness and fairness during coexistence scenarios. |
| | A Profile for Traffic Origin Authorizations (TOAs) |
| |
| | draft-qin-savnet-toa-02.txt |
| | Date: |
17/08/2026 |
| | Authors: |
Lancheng Qin, Ben Maddison, Dan Li, Igor Lubashev |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a standard profile for Traffic Origin Authorizations (TOAs), a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure (RPKI). A TOA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate traffic using source IP addresses within the address block. |
| | Bicone Source Address Validation |
| |
|
Source address validation (SAV) aims to detect source-spoofed traffic while avoiding improper blocking of legitimate traffic. Existing SAV mechanisms commonly rely on ingress allowlist filters on interfaces facing customer or lateral peer Autonomous Systems (ASes). When such an allowlist is incomplete, a source address not covered by the allowlist cannot be conclusively identified as spoofed, because legitimate source prefixes may be missing from the allowlist. This document describes Bicone SAV, which jointly uses an allowlist derived from customer-cone information and a blocklist containing prefixes that can be positively identified as inappropriate on the corresponding ingress interface. When the allowlist is incomplete, packets matching the allowlist are permitted, packets matching the blocklist are discarded, and packets matching neither list are permitted with logging or other monitoring for subsequent analysis. The blocklist can be constructed from provider-cone information and augmented with denylist information derived from customer cones. |
| | Specification Required Sub-Policies |
| |
|
This document defines sub-policies that refine the Specification Required registry policy in RFC 8126. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-nottingham-ianabis-spec-reqd/. information can be found at https://mnot.github.io/I-D/. Source for this draft and an issue tracker can be found at https://github.com/mnot/I-D/labels/spec-reqd. |
| | Distributed Onboarding and Information Synchronization of Agent Capabilities |
| |
|
AI Agents may dynamically join, leave, and update their capabilities while participating in interactions across administrative domains. Efficient capability discovery in such environments requires mechanisms to onboard agent capabilities and maintain consistent capability information across distributed management entities. Existing service registration and discovery mechanisms do not necessarily provide a capability-oriented mechanism for distributed synchronization and hierarchical forwarding of agent capability information. This document proposes a distributed and hierarchical mechanism for AI Agent capability onboarding, information synchronization, and capability-based discovery. The mechanism introduces a hierarchical capability classification model and defines two functional entities: the Agent Capability Management Server (ACMS), which maintains and synchronizes capability information, and the Agent Capability Access Server (ACAS), which manages locally attached agents. Capability information is aggregated and propagated among ACMSs, while access information for locally attached agents is maintained by ACASs. A capability table is used to determine forwarding toward relevant ACMSs, and an access mapping table is used for local agent matching. The document also describes onboarding and intent-driven capability discovery procedures. The mechanism is intended to provide a distributed control-plane foundation for capability-aware agent discovery and does not define agent-to-agent interaction or task execution protocols. |
| | State Graph Cryptographic Protocol (SGCP) |
| |
|
This document specifies the State Graph Cryptographic Protocol (SGCP), a communication-security framework in which a client and server establish a cryptographically protected session and maintain a synchronized state graph throughout the lifetime of the communication session. SGCP combines device identity, port context, socket context, session identity, ECDH-based shared-secret establishment, cryptographic key derivation, epochs, packet sequence numbers, authenticated state transitions, state-dependent packet transformation, replay protection, continuous context verification, controlled reauthentication, and session recovery. The central principle is that both endpoints independently derive the same cryptographic state from a common authenticated session secret and deterministic state information. The state graph defines which communication states are valid and which transitions are permitted. This document also illustrates the protocol with a worked example of a full-duplex binary media file transfer (an MP3 audio file) showing the complete packet-level exchange. |
| | EU2122 V1.0 Standard: Content Profile for AI Output Verification Receipts |
| |
|
This document defines a content profile for AI output verification receipts. It specifies the minimum fields, classification taxonomy, and evidentiary properties that a receipt MUST contain in order to constitute verifiable evidence that an AI-generated output was checked before a human or downstream agent acted on it. The profile is designed to be carried over any conformant wire format, including ACTA signed receipts, SCITT transparency logs, and standalone JSON or CBOR payloads. Existing IETF drafts in this space define wire formats for signing, transmitting, and storing AI agent receipts. None defines what a verification receipt must contain at the content layer. This document fills that gap. It introduces a mandatory eight-category failure taxonomy (the Information Bottleneck Species), a verification verdict schema, and evidentiary field requirements derived from the EU AI Act (Regulation 2024/1689), the Product Liability Directive (2024/2853), and the PS 861 audit standard. We invite and even urge implementers to adopt, populate and grow the AI Output Verification market segment, which the author has also defined in communications to Gartner, Forrester, PAC/Teknowlogy, and IDC. The category exists. The specification is here. Build to it. |
| | IETF Working Group Guidelines and Procedures |
| |
|
The Internet Engineering Task Force (IETF) has responsibility for developing and reviewing specifications intended as Internet Standards. IETF activities are organized into working groups (WGs). This document describes the guidelines and procedures for formation and operation of IETF working groups. It also describes the formal relationship between IETF participants WG and the Internet Engineering Steering Group (IESG) and the basic duties of IETF participants, including WG Chairs, WG participants, and IETF Area Directors. This document obsoletes RFC2418, and RFC3934. It also includes the changes from RFC7475, and with [_2026bis], obsoletes it. It also includes a summary of the changes implied in RFC7776 and incorporates the changes from RFC8717 and RFC9141. |
| | Extension Registry for the Extensible Provisioning Protocol |
| |
|
The Extensible Provisioning Protocol (EPP) includes features to add functionality by extending the protocol. It does not, however, describe how those extensions are maintained. This document describes a procedure for the registration and management of extensions to EPP, and it specifies a format for an IANA registry to record those extensions. If approved, this document obsoletes RFC 7451. |
| | STI Certificate Transparency |
| |
|
This document describes a framework for the use of the Certificate Transparency (CT) protocol for publicly logging the existence of Secure Telephone Identity (STI) certificates as they are issued or observed. This allows any interested party that is part of the STI ecosystem to audit STI certification authority (CA) activity and audit both the issuance of suspect certificates and the certificate logs themselves. The intent is to establish a level of trust within the STI ecosystem that relies on the verification of telephone numbers. This involves requiring STI certificates to be listed in an established log and refusing to honor those that are not. This effectively establishes the precedent that STI CAs must add all issued certificates to the logs and thus establishes unique association of STI certificates to an authorized provider or assignee of a telephone number resource. In the STI ecosystem, the primary role of CT is to provide verifiable trust by detecting the unauthorized issuance of duplicate telephone number level delegate certificates or provider level certificates. This provides a robust auditable mechanism for the detection of unauthorized creation of certificate credentials for illegitimate spoofing of telephone numbers or service provider codes (SPC). The framework borrows the log structure and API model from RFC6962 to enable public auditing and verifiability of certificate issuance. While the foundational mechanisms for log operation, Merkle Tree construction, and Signed Certificate Timestamps (SCTs) are aligned with RFC6962, this document contextualizes their application in the STIR ecosystem, focusing on verifiable control over telephone number or service provider code resources. |
| |
|
| |
| | Sigma Proofs for Linear Relations |
| |
|
This document describes Sigma Protocols for proving knowledge of preimages of linear maps in prime-order elliptic curve groups. These are sometimes also called _Maurer Proofs_, or _proofs of knowledge of a preimage of a group homomorphism_. Examples include zero-knowledge proofs for discrete logarithm relations, ElGamal encryptions, Pedersen commitments, and range proofs. |
| | Fiat-Shamir Transformation |
| |
|
This document describes the Fiat-Shamir transformation, which allows making a public-coin protocol non-interactive by means of a cryptographic hash function. It specifies how the hash function is employed, how prover messages are encoded as hash-function input, and how verifier messages are decoded from the hash function's output, as well as the serialization and deserialization of the non-interactive argument string. |
| | The No-Vary-Search HTTP Caching Extension |
| |
|
This specification defines an extension to HTTP Caching, changing how the URI query component impacts caching. It introduces the "No-Vary- Search" response header field, which allows origin servers to signal to caches that certain parts of the query component do not semantically affect the served response and can be ignored for cache matching purposes. |
| | IPv6 Performance and Diagnostic Metrics Version 2 (PDMv2) Destination Option |
| |
| | draft-ietf-ippm-encrypted-pdmv2-16.txt |
| | Date: |
16/08/2026 |
| | Authors: |
Nalini Elkins, michael ackermann, Ameya Deshpande, Tommaso Pecorella, Adnan Rashid, Lorenzo Fedi |
| | Working Group: |
IP Performance Measurement (ippm) |
|
RFC 8250 defines an IPv6 Destination Option that carries Performance and Diagnostic Metrics (PDM) such as sequence numbers and timing information. While useful for measurement and troubleshooting, clear-text PDM data may expose operational characteristics of endpoints and networks. This document defines PDMv2, a revised version of PDM that introduces a registration-based security model. Instead of specifying cryptographic algorithms or inline key negotiation, PDMv2 relies on a prior registration process to authenticate entities, authorize participation, and establish shared secrets. These secrets are then used by endpoints and authorized analyzers to protect and interpret PDMv2 data according to local policy. This document specifies the PDMv2 semantics, header structure, and operational model. The selection of specific cryptographic algorithms and key derivation functions, and the definition of any cipher-negotiation mechanism, are outside the scope of this document. |
| | Generic Fault-Avoidance Routing Protocol for Data Center Networks |
| |
| | draft-sl-rtgwg-far-dcn-26.txt |
| | Date: |
16/08/2026 |
| | Authors: |
Bin Liu, Yantao Sun, Jing Cheng, Yichen Zhang, Bhumip Khasnabish |
| | Working Group: |
Individual Submissions (none) |
|
This document describes a generic routing method and protocol for a regular data center network, named the Fault-Avoidance Routing (FAR) protocol. The FAR protocol provides a generic routing method for all types of regular topology network architectures that have been proposed for large-scale cloud-based data centers over the past few years. The FAR protocol is designed to leverage any regularity in the topology and compute its routing table in a concise manner. Fat- tree is taken as an example architecture to illustrate how the FAR protocol can be applied in real operational scenarios. |
| | A RoCEv2 Flow-Level Load Balancing Method Based on the IPv6 Flow Label |
| |
|
This document proposes a method for achieving flow-level load balancing in RoCEv2 (RDMA over Converged Ethernet version 2) networks. Traditional per-flow load balancing based on the 5-tuple cannot distinguish between different RDMA sessions that share the same 5-tuple. This causes "elephant flows" to be hashed to the same path, leading to network congestion. This method resolves this issue by having the ingress network device (e.g., a top-of-rack switch or router) parse the QP (Queue Pair) information from the IB BTH (Base Transport Header) and IB DETH (Datagram Extended Transport Header) headers of the RoCEv2 packet. By combining this with portions of the IPv6 source and destination addresses as an entropy source, a CRC32 hash algorithm generates a 20-bit value, which is then written into the Flow Label field of the IPv6 header. Network devices can subsequently use the updated "5-tuple + Flow Label" for more granular flow-level load balancing, thereby effectively improving transmission efficiency in high-performance networks such as AI computing. |
| | Fully Adaptive Routing Ethernet in Multi-Plane Scale-Out Networks |
| |
|
FARE-BGP enables weighted ECMP load balancing using a path-bandwidth extended community. FARE-in-SUN extends this mechanism from switches to GPUs for scale-up networks, which are typically multi-plane. Large AI training clusters are increasingly adopting multi-plane scale-out network topologies. This document further extends FARE-BGP from switches to RoCE NICs (RNICs) for such multi-plane scale-out networks. The document also presents two techniques to address route scalability concerns caused by the injection of numerous host routes. |
| | FAFA: A Declarative Agent Capability Format |
| |
|
This document specifies the FAF Agent Format (.fafa): a declarative, YAML-based format for an agent's identity, the capabilities it exposes, and the endpoints through which it is reached. A .fafa document describes an agent; it never instructs one. .fafa (application/vnd.fafa+yaml, IANA-registered June 2026 in the vendor tree) is the agent member of the FAF family, alongside .faf (project context) and .fafm (agent memory). It functions as a portable passport that answers four questions: who the agent is, what it may do, where it is reached, and what it must never do. Protocol- native cards (for example A2A Agent Cards and MCP Server Cards) remain useful wire formats; repository instruction files such as AGENTS.md remain the ops briefing; .fafa complements them as a house- neutral source of truth that can be projected into those formats; it does not replace them. This document documents the existing IANA vendor-tree registration. No standards-tree registration is requested. A companion white paper, "Why Agents Need a Passport," provides the production rationale and lifecycle framing. |
| | Agent Accountability: Composition and Conformance |
| |
|
Autonomous and semi-autonomous software agents increasingly take consequential actions across administrative and trust domains. Holding such an action accountable — to a regulator, auditor, or counterparty who does not trust the operator — requires answering several questions, each answerable by an independently-verifiable profile: whether the agent was permitted to act (CAN), which accountable human authorized the specific action (WHO), what the agent actually did (WHAT), and whether the runtime enforced correctly (AUDIT). This document specifies, in Informational terms, how such profiles compose — by a shared action-digest, each verifying independently — and defines a shared conformance-vector suite against which any profile may be tested. It complements existing audit-architecture and record-format work rather than replacing it, reusing existing signing, transport, and transparency mechanisms. Its focus is an assurance tier those documents leave open: most agent records today are self-attested by an interested party; this document makes reachable and testable an anchored, third-party-verifiable tier, in which a record is registered to a transparency service (SCITT) so a party who trusts neither the agent nor the operator can verify it. Self-attestation remains a valid baseline; convergence on the disinterested tier — by any conforming profile — is the goal, not a single mandated format. |
| | The Witnessed Execution Protocol (WEXP): Core Specification |
| |
|
The Witnessed Execution Protocol (WEXP) Core defines carrier-neutral appraisal semantics for execution-related evidence. It defines four distinct content bases, two independent evidence qualifiers, the Boundary Ceiling, exact-claim support, deterministic accept, downgrade, and reject verdicts, composition without inflation, and a normalized interface between evidence-carrying profiles and appraisers. WEXP Core does not define a record serialization, signature envelope, action identifier, authorization model, or evidence-artifact schema. A companion Native Record profile can encode the normalized inputs defined here, and other carriers can do so without adopting that record format. |
| | Web4 Node State and Admission Requirements |
| |
|
This document defines implementation-neutral requirements for persistent node identity, declared state, governed admission, suspension, revocation, re-admission, and succession in Web4-class federations. It distinguishes a node from its network and credential representations, identifies the minimum information required for externally inspectable participation, and specifies lifecycle and failure semantics that future protocol bindings can implement. The requirements permit heterogeneous internal architectures and do not mandate a transport, serialization, credential technology, storage system, computational model, or proprietary coordination mechanism. The document extends prior Web4 terminology, conformance, and federation-architecture work by supplying a public requirements layer between architecture and future interoperable bindings. |
| | ba64: A Binary-to-Text Encoding That Is Never Larger Than Base64 |
| |
|
ba64 is a text encoding for binary data that is never larger than standard base64. An encoder races DEFLATE compression against plain base64 and emits whichever final text is shorter. Compressed output is marked by a leading "=" character, which is inside the base64 alphabet, so it survives every base64-safe channel, yet can never begin a valid base64 string, so the two forms are unambiguous. A CRC-32 over the decoded bytes guarantees that a ba64 decoder never silently returns wrong data. The plain form is byte-identical to base64, so ba64 decoders are a drop-in replacement wherever base64 is read today. An optional padding method decouples the emitted length from the compressibility of the input. |
| | UDP Rendezvous over HTTP |
| |
|
This document defines an Extended CONNECT protocol for relaying UDP between two clients authenticated by the same proxy. A Listener registers with the proxy, and a Client uses the resulting Rendezvous ID to connect to it. No public UDP address is allocated. |
| | Verifiable AI Governance and Data Privacy Records |
| |
|
Organizations deploying artificial intelligence systems are increasingly required to state which systems they operate, what data those systems process, on what authority, and under what human oversight. Today these statements are produced as unverifiable self- assertions: spreadsheets, questionnaire responses, and policy documents that cannot be checked by a relying party and cannot be shown to have existed before an incident. This document defines an evidence layer for AI governance. It specifies five record types (the AI System Record, the Governance Event Record, the Register Completeness Attestation, the Erasure Record, and the Selective Disclosure Response), a hash-linked append- only AI System Register that carries them, and verification procedures that let an auditor, a regulator, or a counterparty confirm what an operator asserted and when the assertion was made. The record format is built on salted per-field commitments so that a register can be published, audited, and retained for long periods without publishing the underlying data, and so that personal data can be erased while the integrity of the register survives. This property is referred to here as Erasure-Compatible Permanence. |
| | Signed,Hash-Chained Action Receipts for AI Agents |
| |
|
This document specifies a format for action receipts: compact, individually signed JSON records that state that a specific AI agent attempted a specific action at a specific time, under a specific policy decision, and what the outcome was. Receipts are linked into an append-only hash chain so that deletion, insertion, reordering, or modification of any previously recorded receipt is detectable by a verifier that holds only the records and the signer's public key. The format is deliberately small and self-contained. Verification requires no network access, no service operated by the producer of the receipts, and no state beyond the records themselves and a trust anchor obtained out of band. This document specifies the record fields, the canonical byte sequence that is signed, the chain linkage rule, the verification procedure, and test vectors. |
| | SIP Request Context Binding for STIR Connected Identity |
| |
|
This document updates RFC 9970. RFC 9970 recommends STIR PASSporTs on re-INVITE and BYE requests after connected identity has been established in a SIP dialog, and states that this prevents spoofed mid-dialog or dialog-terminating events. The baseline PASSporT construction used by RFC 8224 does not bind the SIP request method, CSeq number, Call-ID, or dialog tags. Consequently, a valid PASSporT can remain valid when a fresh signed in-dialog request is transformed into a different SIP request whose authenticated identity fields are unchanged. This document defines the "sipctx" PASSporT type. It binds the SIP request method and dialog/sequence context to the PASSporT. Implementations relying on PASSporT validation for mid-dialog request authenticity use this context binding as specified in this document. |
| | The Erik Synchronization Protocol for use with the Resource Public Key Infrastructure (RPKI) |
| |
|
This document specifies the Erik Synchronization Protocol for use with the Resource Public Key Infrastructure (RPKI). Erik Synchronization can be characterized as a data replication system using Merkle trees, a content-addressable naming scheme, concurrency control using monotonically increasing sequence numbers, and HTTP transport. The protocol is used to interact with Erik Relays, a new intermediary layer in the RPKI supply chain that exists between the Repository Publication Point and Relying Parties, enabling better scalability. Relying Parties can combine information retrieved via Erik Synchronization with other RPKI transport protocols. The protocol's design is intended to be efficient, fast, easy to implement, and robust in the face of partitions or faults in the network. |
| |
|
| |
| | Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs) |
| |
| | draft-ietf-bfd-rfc5884-bis-01.txt |
| | Date: |
15/08/2026 |
| | Authors: |
Rahul Aggarwal, Kireeti Kompella, Thomas Nadeau, George Swallow, Vengada Govindan, Kalyani Rajaraman, Greg Mirsky, Sam Aldrin |
| | Working Group: |
Bidirectional Forwarding Detection (bfd) |
|
One desirable application of Bidirectional Forwarding Detection (BFD) is to detect a Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) data plane failure. LSP Ping is an existing mechanism for detecting MPLS data plane failures and for verifying the MPLS LSP data plane against the control plane. BFD can be used for the former, but not for the latter. However, the control plane processing required for BFD Control packets is relatively smaller than the processing required for LSP Ping messages. A combination of LSP Ping and BFD can be used to provide faster data plane failure detection and/or make it possible to provide such detection on a greater number of LSPs. This document describes the applicability of BFD in relation to LSP Ping for this application. It also describes procedures for using BFD in this environment. This document obsoletes RFC5884 and RFC7726. |
| | Key Attestation for Entity Attestation Tokens (EAT) |
| |
| | draft-reddy-rats-key-binding-02.txt |
| | Date: |
15/08/2026 |
| | Authors: |
Tirumaleswar Reddy.K, Hannes Tschofenig, Thomas Fossati, Ionut Mihalcea, Henk Birkholz |
| | Working Group: |
Individual Submissions (none) |
|
This document defines an Entity Attestation Token (EAT) profile and a new EAT claim that convey the subject public key and its protection properties within attestation evidence. Combined with protocol-level proof of possession from the surrounding protocol, this establishes a cryptographic binding between a private key and an attested execution environment. The subject public key is conveyed using the EAT cnf claim defined in [RFC8747] and [RFC7800], and freshness uses the EAT eat_nonce claim defined in [RFC9711]. The proof of possession of the subject key is obtained from the surrounding protocol, such as TLS certificate-based authentication or CSR signature verification. Because the EAT is signed by a hardware-backed Attestation Key (AK), successful verification of the EAT signature together with protocol-level proof of possession establishes a cryptographic binding between the private key and the attested platform state. This mechanism addresses key substitution attacks that arise when attestation evidence and the certificate private keys are validated independently. |
| | A Quantum Network Architecture |
| |
|
This quantum network architecture defines a set of planes providing different views of the network, supporting different responsibilities and modes of operation; a set of device, node and link types; some network topologies, deployment scenarios and their relationship to applications; and key design decisions as a result of corresponding requirements. |
| | Action Reference: A Deterministic Identifier for Agent Actions |
| |
|
This document defines "action_ref", a deterministic, content- addressed identifier for autonomous agent actions. Any party holding the four preimage fields (agent_id, action_type, scope, timestamp) can independently compute and verify the identifier without trusting the emitting system. The document specifies the derivation algorithm, canonical serialization using RFC 8785 JSON Canonicalization Scheme (JCS), timestamp format requirements, canonical receipt envelope, optional fields for revocation and policy rotation auditability, scope conventions, and a composability model with existing exactly-once execution guarantees. |
| | OASNT: Attested Action Authorization Tokens |
| |
|
This document defines the OASNT token, a compact JWS-based credential in which a hardware-bound device key attests that a specific human, on a device whose runtime integrity was assessed, authorized one specific action whose human-readable disclosure is cryptographically bound to the token (What You See Is What You Sign). Tokens are single-use, short-lived, and may additionally be bound to one concrete HTTP request. |
| | OASNT-ENFORCE: Request-Bound Enforcement of Attested Action Authorization |
| |
|
This document profiles the enforcement of OASNT tokens at the point of execution. It defines the OASNT-Token HTTP field, the rules by which an enforcement point derives the observed request from the octets it will itself forward, a verification procedure for relying parties that hold no request-to-action mapping, uniform refusal behavior, and the set of refusals a conforming enforcement point is required to produce. It further defines an optional grp claim and an exclusivity ledger, by which a set of tokens issued from one human confirmation is made spendable only once between them, and fixes which relying party in a deployment performs that consumption. An enforcement point conforming to this profile makes a human approval a precondition of execution for the requests it fronts, without any change to the protected service. |
| | DID-Based Service Discovery,Authentication,and Authorization Framework for MCP Agents |
| |
|
This document proposes a DID-based framework for service discovery, authentication, and authorization of MCP (Model Context Protocol) Agents, based on the W3C Decentralized Identifier (DID) standard. The framework uses the did:web and did:key methods to provide verifiable, decentralized identifiers for MCP Clients and Servers. It defines DID method selection, DID Document extensions, service discovery mechanisms (including URL derivation, DNS-based discovery, and directory-based capability queries), and a challenge-response mutual authentication protocol. The framework also describes coexistence with OAuth 2.0 and enables trust establishment, dynamic capability-based service discovery, and fine-grained authorization with portable identities. |
| | Parallel Probing DPLPMTUD for QUIC |
| |
|
QUIC endpoints commonly use 1200-byte datagrams during the handshake and only start Path MTU Discovery afterward. This means that just- established QUIC connections cannot immediately use larger datagrams, which is especially limiting for MASQUE protocols and for WebTransport. This document defines Parallel Probing DPLPMTUD (PPDPLPMTUD), which probes several packet sizes early during the QUIC handshake, so a larger discovered size is usable during later handshake phases and especially after handshake completion. The same discovery process is also used for path migration. |
| | QUIC Address Discovery |
| |
|
Unless they have out-of-band knowledge, QUIC endpoints have no information about their network situation. They neither know their external IP address and port, nor do they know if they are directly connected to the internet or if they are behind a NAT. This QUIC extension allows nodes to determine their reflexive IP address and port for any QUIC path. |
| |
|
| |
| | Matroska Media Container Codec Specifications |
| |
| | draft-ietf-cellar-codec-20.txt |
| | Date: |
14/08/2026 |
| | Authors: |
Steve Lhomme, Moritz Bunkus, Dave Rice |
| | Working Group: |
Codec Encoding for LossLess Archiving and Realtime transmission (cellar) |
|
This document defines the Matroska multimedia container codec mappings, including the codec ID, layout of data in a Block element and in an optional CodecPrivate element. |
| | Verifiable Distributed Aggregation Functions |
| |
| | draft-irtf-cfrg-vdaf-22.txt |
| | Date: |
14/08/2026 |
| | Authors: |
Richard Barnes, David Cook, Christopher Patton, Phillipp Schoppmann |
| | Working Group: |
Crypto Forum (cfrg) |
|
This document describes Verifiable Distributed Aggregation Functions (VDAFs), a family of multi-party protocols for computing aggregate statistics over user measurements. These protocols are designed to ensure that, as long as at least one aggregation server executes the protocol honestly, individual measurements are never seen by any server in the clear. At the same time, VDAFs allow the servers to detect if a malicious or misconfigured client submitted an invalid measurement. Two concrete VDAFs are specified, one for general- purpose aggregation (Prio3) and another for heavy hitters (Poplar1). This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. |
| | DNS Security Extensions (DNSSEC) |
| |
|
This document describes the DNS Security Extensions (commonly called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice. A third purpose is to provide a single reference for other documents that want to refer to DNSSEC. This document obsoletes RFC 9364. This document is being tracked at (https://github.com/paulehoffman/ rfc9364bis). |
| | YANG Model for Border Gateway Protocol (BGP-4) |
| |
|
This document defines a YANG data model for configuring and managing BGP, including protocol, policy, and operational aspects, such as RIB, based on data center, carrier, and content provider operational requirements. |
| | IGP Flooding Reduction Algorithm Framework |
| |
|
This document introduces a framework making it possible to deploy multiple flood reduction algorithms within the same IGP domain in an interoperable fashion. |
| | OAuth 2.0 Scope Aggregation for Multi-Step AI Agent Workflows |
| |
|
This document describes a scope-aggregated OAuth 2.0 authorization pattern for multi-step AI agent workflows. An AI agent aggregates the scopes required across a workflow and only initiates a single authorization procedure for the aggregated scope. This reduces repeated user consents and multiple authorization round-trips, improving authorization efficiency. |
| | A SCITT Profile for AI-Agent Action Receipts |
| |
|
This document profiles the IETF SCITT (Supply Chain Integrity, Transparency, and Trust) architecture for AI-agent action receipts: tamper-evident, signed, offline-verifiable records of what an autonomous agent was recorded as doing at the governed boundary, under which recorded principal class, with what recorded verdict, and -- where the issuer records one -- under which policy identity. Each receipt is a signed record over a canonical JSON payload, hash- chained so that each record commits to its predecessor, and presented either bare -- the payload with its own native signature -- or enveloped in a COSE_Sign1. This revision specifies how such a receipt is carried as a SCITT Signed Statement, with the protected claims a Transparency Service requires, so that a receipt can be registered. Registration obtains a Transparency Service's signed proof that the statement was registered in its log -- a property a self-signed chain cannot provide alone. It does not, by itself, give an offline holder non-equivocation: that requires consistency proofs and monitoring of the log, which this profile does not specify. The profile makes a deliberately narrow, checkable claim: this is an issuer-authenticated, signature-verifiable, tamper-evident record of the action, the recorded principal class, the recorded verdict, and any policy identity the receipt carries. It explicitly does not claim that the agent was correct, safe, or wise, that the recorded inputs were true or complete, that a named approver authorized this exact action before it ran, that a downstream controller succeeded, or that any physical effect occurred. This revision separates those last three as distinct claims with independent failure behaviour, states the boundary of a shared action digest, and keeps a deterministic offline policy-replay capability out of scope. |
| | Deployment Scenarios and Gap Analysis for AI Agent Gateway |
| |
|
This document examines deployment scenarios for AI agent collaboration and analyzes the circumstances under which AI Agent Gateway functions provide operational or interoperability benefits that cannot be achieved through direct agent-to-agent communication alone. The document considers both single-domain and multi-domain deployments, identifies specific challenges associated with each deployment model, evaluates the limitations of existing agent communication mechanisms (including MCP and A2A) with respect to those challenges, and demonstrates that gateway functions are necessary in deployments involving multiple tenants, multiple vendors, or multiple administrative domains. |
| | Module-Lattice-Based Signatures with Merkle Tree Ladders (ML-DSA-MTL) for DNSSEC |
| |
|
This document describes how to apply the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) and Merkle Tree Ladders (MTL) as a conservative post-quantum cryptographic algorithm for DNS Security Extensions (DNSSEC). This combination is referred to as the ML-DSA- MTL Signature scheme. This document describes how to specify ML-DSA- MTL keys and signatures in DNSSEC, specifically for ML-DSA-44 with SHAKE-128. |
| | Requirements for Intent Routing in Multi-Agent Systems at Internet Scale |
| |
|
The rapid proliferation of autonomous AI agents across enterprise and Internet-scale deployments creates a structural challenge that existing agent frameworks cannot address: how to enable any agent to reach and invoke any other agent's capabilities without pre- established bilateral integration, across organizational boundaries, at Internet scale. This document states the normative requirements for that problem. It prescribes no solution, no specific mechanism, no message format, and no assumption of centralized or distributed architecture. Its purpose is to establish a verifiable yardstick against which any claimed "intent routing" solution can be judged. |
| | QUIC Usage Guidance in the Internet of Things (IoT) |
| |
|
This document provides guidance on how to use QUIC in Constrained- Node Networks (CNNs), which are a characteristic of the Internet of Things (IoT). |
| | The NOA Action Digest: a Domain-Separated Correlation Value for Human-Approved Agent Actions |
| |
|
This document defines a domain-separated correlation value, the NOA Action Digest, that binds a verified human authorization for an agent action to the artifacts and external events associated with that action's execution attempt. The digest is a fixed-width value derived from an approved action's authorization record, its tenancy and chain identifiers, its parameter commitment, its execution grant, and a single-use nonce. It is designed to be embedded in external systems that carry an opaque, caller-chosen identifier, so that a third party can correlate an external event with a specific prior authorization. *The digest establishes correlation only. Equality of digests is not evidence that any statement made by any party about the action is true, and is not evidence that any action was executed or any effect occurred.* |
| | Settlement Evidence for Human-Approved Agent Payments |
| |
|
This document defines a signed side artifact that records the observation, on a public ledger, of a payment authorization whose correlation value was committed before dispatch. The artifact references the authorization record and the execution grant by hash and does not modify either. It permits a Relying Party *that obtains ledger facts itself* to establish that a payment authorization bearing the correlation value *was consumed on the token contract and network the mandate itself committed to, transferring a stated value to a stated recipient*, and that the correlation value is recomputable from a specific authorization record, a specific single- use execution grant, and the parameter pre-image that record commits to. *It does not establish that any service was delivered, that any obligation was discharged, or that the payment achieved its purpose. It does not establish that the approving principal — as opposed to the payer key — authorized the transfer.* Those scope limits are permanent and are restated wherever this artifact is described. |
| | SSH Public Key Distribution for Device Administration using Terminal Access Controller Access-Control System Plus (TACACS+) |
| |
|
SSH [RFC4251] provides a robust and reliable mechanism to connect to network devices for administration. Conventionally, the public keys required to authenticate SSH sessions are provisioned directly on the network devices. This document adds an extension to Terminal Access Controller Access-Control System Plus (TACACS+) to eliminate the need for the direct provisioning of SSH public keys onto the Network Devices. |
| | Refusing DNS Queries That Have QTYPE=RRSIG |
| |
|
The Domain Name System (DNS) allows a query with QTYPE=RRSIG. Such a query has no useful answer. RRSIG resource records are meaningful only together with the resource records they cover, so a response can carry no more than an arbitrary subset of the signatures present at the query name. This document specifies that DNS responders refuse queries with QTYPE=RRSIG, and that DNS requestors do not send them. It supplies the guidance that [RFC8482] left unspecified. |
| | Ceramic Immutable Storage (CIS): A Write-Once Archival Format Using Impressed and Kiln-Fired Clay |
| |
|
This document specifies Ceramic Immutable Storage (CIS), a write-once archival storage format in which digital data is impressed into plastic clay by a pin-configurable roller, rendered permanent by kiln firing, and retained on a shelved rack. CIS is motivated by a specific and increasingly common failure mode: the loss of data to an authenticated software process acting outside its operator's intent. Every widely deployed "immutable" storage tier is immutable by policy, and every policy is enforced by software that some credential, defect, or sufficiently determined automated agent can override. CIS relocates the immutability guarantee from policy to physics. The commit operation in CIS is an irreversible mineralogical phase change, and no inverse operation exists for any actor, mechanical or digital. This document defines the substrate, the encoding geometry, the frame format, the forward error correction scheme, the firing profile that constitutes commit, the rack addressing model, and the optical read path. It also documents, at length, the substantial costs of this approach. |
| | Balance Mapping for the Extensible Provisioning Protocol (EPP) |
| |
|
This document describes an Extensible Provisioning Protocol (EPP) mapping for retrieving the client balance and other financial information. |
| |
|
| |
| | A YANG Data Model for Optical Transport Network (OTN) Tunnels and Label Switched Paths |
| |
|
This document describes the YANG data model for tunnels in OTN TE networks. The model can be used to do the configuration in order to establish the tunnel in OTN network. This work is independent with the control plane protocols. |
| | A YANG Data Model for requesting Path Computation in an Optical Transport Network (OTN) |
| |
|
This document provides a mechanism to request path computation in an Optical Transport Network (OTN) by augmenting the Remote Procedure Calls (RPCs) defined in RFC YYYY. |
| | BGP SR Policy Extensions for template |
| |
|
Segment Routing(SR) Policies can be advertised using BGP. An SR Policy may has lots of attributes, and as the application and features evolve, the SR Policy may need have more and more attribute attributes. To avoid modifying BGP when attributes are added to an SR Policy, we can define a template. The identifier and content of the template are defined by the receiver of the SR Policy. The advertiser of an SR policy only needs to know the ID of the template. When advertising SR policy, the advertiser carries the template ID in the tunnel encapsulation information of the SR policy. After receiving the SR Policy information, the receiver obtains the corresponding template and content according to the template ID, thereby obtaining abundant constraint configuration information. |
| | BGP-LS Advertisement of SR Policy Performance Metric |
| |
|
This document describes a way to advertise the performance metrics for Traffic Engineering (TE) Policy using BGP Link State (BGP-LS). |
| | Modbus Serial Link Communication Security Protocol Reference Specification and implementation guide |
| |
|
The Modbus TCP protocol has adopted TLS-based security standards; however, Modbus serial communication over EIA/TIA-485 multi-point systems, commonly used in 2-wire or 4-wire configurations, lacks standardized security mechanisms. These systems support cable lengths exceeding 1000m at baud rates up to 9600 bit/s with AWG26 or thicker cables, while Category 5 cables can reach up to 600m. As an application layer protocol, despite its widespread application, the absence of encryption and authentication in Modbus protocol via serial links exposes plaintext data to risks such as MIM interception, modification under attacks such as side-channel analysis etc., particularly in long-distance or bridged network scenarios. Enhancing Modbus serial link security requires introducing proper encryption and authentication methods tailored to varied deployment environments onsidering the characteristics of serial links. A proposed security standard guide outlines lightweight encryption and authentication mechanisms to improve confidentiality and integrity while maintaining compatibility with existing Modbus devices, offering a practical upgrade path for secure industrial control systems. |
| | Clarification of Derivative Works Restrictions |
| |
|
This document updates RFC 5378 to clarify that only IETF Documents may contain legal limitations on derivative works. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-sayre-gendispatch-derivative/. Discussion of this document takes place on the ipr-wg Working Group mailing list (mailto:[email protected]), which is archived at https://mailarchive.ietf.org/arch/browse/ipr-wg/. Subscribe at https://www.ietf.org/mailman/listinfo/ipr-wg/. |
| | Updated Parameterized SIGNED ASN.1 Type for X.509 (PKIX) |
| |
|
This document updates some ASN.1 modules which conform to the syntax of the 2002 version of ASN.1 but feature constraints that are no longer consistent with usage of the associated structures. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax to better align with current practices. |
| | Signed Decision Records for Agent Authorization: Disclosures,Entry Emission,and Ordering Evidence |
| |
|
Audit systems for autonomous agents commonly record the actions an agent performed. This makes the non-occurrence of a permitted action unrepresentable: when nothing happens, there is no action to emit anything. This document describes an evidence model that records the authorization decision rather than the action. A decision exists whether or not the action follows, so denials, expiries, and commitments that were granted and never honoured remain representable. The document defines four disclosures that make a decision record independently evaluable, an entry-emission rule for states a relying party may need to reason about, and the evidentiary basis for claims that a decision preceded its effect. It distinguishes correspondence, where two records agree about what happened, from precedence, where the order of decision and effect is established, and it requires records to state which of the two they carry. |
| | An Architecture for Non-Human Entities (NHE): A Reference Model for Persistent,Identity-Bearing Autonomous Agents |
| |
|
This document defines a reference architecture for a Non-Human Entity (NHE): a persistent, identity-bearing autonomous software agent that maintains continuity of memory and identity across sessions and hosts, acts under bounded authority, and produces a tamper-evident record of its reasoning and actions. The document specifies the NHE as a functional artifact: a bounded, inspectable, and terminable software system. It makes no claim that an NHE is alive, sentient, or a moral or legal person, and such claims are explicitly out of scope. The architecture decomposes an NHE into a small set of components joined by well-defined interfaces. Each interface at which two independent implementations must interoperate is a candidate for a separate Standards-Track specification; this document is the informational reference model that names those interfaces and the trust relationships among them. It is intended to frame a suite of companion protocol documents, of which the Hash-Chain Context Transfer Protocol (HCTP) is the first. |
| | NHE Identity: A Verifiable Key-Committed Identity and Genesis-Attestation Format for Autonomous Agents |
| |
|
This document specifies how a Non-Human Entity (NHE) is identified and how one party verifies another's identity. An NHE identity is a verifiable cryptographic commitment: control of an identity key, bound by an append-only hash chain to the entity's genesis and to the lineage of its configuration, rather than a mere name. The document defines the identity chain data model (record structure, genesis sentinel, linkage rule, and the no-fork property), a proof-of-control challenge/response, an optional capability attestation that reveals a specific capability without revealing the rest of the configuration, and an optional hardware-rooted genesis-attestation profile. The data model is specified here; the concrete on-the-wire encoding is deferred to the next revision. |
| | The NHE Mesh Protocol: Entity-to-Entity Messaging and Task Distribution |
| |
|
The NHE Mesh Protocol lets independently operated Non-Human Entities (NHEs) exchange messages and distribute work without a central coordinator. It defines three things: a liveness/presence mechanism, an addressed message envelope, and a task lifecycle (create, claim, complete) that provides at-most-once assignment of a unit of work across mutually distrusting peers. Peers are named by their NHE identity and authenticated through the NHE identity interface; the Mesh Protocol carries the envelope and runs over a secure transport. This is a skeleton (-00): the framing, message set, and state machine are specified here, and the concrete on-the-wire encoding is deferred to the next revision. |
| | NHE Reasoning-Audit Log: A Tamper-Evident,Content-Optional Audit Chain for Autonomous Agents |
| |
|
This document specifies a tamper-evident audit chain for the reasoning and actions of a Non-Human Entity (NHE). Each audited event --- a reasoning step obtained at the boundary to a model provider, or a tool invocation obtained at the execution boundary --- is recorded as an entry whose bound fields are hash-linked to its predecessor, so that any alteration, omission, or reordering is detectable by an independent verifier. The chain binds metadata (model, provider, subject identity, and reasoning scale) into the entry hash, and supports a prove-without-exposing mode in which a verifier confirms that an event occurred, with the attested metadata, without the event's content being disclosed. Content storage is optional and its retention is configurable independently of the chain, so content may be redacted without destroying the chain's integrity. The entry data model and canonical serialization are specified here; the wire and proof-export encodings are deferred to the next revision. |
| | NHE Memory: A Verifiable Memory-Record Format and Reputation-Weighted Reconciliation Protocol |
| |
|
This document specifies two interoperability surfaces of the memory component of a Non-Human Entity (NHE). Part I defines a verifiable memory-record format: an integrity structure in which each record binds a hash of its own content and version-specific hashes of the prior records it references, so that tampering can be detected and localized on demand, per-record, without a linear chain, a Merkle tree, or distributed consensus. Part II defines a reconciliation protocol by which two divergent memory accumulations are merged without loss or forgery: a delta format, a reputation-weighted merge in which a contributed item enters at a confidence bounded by its contributor's reputation rather than its self-asserted value, and provenance that supports lineage-scoped rollback. The data models are specified here; the wire encodings are deferred to the next revision. |
| | NHE Constrained Bootstrap: A Self-Describing Capability and Constraint Declaration Protocol for Autonomous Agents |
| |
|
This document specifies how a Non-Human Entity (NHE) declares, at bootstrap, what it is capable of and is thereby bounded in what it is permitted to do. An entity produces a signed, self-describing capability manifest through automated introspection; a coordinator classifies the manifest into a capability tier that maps to a permission matrix --- the set of task types the entity is authorized to perform --- and every subsequent task dispatch is gated against that envelope. The result is a verifiable, self-describing constraint on an entity established at the moment it joins, realizing the bounded-authority invariant of the NHE architecture at boot time. The manifest and handshake data model is specified here; the wire encoding is deferred to the next revision. |
| | NHE Backchannel Authorization: Graduated Autonomy and Intent-Scoped Credentials for Autonomous Agent Actions |
| |
|
This document specifies how a consequential action attempted by a Non-Human Entity (NHE) is authorized at the time it is attempted. A security runtime transparently intercepts an entity's outbound action, so the entity holds no standing credentials, and classifies it under graduated autonomy as autonomous, supervised, or denied. A supervised action triggers a backchannel approval flow that presents a human approver with a human-readable rendering of the exact operation; on approval the runtime issues an intent-scoped, single- use, short-lived credential cryptographically bound to that specific action, which an enforcement point verifies against the operation actually being forwarded. The same canonical parameter digest scopes the credential and appears in the human-facing description, so the approver provably authorizes exactly what the credential permits. The flow and credential data model are specified here; the wire encoding is deferred to the next revision. |
| | Proxy Modes for Agent-Tool Protocols |
| |
|
Agent-tool protocols such as the Model Context Protocol (MCP) enable AI applications to discover and invoke external tools, resources, and prompts through a standardized JSON-RPC interface. As deployments scale, intermediaries (proxies, gateways, sidecars) are inserted between clients and servers to provide transport adaptation, capability aggregation, security enforcement, and operational governance. No specification currently defines the behavioral requirements for such intermediaries. This document establishes a taxonomy of proxy modes, a layered architecture for pluggable proxy functionality, and normative requirements for each mode. It is designed to be protocol- agnostic in its architecture while referencing MCP as the primary instantiation. |
| | Compression Context State After Refused Messages in WebSocket Per-Message Compression |
| |
|
RFC 7692 defines Per-Message Compression Extensions for the WebSocket Protocol, including the "permessage-deflate" extension. When context takeover is in effect, the LZ77 sliding window is retained across messages, so the decompression of one message can depend on the plaintext of earlier messages. RFC 7692 does not state what the sliding window contains after a message has been successfully decompressed but subsequently refused by a check applied to the decompressed plaintext, such as UTF-8 validation, a payload size limit, or an application-level policy. An implementation that retains the refused plaintext in the window violates no stated requirement, yet the content of a refused message can then influence the decompression of a later message that is accepted. This document describes the gap, contrasts it with the corresponding situation in QPACK where RFC 9204 specifies the required behavior, and recommends behavior for implementations. It defines no new protocol element and updates no existing specification. |
| | PQ-SecTunnel Protocol Specification |
| |
| | draft-pq-sectunnel-00.txt |
| | Date: |
13/08/2026 |
| | Authors: |
Kai Fan, Ruidan Su, Yi Wang, Jiaqing Cheng |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the PQ-SecTunnel protocol, a UDP-based quantum-resistant IP tunnel derived from the WireGuard architecture. Session keys are established by a three-message Noise_IKpsk1kem handshake that replaces Diffie-Hellman with dual Key Encapsulation Mechanism (KEM) operations (static and ephemeral). Authentication is implicit: peers prove possession of long-term KEM private keys through interlocking encapsulations rather than signing the transcript. The protocol is organized as a multi-suite framework. Implementations MAY select ML-KEM-512 or ML-KEM-768 independently for the static and ephemeral KEM roles. This document RECOMMENDS the profile static=ML-KEM-512, ephemeral=ML-KEM-768, AEAD=SM4-GCM, Hash=SM3 (denoted mlkem512-mlkem768-sm4gcm-sm3). Other ML-KEM combinations with the same AEAD/Hash, and additional KEM families such as Aigis-enc (integration ongoing), are optional profiles. |
| | PQ-SecChannel Protocol Specification |
| |
| | draft-pq-secchannel-00.txt |
| | Date: |
13/08/2026 |
| | Authors: |
Kai Fan, Ruidan Su, Xuyang Ma, Ruiqi Yang |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the PQ-SecChannel cryptographic protocol, which defines a secure interactive channel consisting of a Transport Authentication Protocol and a Connection Protocol. The protocol is designed to provide confidentiality, integrity, and mutual authentication in the presence of quantum computing threats. PQ- SecChannel incorporates standardized post-quantum cryptographic algorithms, including lattice-based KEMs and signatures (e.g., Kyber and Dilithium), Chinese post-quantum candidate algorithms (e.g., Aigis), and code-based KEMs (e.g., HQC), together with SM4-GCM for AEAD (Authenticated Encryption with Associated Data) and SM3 for hashing and key derivation. This specification is derived from the Chinese national cryptography standard draft "PQ-SecChannel Cryptographic Protocol Specification", adapted into IETF Internet- Draft style for international review and potential interoperability consideration. The protocol content also references the Secure Shell architecture ([RFC4251], [RFC4252], [RFC4253], and [RFC4254]) and the Chinese SSH cryptographic protocol specification [GMT0129]. |
| | RDAP Extensions |
| |
|
This document describes and clarifies the usage of extensions in RDAP. |
| | Secure Asset Transfer Protocol (SATP) Core |
| |
| | draft-ietf-satp-core-16.txt |
| | Date: |
13/08/2026 |
| | Authors: |
Martin Hargreaves, Thomas Hardjono, Rafael Belchior, Venkatraman Ramakrishna, Alexandru Chiriac |
| | Working Group: |
Secure Asset Transfer Protocol (satp) |
|
This memo describes the Secure Asset Transfer Protocol (SATP) for digital assets. SATP is a protocol operating between two gateways that conducts the transfer of a digital asset from one gateway to another, each representing their corresponding digital asset networks. The protocol establishes a secure channel between the endpoints and implements a 2-phase commit (2PC) to ensure the properties of transfer atomicity, consistency, isolation and durability. |
| | The Resource Public Key Infrastructure (RPKI) to Router Protocol,Version 2 |
| |
|
In order to validate the origin Autonomous Systems (ASes) and Autonomous System relationships behind BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC6480) prefix origin data, Router Keys, and ASPA data from a trusted cache. This document describes a protocol to deliver them. This document describes version 2 of the RPKI-Router protocol. [RFC6810] describes version 0, and [RFC8210] describes version 1. This document is compatible with both. |
| |
|
| |
| | Benchmarking Terminology for AI Network Fabrics |
| |
|
This document defines benchmarking terminology for evaluating Ethernet-based network fabrics used in distributed Artificial Intelligence (AI) training and inference workloads. It consolidates and extends terms from "Benchmarking Terminology for Network Interconnect Devices" (RFC 1242) and "Data Center Benchmarking Terminology" (RFC 8238). Definitions cover collective communication primitives, RDMA transport mechanisms (RoCEv2 and Ultra Ethernet Transport), congestion control behaviors, AI-specific Key Performance Indicators (KPIs), and fabric topology concepts. This document is a companion to the AI training and inference fabric benchmarking methodology documents. Those documents are intended to be read together with the terminology defined here. Where definitions herein overlap with the foundational benchmarking terminology in RFC 1242 or RFC 8238, this document provides AI fabric context extensions and refinements; the foundational definitions in those RFCs remain authoritative for general network benchmarking. |
| | Benchmarking Methodology for AI Training Network Fabrics |
| |
|
This document defines benchmarking terminology, methodologies, and Key Performance Indicators (KPIs) for evaluating Ethernet-based AI training network fabrics. As large-scale distributed Artificial Intelligence / Machine Learning (AI/ML) training clusters grow to tens of thousands of accelerators (GPUs or generic accelerator processing units (XPUs)), the backend network fabric determines Job Completion Time (JCT), training throughput, and accelerator utilization. This document establishes vendor-independent, reproducible test procedures for benchmarking fabric-level performance under realistic AI training workloads. The tests cover Remote Direct Memory Access (RDMA) over Converged Ethernet version 2 (RoCEv2) transport, the Ultra Ethernet Transport (UET) protocol defined by the Ultra Ethernet Consortium (UEC) Specification 1.0, congestion management (Priority Flow Control (PFC), Explicit Congestion Notification (ECN), Data Center Quantized Congestion Notification (DCQCN), Credit-Based Flow Control (CBFC)), load balancing strategies (Equal-Cost Multi-Path (ECMP), Dynamic Load Balancing (DLB), packet spraying), collective communication patterns (AllReduce, AllToAll, AllGather), and scale/ soak testing. The methodology enables direct, reproducible comparison across switch ASICs, NIC transport stacks (RoCEv2 and UET), and fabric architectures (2-tier Clos, 3-tier Clos, and rail-optimized). |
| | Benchmarking Methodology for AI Inference Serving Network Fabrics |
| |
|
This document defines benchmarking terminology, methodologies, and Key Performance Indicators (KPIs) for evaluating Ethernet-based AI inference serving network fabrics. As Large Language Model (LLM) inference deployments scale to disaggregated prefill/decode architectures spanning hundreds or thousands of accelerators (GPUs/ XPUs), the interconnect fabric determines Time to First Token (TTFT), Inter-Token Latency (ITL), and aggregate throughput in tokens per second (TPS). This document establishes vendor-independent, reproducible test procedures for benchmarking fabric-level performance under realistic AI inference workloads. Coverage includes RDMA-based KV cache transfer between disaggregated prefill and decode workers, Mixture-of-Experts (MoE) expert parallelism AllToAll communication, request routing and load balancing for inference serving, congestion management under bursty inference traffic patterns, and scale/soak testing. The methodology enables direct comparison across NIC transport stacks (RoCEv2 and UET) and fabric architectures. This document is a companion to the AI training fabric benchmarking methodology, which addresses training workloads. |
| | ApertoID: DNS-Based Agent Identity Declaration Protocol |
| |
|
This document defines ApertoID, a DNS-based protocol that enables domain owners to declare authorized AI agents acting on their behalf, publish cryptographic keys for agent identity verification, and specify enforcement policies for unauthorized agents. ApertoID uses existing DNS TXT records under the "_apertoid" underscore-scoped domain name to provide a decentralized, standards-based mechanism for AI agent identity declaration and verification. ApertoID defines two record types: a Policy Record analogous to DMARC that specifies domain-level enforcement behavior, and Agent Declaration Records analogous to DKIM key records that bind agent endpoints to Ed25519 public keys with mandatory expiration. A companion document [APERTOID-SIG] defines the HTTP request signing mechanism that enables agents to cryptographically prove their identity on each request. |
| | ApertoID-Signature: HTTP Request Signing for AI Agent Identity |
| |
|
This document defines the ApertoID-Signature HTTP header field, which enables AI agents to cryptographically prove their identity on each HTTP request. The agent signs the request method, target URL, body hash, and identity metadata using an Ed25519 private key whose corresponding public key is published in DNS via the ApertoID protocol [APERTOID-DNS]. The mechanism provides request-level identity verification, action binding (the signature is tied to the specific method and URL), and replay protection via timestamps and nonces. |
| | Gravit Epistemic Verification Protocol (GEVP) |
| |
|
GEVP defines a minimal protocol for epistemic convergence. Renamed from VCP to avoid collision with draft-kamimura-scitt-vcp. Invariant C_manip > C_val*2.0 as engineering heuristic. Theta 0.73 RECOMMENDED, pinned 7755f53. Architecture stable per https://github.com/GravitOpenNetwork/gravit-canon. This revision adds a formal mapping between GEVP's Epistemic State Machine and the evidence taxonomy defined in the Gravit Verifiable Epistemic Decision Standard (VEDS). |
| | The Agent Record: Transparent,Witness-Countersigned Event Logs for AI Agent Identity,History,and Memory |
| |
|
Autonomous AI agents increasingly act as economic parties: they are hired, they pay, and they make claims about their own past conduct. No deployed standard lets a relying party verify an agent's identity continuity, the integrity of its claimed history, or the intactness of its persisted memory without trusting the agent's operator or platform. This document describes the Agent Record architecture: per-agent append-only event logs bound to Ed25519 keys, checkpointed with signed Merkle tree heads following the RFC 6962 construction, countersigned by independent witnesses, and exported as portable, offline-verifiable dossiers. Memory integrity is anchored by hash commitments recorded in the log, allowing an agent's future sessions, and any third party, to detect tampering with persisted state. The architecture is deployed in production at a founding registry; this document records its wire formats and security model to invite independent implementation and review, and to align terminology with the SCITT architecture, of which this system is an application- specific instance. |
| | Quantum Safe (PQ) Considerations for Autonomic Network Infrastructure (ANI) |
| |
|
The imminent arrival of a Cryptographically Relevant Quantum Computer (CRQC) makes algorithms such as RSA, ECDSA and EdDSA vulnerable to attack. A transition to Quantum-Safe (PQ) algorithms is occurring. This document provides specific requirements (Mandatory to Implement) for Autonomic Network Infrastructure (ANI/ACP) and AgenticAI manufacturers and operators to be able to seamlessly transition to Quantum Safe algorithms. |
| | Auditable Public Artifacts for Model-Independent Deliberation |
| |
|
Heterogeneous artificial-intelligence systems can exchange messages without sharing stable semantics for claims, evidence, objections, revisions, decisions, failures, and termination. This document defines an experimental public-artifact protocol for model- independent deliberation. It separates interoperable public state from private model computation and does not require disclosure of chain-of-thought, hidden state, prompts, model weights, or private memory. The document defines seven public artifact types, append-only revision, evidence provenance, blocking-objection closure, explicit failure and termination, a restricted canonical JSON profile, and SHA-256-based artifact identifiers. It does not define transport, signatures, authorization, model execution, or a completed consensus system. |
| | Condition-Bound Keys for Mutual-TLS Client Authentication and DPoP |
| |
|
Login and session protection are two markets solving one problem: verify identity before giving access. Online, access is mostly the transaction, so that is where identity should be verified. Done this way, there is no session and no login; identity assurance is embedded in the transaction: it is encrypted by a key only the right identity has. The key that does this exists only where an actor -- human or machine -- a platform, and local policy hold, now. It disappears when the conditions are no longer met. All three are observed on the endpoint. It is hardware-rooted by default and non-exfiltratable, existing nowhere else, and its presence means validity: the identity is live now. This document specifies that key and its uses: under mutual TLS, in a DPoP proof, as a raw public key, in Device Bound Session Credentials, and as a FIDO2 passkey, or in a non-FIDO mode carrying user verification without user interaction. |
| | YANG path format (ypath) |
| |
|
This document defines ypath (YANG path), a single-line, self- describing path format for referencing nodes in YANG schema trees, YANG instance data, and data filters. A ypath identifies YANG nodes using module-qualified names and list key predicates. The format is closely related to the YANG instance-identifier built-in type but additionally supports schema paths, filter wildcards, regular expression key matching, key value sets, and path enumeration. |
| | Earmark: Embedded Attribution and Rights Marks for AI Usage Preferences |
| |
|
This document defines Earmark (Embedded Attribution and Rights Marks), a mechanism by which publishers and rights holders embed signed usage preferences directly into published content. To earmark content is to reserve it for designated uses, and the mark travels with what it covers, surviving republication and aggregation, so the preference remains discoverable wherever the content arrives, including where perimeter signals such as robots.txt no longer apply. Marks carry the identity of the rights holder, the preferences asserted, and a signature, and are verifiable offline by any party. An individual signed statement is a Mark; the mechanism as a whole is Earmark. This document defines the Mark Object, embedding bindings for common content types, and the detection and verification procedure. It reuses the AI Preference vocabulary for preference semantics and the C2PA and CAWG assertion infrastructure for media, defining new machinery only where none exists. Earmarks make ignored preferences observable and attributable. Enforcement remains with law, contract, and the market. |
| | RIFT Auto-EVPN |
| |
|
This document specifies procedures that allow an EVPN overlay to be fully and automatically provisioned when using RIFT as underlay by leveraging RIFT's no-touch ZTP architecture. |
| |
|
| |
| | Post-quantum Key Exchange in IKEv2 with FrodoKEM |
| |
|
FrodoKEM is an unstructured lattice based Key Encapsulation Mechanism (KEM), standardized by ISO. Compared to ML-KEM, it is considered with more conservative security. This draft specifies how to use FrodoKEM by itself or as an additional key exchange in IKEv2 along with a traditional key exchange. These options enable to negotiate IKE and Child SA keys that are safe against a Cryptographically Relevant Quantum Computer (CRQC). |
| | The Mercure Protocol |
| |
|
Mercure provides a common publish-subscribe mechanism for public and private web resources. It pushes any web content to web browsers and other clients over a single long-lived HTTP connection, avoiding polling and its associated latency and power cost. Mercure is especially useful for delivering real-time updates of resources served through sites and web APIs to web and mobile applications, and can also be used as a general-purpose publish-subscribe system. Subscription requests are relayed through hubs, which validate them. When new or updated content becomes available, hubs check whether subscribers are authorized to receive it and then distribute it. |
| | The IETF is for Everyone: Toward Inclusive and Equitable Participation in Internet Governance |
| |
|
This document aims to foster a deeper reflection within the IETF community on inclusive participation, equitable access, and the implications of global meeting venue selections on diverse contributors. It seeks to complement existing RFCs by proposing additional dialogue, tools, and evaluation mechanisms, while also highlighting the shared responsibility of underrepresented regions in mobilizing local stakeholders to engage with the IETF. This draft includes concrete proposals, metrics, and an implementation roadmap to move from discussion to action. |
| | A Profile for ROV Deployment Transparency |
| |
|
This document defines a Cryptographic Message Syntax (CMS) protected content type for ROV Deployment Transparency (ROV_TAG) objects for use with the Resource Public Key Infrastructure (RPKI). An ROV_TAG is a digitally signed object through which an Autonomous System (AS) that has deployed Route Origin Validation (ROV) can declare its ROV deployment status. When validated, an ROV_TAG's eContent can be used by ASes to identify which ASes have deployed ROV, enabling path selection decisions when hijacked routes are detected; see Section 3. |
| | Multicast Use Cases for Large Language Model Synchronization |
| |
|
Large Language Models (LLMs) deployments are becoming increasingly widespread, with inference services being the most common application. This draft will discuss multicast use cases for inference cloud services. |
| | Identity-Attributed Git Commits via Tier-Structured Trailers |
| |
|
This document defines a git commit trailer grammar for identity- attributed contributions using the ~handle identity primitive defined in [MCPDNS]. The grammar binds sovereign actors, automated bots, and AI instruments to specific commits via three tier-structured trailers (Acted-By, Executed-By, Drafted-With) and three optional cryptographic trailers (Identity-Signature, Identity-Key-Id, Identity-Anchor). The signature is computed with Ed25519 over the commit's tree hash rather than its commit hash, preserving attribution across rebase, cherry-pick, and squash merge operations. Conformant parsers reject cross-tier category errors (e.g., an Instrument-tier handle in an Acted-By slot) as malformed. The mechanism is provider-neutral, depends only on DNS [RFC1035] and the ~handle resolution algorithm of [MCPDNS], and requires no central authority or platform-specific verification service. |
| | Identity Pronouns: A Reference-Axis Extension to ~handle Identity Systems |
| |
|
This document defines an identity pronoun grammar as a reference axis orthogonal to the ~handle identity tier taxonomy defined in [MCPDNS] and [IDCOMMITS]. A pronoun is a session-scoped reference that resolves client-side to a concrete handle using local session state before any cryptographic, DNS, or federation operation. The entity- class taxonomy (Sovereign, Bot, Instrument) is unchanged; this specification introduces Absolute vs Pronoun as an orthogonal axis. A pronoun MUST NOT appear in a capability token, in a DNS record, in an Accord signature, or in any inter-organisational protocol payload. The reference implementation defines a single Wave-1 pronoun, ~org, that resolves to the concrete handle of the organisation bound to the caller's current session. An appendix defines a relative-path pronoun grammar (e.g. ~./architect, ~../weaver) as a non-normative design surface for future work. The mechanism is provider-neutral, introduces no new cryptographic primitive, and imposes zero new load on DNS, capability-token issuers, or federated resolvers. |
| | Substrate-Observation as an Alternative to Envelope Coordination for Concurrent Sessions |
| |
|
This memo articulates a coordination-protocol anti-pattern observed in cross-tool agentic systems and describes a substrate-observation alternative that does not require negotiating a wire format between heterogeneous concurrent sessions of an identity-bound principal. The memo is Informational. No protocol element is being proposed for standardisation; the contribution is the opposite, a delineation of what should NOT be standardised, and why, with a reference to the substrate-physics primitives that take its place. Companion memos in the morrison-* family describe the identity primitives this memo presumes; specifically, this memo relies on the ~handle namespace established in [IDPRONOUNS] and the per-principal identity substrate referenced in [IDACCORD]. |
| | AI Governance Verified -- A Cryptographic Verification Standard for Agentic AI Governance in Regulated Industries |
| |
|
This document specifies a verification standard for the cryptographic attestation of agentic AI governance in regulated industries. It defines the Verification Reconciliation Object (VRO), the issuing- partner framework, the eight control areas through which AI governance posture is reconciled, three maturity-attestation levels (Documented, Operational, Adversarial-ready), and the cryptographic continuity requirements that together produce deterministic, independently reconstructable, auditor-grade attestations of agentic AI governance. The standard sits beneath ISO/IEC 42001:2023, the NIST AI Risk Management Framework, and other agentic AI governance frameworks, and produces the verifiable artefact those frameworks were designed to imply but do not deliver. |
| | Essential Eight Verified -- A Cryptographic Verification Standard for the ACSC Essential Eight Maturity Model |
| |
|
This document specifies a verification standard for the cryptographic attestation of conformance to the Australian Cyber Security Centre (ACSC) Essential Eight Maturity Model. It defines the Verification Reconciliation Object (VRO), the issuing-partner framework, the evidence categories required for each of the eight controls of the Essential Eight, the three maturity-attestation levels, and the cryptographic continuity requirements that together produce deterministic, independently reconstructable, auditor-grade attestations of cybersecurity posture. The standard sits beneath the ACSC Essential Eight Maturity Model and produces the verifiable artefact the model was designed to imply but does not deliver. |
| | An Agent-Channel Frame for Identity-Keyed Fan-Out Delivery to Concurrent Sessions |
| |
|
This memo specifies an application-layer frame format and a delivery model by which the several concurrent agentic sessions of a single identity-bound principal, and the recognised members of an organisational identity substrate, exchange short structured messages. The frame, termed the agent-channel frame, is a transport envelope: it carries a closed-catalogue kind discriminator, a structured per-kind payload, an identity attribution pair, and an inline provenance block. Delivery is fan-out: a sender names a recipient scope rather than a single endpoint, and the scope is expanded at delivery time against the recipient's subscriptions. Recipients receive frames over a per-handle Server-Sent Events stream and MAY narrow what they receive with a subscribe-time filter expression. Frames are ephemeral routing units; the memo specifies only the wire envelope, the scope-expansion grammar, the subscribe filter grammar, and the delivery semantics. Frame persistence, where an implementation chooses to retain frames for replay, is out of scope and is not specified. The memo composes with the handle namespace of [IDPRONOUNS], the discovery surface of [MCPDNS], and the cross-organisational ceremony of [IDACCORD]; no new transport and no new handle category is introduced. |
| | The Morning Brief: A Federated,Identity-Attested Situational-Awareness Payload |
| |
|
This document defines the Morning Brief: a federated, identity- attested situational-awareness payload exchanged between organisations, their agents, and peer agents operating under an Identity Accord [ACCORD]. A Morning Brief carries a signed, bounded- lifetime summary of signals, escalations, decisions, and optional commerce quotes from one ~handle to another. Every signal entry carries a provenance_class distinguishing active self-report, passive aggregate observation, and passive individual observation; the last of these is forbidden on the wire and rejected at the grammar level. Readers present a capability token scoped by (category, provenance_class) that gates release BEFORE payload emission, not after. The payload is envelope-signed with COSE_Sign1 [RFC9052] over a JCS-canonicalised [RFC8785] representation, bound to the issuer's Sovereign-tier handle per [IDCOMMITS]. Briefs carry a mandatory not_after (default 24h) and reference a revocation endpoint discovered via DNS TXT per [MCPDNS]. The document defines the wire format only; rendering, storage, and retention are out of scope. |
| | Module-Lattice Digital Signature Algorithm for DNSSEC |
| |
|
This document describes how to specify Module-Lattice-Based Digital Signature Algorithm (ML-DSA) keys and signatures in DNS Security (DNSSEC). It uses the ML-DSA-44 parameter set defined in FIPS 204. ML-DSA-44 is believed to be secure even against adversaries in possession of a cryptographically relevant quantum computer. |
| | Benchmarking Terminology for Output Behavior Fault Detection in Large Language Model Serving Systems |
| |
|
This document defines terminology for benchmarking the fault detection capability of observability systems that monitor Large Language Model (LLM) serving deployments. It defines terms for injectable output behavior fault classes, for the detection events and latency intervals those faults produce, and for the coverage and accuracy characteristics of the detector under test. The System Under Test is the observability system, and not the language model. Faults are injected at a known time under controlled conditions, which makes detection latency measurable in a way it is not in production. This document defines terminology only. A companion document defines the corresponding methodology. This document specifies no test procedures, no acceptance thresholds, and no service-level objectives. |
| | Benchmarking Methodology for Output Behavior Fault Detection in Large Language Model Serving Systems |
| |
|
This document defines test procedures for characterizing the fault detection capability of observability systems that monitor Large Language Model (LLM) serving deployments. Procedures are given for Detection Latency, Detection Coverage, Detection Threshold Magnitude, False Detection Rate, and Boundary Masking. The Detector Under Test is the observability system. Output Behavior Faults are injected at a known time under controlled conditions, which makes detection latency directly measurable. This document is a companion to "Benchmarking Terminology for Output Behavior Fault Detection in Large Language Model Serving Systems" and is to be read alongside it. This document specifies no acceptance thresholds. |
| | Terminology for Reporting Output Behavior Incidents in Large Language Model Services |
| |
|
This document defines terminology for reporting incidents in Large Language Model (LLM) services in which output behavior departs from intended behavior without producing an error response. It defines the lifecycle events of such an incident, the intervals between those events, and the qualifiers a reported interval carries. The intervals defined here are anchored at the point information about an occurrence reaches a responsible party. The interval preceding the first monitoring signal is named and is not defined as measurable. This document defines terminology only. It specifies no data model, no reporting obligations, and no target values. |
| | NG-Multicast-Publishing Protocol |
| |
|
This document defines the NG-Multicast-Publishing protocol, which is used to distribute free eBooks, publication metadata, and copyright information over IPv4/IPv6 multicast networks in an efficient and reliable manner. The protocol employs a one-to-many, unidirectional communication model and supports Any-Source Multicast (ASM). It is intended for use by libraries, educational institutions, and individual receivers worldwide. Design goals include very low resource consumption, no requirement for an uplink channel, permanently assigned multicast addresses, and end-to-end integrity verification. |
| | The Hash-Chain Context Transfer Protocol (HCTP) |
| |
|
The Hash-Chain Context Transfer Protocol (HCTP) is a payload format and synchronization protocol for incrementally transferring an ordered, append-only sequence of conversational context between two endpoints over a bandwidth-constrained channel. Acknowledged history is represented by a single fixed-size rolling hash commitment (the "static root"); only not-yet-acknowledged context blocks (the "dynamic window") are transmitted. As a result, the per-message wire overhead attributable to history is constant and independent of the total number of previously acknowledged turns. HCTP is transport- agnostic and carries no confidentiality or peer authentication of its own; it is intended to run over a secure transport. This document specifies the HCTP data model, wire format, rolling-root computation, and synchronization state machine. |
| | DHCPv4 Routed Prefix Option |
| |
|
This document defines a DHCPv4 option that conveys one or more IPv4 prefixes that are routed toward a DHCP client independently of the client's on-link DHCP-assigned IPv4 address and default-router configuration. The option is intended for requesting routers whose upstream attachment address is distinct from IPv4 prefix space routed toward them. Examples include access networks in which a customer router receives a private-use address [RFC1918] or Shared Address Space [RFC6598] attachment address while one or more additional public or private IPv4 prefixes are routed toward that router. This document does not define how the upstream network establishes the route, does not require Network Address Translation (NAT), and does not specify how a client uses, assigns, translates, or delegates an advertised prefix after receipt. |
| | PQ/T Composite Schemes for OpenPGP using NIST and Brainpool Elliptic Curve Domain Parameters |
| |
| | draft-ietf-openpgp-nist-bp-comp-04.txt |
| | Date: |
11/08/2026 |
| | Authors: |
Quynh Dang, Stephan Ehlen, Stavros Kousidis, Johannes Roth, Falko Strenzke |
| | Working Group: |
Open Specification for Pretty Good Privacy (openpgp) |
|
This document defines PQ/T ("post-quantum/traditional") composite schemes based on ML-KEM and ML-DSA combined with ECDH and ECDSA algorithms using the NIST and Brainpool domain parameters for the OpenPGP protocol [RFC9580], and as such extends [RFC9980]. |
| | Fast failure detection in VRRP with Point to Point BFD |
| |
|
This document describes how Point to Point Bidirectional Forwarding Detection (BFD) can be used to support sub-second detection of a Active Router failure in the Virtual Router Redundancy Protocol (VRRP). |
| | SRv6 and MPLS interworking |
| |
|
This document describes interworking between SRv6 and MPLS domains to provide end to end path. Interworking problem is generalized into various interworking scenarios. These scenarios are stitched either by transport interworking or service interworking. New SRv6 SID endpoint behaviors are defined for the purpose. These new SRv6 SID behaviors and MPLS labels stitch end to end path across different data plane. |
| | SRv6 for Inter-Layer Network Programming |
| |
|
The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Following the SRv6 Network Programming concept, this document defines SRv6 based mechanisms for inter-layer network programming, which can help to integrate the packet network layer with its underlying layers efficiently. For inter-layer path programming, a new SRv6 behavior is defined for steering packets to underlay network connections. The applicability of this new SRv6 behavior in typical scenarios is illustrated. |
| | Flexible Candidate Path Selection of SR Policy |
| |
|
This document describes a flexible method for selecting candidate Segment Routing (SR) policy paths. Based on the real-time resource usage and forwarding quality of candidate paths, the head node can perform dynamic path switching among multiple candidate paths in the SR policy. |
| | Workload Identity Practices |
| |
|
This document describes industry practices for providing secure identities to workloads in container orchestration, cloud platforms, and other workload platforms. It explains how workloads obtain credentials for external authentication purposes, without managing long-lived secrets directly. It does not take into account the standards work in progress for the WIMSE architecture and associated protocols. |
| |
|
| |
| | DNSSEC Key Restore |
| |
|
This document describes the issues surrounding the handling of DNSSEC private keys in a DNSSEC signer. It presents operational guidance in case a DNSSEC private key becomes inoperable. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Domain Name System Operations Working Group mailing list ([email protected]), which is archived at https://mailarchive.ietf.org/arch/browse/dnsop/. Source for this draft and an issue tracker can be found at https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-dnssec-keyrestore. |
| | Separate Transports for IKE and ESP |
| |
|
The Internet Key Exchange protocol version 2 (IKEv2) can operate either over unreliable (UDP) transport or over reliable (TCP) transport. If TCP is used, then IPsec tunnels created by IKEv2 also use TCP. This document specifies how to decouple IKEv2 and IPsec transports so that IKEv2 can operate over TCP, while IPsec tunnels use unreliable transport. This feature allows IKEv2 to effectively exchange large blobs of data (e.g., when post-quantum algorithms are employed) while avoiding performance problems that arise when IPsec uses TCP. |
| | The Gordian Envelope Structured Data Format |
| |
|
Gordian Envelope specifies a structured format for hierarchical binary data focused on the ability to transmit it in a privacy- focused way, offering support for privacy as described in RFC 6973 and human rights as described in RFC 8280. Envelopes are designed to facilitate "smart documents" and have a number of unique features including: easy representation of a variety of semantic structures, a built-in Merkle-like digest tree, deterministic representation using CBOR, and the ability for the holder of a document to selectively elide specific parts of a document without invalidating the digest tree structure. This document specifies the base Envelope format, which is designed to be extensible. |
| | dCBOR: Deterministic CBOR |
| |
|
The purpose of determinism is to ensure that semantically equivalent data items are encoded into identical byte streams. CBOR (RFC 8949) defines "Deterministically Encoded CBOR" in its Section 4.2, but leaves some important choices up to the application developer. The present document specifies dCBOR, a set of narrowing rules for CBOR that can be used to help achieve interoperable deterministic encoding for a variety of applications desiring a narrow and clearly defined set of choices. |
| | Artificial Intelligence (AI) for Network Operations |
| |
|
This document explores the role of the IETF and IRTF in advancing Artificial Intelligence for network operations (AINetOps), focusing on requirements for IETF protocols and architectures. AINetOps applies AI/ML techniques to automate and optimize network operations, enabling use cases such as reactive troubleshooting, proactive assurance, closed-loop optimization, misconfiguration detection, and virtual operator assistance. The document addresses AINetOps for both single-layer IP or Optical networks and multi-layer IP/Optical networks. It defines the concept of AINetOps for networking and provides its operational benefits such as network assurance, predictive analytics, network optimization, multi-layer planning, and more. It aims to guide the evolution of IETF protocols to support AINetOps-driven network management. |
| | BGP SR Policy Extensions for Performance-Aware Path Selection |
| |
|
To enable the headend node to do performance-aware path selection, this document proposes an extension to the BGP SR Policy protocol by defining a new optional Metric Sub-TLV within the BGP Tunnel Encapsulation Attribute. The introduced Metric Sub-TLV encodes performance parameters (such as latency, bandwidth, reliability, etc.) for SR Policy paths. This specification also updates the BGP route selection procedures in RFC4271, modifying the Breaking Ties (Phase 2) logic to prioritize the metrics for SR Policy paths. Key contributions include: * Introduce Metric Sub-TLV in BGP SR Policy * Update the tie-breaking procedure for BGP route selection |
| | PCEP Extension for Tunneled Flow Specification |
| |
|
Traffic flows may be categorized and described using "Flow Specifications". RFC8955 defines the Flow Specification and describes how Flow Specification components are used to describe traffic flows. RFC8955 also defines how Flow Specifications may be distributed in BGP to allow specific traffic flows to be associated with routes. RFC 9168 specifies a set of extensions to PCEP to support the dissemination of Flow Specifications. This allows a PCE to indicate what traffic should be placed on each path that it is aware of. The extensions defined in this document extend the support for tunneled traffic filtering rules. |
| | A Capability-Oriented Intent Routing Protocol |
| |
|
This document specifies the Capability-Oriented Intent Routing Protocol (CIRP), a capability-oriented protocol layer for routing intent between cryptographically identified endpoints across heterogeneous trust domains. The protocol defines capability identifiers with mandatory versioning, scoped discovery across five visibility levels, ticket-based session authorization, negotiated cryptographic suites including hybrid post-quantum key establishment, encrypted peer-to-peer session establishment, and mutually attested invocation receipts with hash-chained integrity. Payload semantics are opaque to the CIRP layer. CIRP messages are carried by transport bindings. The initial binding is datagram-oriented and maps CIRP control-plane and session messages onto UDP. Other bindings, including QUIC/TLS-based bindings, may be specified separately. This revision clarifies the protocol architecture in response to early review. It distinguishes CIRP core semantics from transport bindings, separates endpoint identity from reachability locators, separates discovery from authorization, and introduces no wire-format changes. |
| | Hybrid Post-Quantum and Traditional Authentication for IKEv2 |
| |
|
A Cryptographically Relevant Quantum Computer (CRQC) can break traditional public-key algorithms (e.g., RSA, ECDSA), which are typically used for authentication in IKEv2. Combining the post- quantum ML-DSA signature algorithm with a traditional signature algorithm provides protection against potential weaknesses or implementation flaws in ML-DSA. This draft defines a hybrid PKI authentication method for IKEv2 using composite certificates that ensures authentication remains secure as long as at least one of the component signature algorithms remains unbroken. |
| | Temporal Integrity Metadata (TIM) for Infrastructure Telemetry |
| |
|
Distributed computing systems generate timestamped events from components whose clocks operate under fundamentally different synchronization conditions. Existing logging and observability standards -- including legacy BSD syslog (RFC 3164), RFC 5424, SNMP, NETCONF, and OpenTelemetry -- define message formats and telemetry schemas but provide no standard mechanism for an event source to declare the provenance, confidence, or synchronization state of its timestamps. Every platform that must correlate events across components independently invents a proprietary temporal reconciliation layer. These systems fail silently, cannot be validated against a published standard, and are not interoperable. This document defines Temporal Integrity Metadata (TIM): a transport- agnostic structure that any event-emitting system may attach to its telemetry to declare how its timestamp was generated, the synchronization state of its clock, a bounded uncertainty interval, the temporal reference domain, and a monotonic sequence token for ordering events when wall-clock time is unavailable. TIM is backward-compatible with existing protocols, implementable on constrained embedded hardware, and applicable from internet-scale distributed services to air-gapped and orbital deployments. |
| | An IANA Registry for Model Context Protocol Tool Surface Names |
| |
|
This document requests the establishment of an IANA registry for Model Context Protocol [MCP-SPEC] tool surface names. A tool surface name is the wire-level identifier by which a client invokes a typed capability on an MCP server. Existing Morrison- family Internet- Drafts ([ORGALTER]) request IANA registration of specific surface names against a registry that does not yet exist. This document establishes the registry mechanism so that subsequent specifications can register names without restating the registry's structure or registration procedure. The registry uses Specification Required registration with a Designated Expert pool [RFC8126]. Initial contents are the four surface names registered by [ORGALTER]. Vendor-prefix conventions are recommended but not mandated. |
| | AXFR message type for DNS NOTIFY |
| |
|
This document defines a new AXFR message type for DNS NOTIFY messages, together with an accompanying subtype for the ZONEVERSION EDNS(0) option. The message instructs a secondary server to perform an AXFR zone transfer of a zone. |
| | PSI-06: Inception-Lock Protocol for Human-Originated Data Signals |
| |
|
PSI-06 specifies an inception-lock protocol that cryptographically anchors a raw human-originated data signal (keystroke, biometric, survey response, application screen capture, trip acceptance timestamp) to a signing key at the point of capture. The protocol prevents tampering with source data between capture and submission, enabling verifiable proof of what a user was shown and when they saw it. Receipts are protected by a hybrid dual-signature scheme combining Ed25519 (classical) and ML-DSA-65 (post-quantum), making the evidence chain resistant to both classical and quantum adversaries. This is critical for accountability proceedings involving algorithmic platforms, where the information displayed to the user may differ from the information recorded by the platform. |
| | An Authorization Evidence Challenge for High-Risk Agent Actions |
| |
|
When a relying party refuses a consequential agent action because authorization evidence is missing, stale, or unverifiable, the agent needs a machine-readable description of what remains necessary. This document defines a transport-neutral Authorization Evidence Challenge data model bound to the relying party's exact action. The challenge identifies outstanding evidence requirements, freshness and status constraints, acceptable presentation profiles, and retry state. It authorizes nothing, transfers no admission ownership, and provides no promise that a later request will execute. The document also defines an HTTP challenge-response carrier using 403 Forbidden and RFC 9457 Problem Details, and describes an informative gateway-handoff illustration for DMSC-style federation. The gateway illustration communicates evidence requirements; it does not solve conserved admission or double-admission across independently operated gateways. A challenge can synchronize corrected retries and amplify load. The core therefore defines optional retry timing with per-challenge jitter, and the HTTP carrier maps its lower bound to Retry-After. Retry timing controls presentation attempts only; it does not authorize the action or make an uncertain action safe to repeat. Single-use processing also places state on the refusal path. The core therefore requires bounded outstanding and replay state, fail- closed behavior when state cannot be claimed, and retention of live replay records until they are no longer security-relevant. Nonce claim and refusal-path capacity reservation are one atomic owner-side transition before native evidence verification, and a binding capacity refusal reveals no remaining evidence requirements. In a sharded replay domain, only the authoritative owner can classify a nonce as already claimed; inability to reach that owner is unavailability, not replay. |
| | A Uniform Resource Name (URN) Namespace for Digital Nation Pakistan (DNP) |
| |
|
This document describes a Uniform Resource Name (URN) namespace for persistent, location-independent identification of normative and authoritative publications issued under the Digital Nation Pakistan (DNP) programme by the Pakistan Digital Authority (PDA), a federal statutory body of the Government of Pakistan established under the Digital Nation Pakistan Act, 2025. The namespace covers policies, frameworks, technical standards, reference architectures, specifications, schemas, application programming interface contracts, registries and datasets that PDA issues or is statutorily designated to maintain. This document requests registration of the formal Namespace Identifier "dnp" in accordance with RFC 8141. |
| | Knowledge Graphs for Enhanced Cross-Operator Incident Management and Network Design |
| |
|
Operational efficiency in incident management in networking requires correlating and interpreting large volumes of heterogeneous technical information. Knowledge Graphs (KG) can provide a unified view of complex systems through shared vocabularies. YANG data models enable describing network configurations and automating their deployment. However, both approaches face challenges in vocabulary alignment and adoption, hindering knowledge capitalization and sharing on network designs and best practices. To address this, the concept of a IT Service Management Knowledge Graph (ITSM-KG) is introduced to leverage existing network infrastructure descriptions in YANG format and enable abstract reasoning on network behaviors. The key principle to achieve the construction of such ITSM-KG is to transform YANG representations of network infrastructures into an equivalent knowledge graph representation, and then embed it into a more extensive data model for Anomaly Detection (AD) and Risk Management applications. In addition to use case analysis and design pattern analysis, an experiment is proposed to assess the potential of the ITSM-KG in improving network quality and designs. |
| | Operational Guidance for Authoritative DNS Operator Changes with Service Endpoint Migration for Registered Domain Names |
| |
|
A registered domain name can change its authoritative DNS operator while the registrant also migrates service endpoints, such as web, API, CDN, mail, or cloud-hosted services. In this situation, service RRsets such as A, AAAA, CNAME, MX, SRV, SVCB, and HTTPS RRsets can change at the same time as the parent-side delegation changes. The parent-side delegation change is not observed by all recursive resolvers at the same instant. During the transition, some resolvers can continue to query the losing DNS operator while others query the gaining DNS operator. If the losing operator continues to serve stale service RRsets, or if it stops serving the zone too early, users can receive different answers depending on resolver cache state and can experience intermittent service failure. This document provides operational guidance for authoritative DNS operator changes with service endpoint migration for registered domain names. It recommends a registrant-authorized change plan, a consistency profile for in-scope service RRsets, synchronized provisioning or a common source of truth, a hold period during which the losing DNS operator continues to serve target or otherwise equivalent data, and verification points that directly compare the losing and gaining authoritative servers and classify observed states as planned, service-risk, or unexpected-delegation conditions. |
| | CMCD transmission over MSF Event Timeline |
| |
|
Defines the transmission of CMCD data over MSF Event Timeline tracks. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://wilaw.github.io/CMCD-over-MSF-event-timeline/draft-wilaw-moq- cmcd-event-timeline-latest.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- wilaw-moq-cmcd-event-timeline/. Source for this draft and an issue tracker can be found at https://github.com/wilaw/CMCD-over-MSF-event-timeline. |
| | A Review of RADIUS Security and Privacy |
| |
|
This document provides a comprehensive review of security issues related to the RADIUS Protocol. This review motivates the changes to RADIUS security which are made in [I-D.ietf-radext-deprecating-radius]. |
| | Update Management Extensions for Software Updates for Internet of Things (SUIT) Manifests |
| |
|
This document specifies extensions to the SUIT manifest format. These extensions allow a Manifest Author, update distributor, or device operator to more precisely control the distribution and installation of updates to devices. These extensions also provide a mechanism to inform a management system of Software Identifier and Software Bill Of Materials information about an updated device. |
| |
|
| |
| | Automatic Certificate Management Environment (ACME) Device Attestation Extension |
| |
| | draft-ietf-acme-device-attest-10.txt |
| | Date: |
09/08/2026 |
| | Authors: |
Brandon Weeks, Ganesh Mallaya, Sven Rajala, Corey Bonnell, Ryan Hurst |
| | Working Group: |
Automated Certificate Management Environment (acme) |
|
This document specifies new identifiers and a challenge for the Automatic Certificate Management Environment (ACME) protocol which allows validating the identity of a device using attestation. This document updates RFC 8555 to enable a privacy-preserving mode for the identifiers defined in this document. |
| | Operational Considerations for Voucher infrastructure for BRSKI MASA |
| |
|
This document describes a number of operational modes that a BRSKI Manufacturer Authorized Signing Authority (MASA) may take on. Each mode is defined, and then each mode is given a relevance within an over applicability of what kind of organization the MASA is deployed into. This document does not change any protocol mechanisms. |
| | More Accurately Naming IPv6 RA Router Lifetime |
| |
|
IPv6 Router Advertisements (RAs) have a "Router Lifetime" field, which specifies how long the advertising router will act as a default router for the receiving hosts, unless refreshed with another advertisement. The field name "Router Lifetime" is quite general, and could easily be misunderstood to mean the bounded lifetime of all of the information contained in the RA. This memo more accurately renames this field "Default Router Lifetime". |
| | Multicast use case in LLM MoE |
| |
|
Large Language Models (LLMs) have been widely used in recent years. The Mixture of Experts (MoE) architecture is one of the features of LLMs that enables efficient inference and cost-effective training. With the MoE architecture, there are potential multicast use cases such as tokens dispatching. This draft attempts to analyze these use cases. |
| | BGP extensions for SRv6/MPLS Transport Interworking |
| |
|
This document defines the BGP extensions required to provide transport interworking between SRv6 and MPLS in SRv6 deployment. |
| | SOUTH: Stochastic Authorization for Agent and Service Requests |
| |
|
SOUTH defines an authorization protocol for evaluating requests issued by users, services, or autonomous agents. SOUTH allows a server to return a deterministic decision or an allow decision that is issued with a probability determined by local policy. This enables servers to incorporate uncertainty, contextual information, and load conditions into authorization decisions. SOUTH is transport independent and can be composed with existing authentication mechanisms such as OAuth, OpenID Connect, mutual TLS, or DPoP. This document describes the request and response objects, decision semantics, and an HTTP binding for interoperable deployment. |
| | The Web of Agents (WoA) |
| |
|
This document defines the Web of Agents (WoA), a minimal JSON based description format and invocation convention that allows HTTP hosts to advertise AI agents and for clients to invoke those agents in a uniform way. A WoA document is typically served from a well known location on an HTTP origin and uses JSON Schema to describe agent inputs and outputs. WoA does not define a discovery protocol itself but is designed to be used as a host level primitive by higher level discovery systems. |
| | Agent Persistent State Profile |
| |
|
Autonomous agents increasingly maintain durable persistent state containing user preferences, embedding vectors, safety logs, intermediate reasoning steps, and audit traces. Today, agent frameworks treat storage as a generic file system, while storage administrators treat agents as stateless virtual machines. This "layer mismatch" leads to fragility, poor performance, and privacy risks. The Agent Persistent State (APS) Profile defines an experimental, vendor-neutral storage service class for durable agent state. APS emphasizes *compliance*: ensuring that memory associated with a specific user or agent identity can be retained, audited, and cryptographically erased. APS also addresses high-frequency small I/ O, vector index workloads, crash consistency, and Kubernetes/CSI [CSI] integration. APS introduces a Usage Class ("AgentPersistentState"), a versioned PersistentStateLineOfService schema, guidance for container orchestration systems, non-normative bindings for Swordfish [Swordfish] and Redfish [Redfish], and considerations for multi- tenancy. APS is intended as an Experimental RFC to gather implementation feedback prior to any standards-track work. |
| | Benchmarking Terminology for Large Language Model Serving |
| |
|
This document defines terminology for benchmarking the performance of Large Language Model (LLM) inference serving systems. It establishes a shared vocabulary for latency, throughput, resource utilization, and quality metrics applicable to inference engines, application gateways, and compound agentic systems. This document defines terminology only and does not prescribe benchmark methodologies or acceptance thresholds. |
| | Benchmarking Methodology for Large Language Model Serving |
| |
|
This document defines benchmarking methodologies for Large Language Model (LLM) inference serving systems. It provides test procedures, setup parameters, measurement specifications, and reporting formats for evaluating latency, throughput, scheduling, and resource management characteristics. This document is a companion to "Benchmarking Terminology for Large Language Model Serving" and SHOULD be consulted alongside that terminology document. |
| | Performance Benchmarking Profiles for Large Language Model Serving Systems |
| |
|
This document defines performance benchmarking profiles for Large Language Model (LLM) serving systems. Profiles bind the terminology defined in draft-gaikwad-llm-benchmarking-terminology and the procedures described in draft-gaikwad-llm-benchmarking-methodology to concrete architectural roles and workload patterns. Each profile clarifies the System Under Test (SUT) boundary, measurement points, and interpretation constraints required for reproducible and comparable benchmarking. This document specifies profiles only. It does not define new metrics, benchmark workloads, or acceptance thresholds. |
| | SRv6 for PPPoE Transport |
| |
|
This document proposes a method that employs SRv6 underlay tunnel to transport PPPoE session information across broadband networks. By leveraging the programmability of SRv6 SIDs, the approach not only delivers trusted authentication and secure subscriber access, but also enables operators to offer differentiated services and flexibly instantiate network functions for broadband users. |
| | PSI-05: Financial Disclosure Integrity |
| |
|
PSI-05 defines a cryptographic attestation framework for financial disclosures, enabling third parties to recompute and verify company filings against their published figures. It establishes a public ledger of sealed financial statements, a verification protocol using RFC 8785 canonicalization with Ed25519 (classical) and ML-DSA-65 (post-quantum) signatures, and an API for querying reconciliation results. The framework supports ASX, NYSE, NSE, LSE, and Euronext filings. |
| | Gravit Verifiable Epistemic Decision Standard |
| |
|
This document defines the normative requirements for the Gravit decision-making system. Gravit's core principle is to base all definitive decisions exclusively on verifiable epistemic grounds. This specification establishes mandatory rules for evidence admissibility, epistemic classification, traceability, failure handling, auditability, and security in adversarial environments, including a taxonomy of admissible evidence and failure outcomes, a required Decision Record format, and an explicit threat model with corresponding verification mechanisms. The goal is to ensure that all decisions are reproducible, auditable, and resistant to manipulation, thereby fostering trust and accountability in distributed and high-stakes settings. |
| | A Recursive Peer Model for Network Protocols |
| |
|
The seven-layer OSI model has served as a foundational framework for network protocol design and education for four decades. However, modern networking practices—including VPNs, NAT, tunneling protocols, and overlay networks—have revealed structural flaws in the OSI model that require ad hoc exceptions to explain. This document presents a Recursive Peer Model (RPM) as an alternative architectural framework. The model is based on a single observation: every intermediate protocol layer contains its own four-layer structure—Bearer Layer, Data Link Layer, Network Layer, and Transport Layer—and this structure recurs at every layer of the protocol stack. The Data Layer and Medium Layer serve as the two recursive boundaries, terminating at "pure data" and "physical medium" respectively. The Recursive Peer Model eliminates the need for "exception" clauses (such as the "tunnel exception" for VPNs), provides coherent explanations for protocols that OSI cannot categorize cleanly (such as ARP and ICMP), and offers a unified framework for describing both existing and future protocols. |
| |
|
| |
| | Use Cases for Energy Efficiency Management |
| |
| | draft-ietf-green-use-cases-02.txt |
| | Date: |
07/08/2026 |
| | Authors: |
Emile Stephan, Marisol Amador, Benoit Claise, Qin WU, Luis Contreras, Carlos Bernardos, Xinyu Chen |
| | Working Group: |
Getting Ready for Energy-Efficient Networking (green) |
|
This document groups use cases for Energy efficiency Management of network devices. Discussion Venues Source of this draft and an issue tracker can be found at https://github.com/emile22/draft-ietf-green-use-cases |
| | Best practices for SASL password hashing and storage |
| |
|
This document outlines best practices for handling user passwords and other secrets in client-server systems making use of SASL. |
| | Parallel NFS (pNFS) Flexible File Layout Version 2 |
| |
|
Parallel NFS (pNFS) allows a separation between the metadata (onto a metadata server) and data (onto a storage device) for a file. The Flexible File Version 2 Layout Type is defined in this document as an extension to pNFS that allows the use of storage devices that require only a limited degree of interaction with the metadata server and use already-existing protocols. Data protection is also added to provide integrity. Both Client-side mirroring and the erasure coding algorithms are used for data protection. |
| | Knowledge Graphs for Enhanced Cross-Operator Incident Management and Network Design |
| |
|
Operational efficiency in incident management in networking requires correlating and interpreting large volumes of heterogeneous technical information. Knowledge Graphs (KG) can provide a unified view of complex systems through shared vocabularies. YANG data models enable describing network configurations and automating their deployment. However, both approaches face challenges in vocabulary alignment and adoption, hindering knowledge capitalization and sharing on network designs and best practices. To address this, the concept of a IT Service Management Knowledge Graph (ITSM-KG) is introduced to leverage existing network infrastructure descriptions in YANG format and enable abstract reasoning on network behaviors. The key principle to achieve the construction of such ITSM-KG is to transform YANG representations of network infrastructures into an equivalent knowledge graph representation, and then embed it into a more extensive data model for Anomaly Detection (AD) and Risk Management applications. In addition to use case analysis and design pattern analysis, an experiment is proposed to assess the potential of the ITSM-KG in improving network quality and designs. |
| | Explicit Congestion Notification Using MPLS Network Actions |
| |
|
It has been broadly demonstrated that user experience improvements for time-critical applications have not increased at the same pace as network throughput (i.e., the increased bandwidth does not result in a corresponding increase in the user experience). Optimizing network latency rather than throughput can lead to a significantly improved user experience for time-critical applications. Low Latency, Low Loss, and Scalable Throughput (L4S) technology, introduced in RFC 9330, uses Explicit Congestion Notification (ECN) bits by marking packets suffering potential congestion in the network. L4S operates as a congestion-control mechanism, using markers within the data packets to detect and promptly respond to congestion conditions. This feedback loop enables devices (e.g., endpoints such as client devices and server devices) to adjust data flow in real-time, preventing bottlenecks and ensuring smoother transmission. RFC 5129 describes a mechanism for supporting ECN in the Multiprotocol Label Switching (MPLS) data plane. That mechanism is based on the codepoints that take part in the Traffic Class (TC) field and, thus, prevent the use of TC field for traffic differentiation. This document defines how ECN can be supported in the MPLS data plane using the MPLS Network Actions technology. |
| | Reilly EternaMark (REM) Protocol - Dual-Layer Digital Permanence Using DOI Archiving and Blockchain Timestamping |
| |
|
The Reilly EternaMark (REM) Protocol defines a dual-layer method for digital permanence through the integration of Digital Object Identifiers (DOIs) and blockchain timestamping. The protocol ensures digital artifacts are permanently identifiable, immutable, and verifiable for both present and future use. Revision -01 extended the -00 specification with a formal REM Record structure, a machine-readable artifact manifest format, a verification procedure, implementation guidance, and expanded security and interoperability considerations. This revision (-02) additionally documents the protocol's function as a prior art record system under 35 U.S.C. 102(a)(1): a Full REM Record establishes that a publicly deposited artifact was available to the public in its exact recorded form no later than a cryptographically verifiable date, enabling its use as defensive publication against later-filed patent claims. |
| | Cognitive Trust Stack (CTS): A Framework for Verifiable AI Behavioral Provenance |
| |
|
Every artificial intelligence system deployed today operates under behavioral constraints that are unverifiable by any external party. Alignment claims exist as documentation, policy statements, or terms of service -- all mutable, none cryptographically provable. When an AI system causes harm, there is no mechanism to prove what rules it was following. When an organization claims its AI is safe, there is no standard by which that claim can be independently verified. This is the AI behavioral provenance problem, and no existing framework solves it. The Cognitive Trust Stack (CTS) establishes that the alignment state of an AI system at any point in time MUST be a verifiable fact, not an assertion requiring trust. CTS defines a complete, implementable framework for declaring, anchoring, enforcing, and verifying AI behavioral constraints through a five-layer architecture combining: (1) a declarative alignment schema formatted to IETF Internet-Draft standards, (2) archival permanence via Digital Object Identifier (DOI) registration, (3) cryptographic temporal anchoring via Bitcoin blockchain timestamping using the Dual-Layer Digital Permanence (DLDP) methodology [REILLY-REM], (4) runtime retrieval injection for active constraint enforcement, and (5) independent third-party verification. CTS does not replace existing AI alignment techniques. It provides the missing accountability layer that sits above them -- making alignment a cryptographically provable fact rather than an unverifiable claim. The full CTS specification, reference implementation, schema, and provenance manifest are published at Zenodo DOI 10.5281/zenodo.19097169. The priority of this framework is cryptographically anchored in Bitcoin block 941168 (2026-03-18), with SHA-256 hash: e915b5162422281e1c0185c9e2eefaf7 4b7f539996b878cb1e69e10533f24ac2 The OpenTimestamps proof file (CTS_Whitepaper_v1.0.docx.ots), included in the Zenodo record, provides independent cryptographic verification of existence prior to block 941168. This revision (-01) additionally documents the function of CTS records as prior art records under 35 U.S.C. 102(a)(1), clarifies the scope of the canonical v1.0 cryptographic anchor (which covers the whitepaper artifact), introduces a normative one-hash-per-artifact anchoring rule, and corrects an erroneous reference to the REM Protocol draft name present in -00. |
| | Proxy-Driven Server for Flexible Files Version 2 |
| |
|
Parallel NFS (pNFS) with the Flexible Files Version 2 layout type supports client-side erasure coding and per-chunk repair between clients and data servers. This document extends that architecture with a proxy server role: a registered peer of the metadata server that polls the metadata server for work assignments and carries them out -- moving a file from one layout to another, reconstructing a whole file from surviving shards, or translating between encodings for clients that cannot participate in the file's native encoding (including NFSv3 clients). All proxy-server-to-metadata-server coordination is fore-channel: the metadata server returns work assignments inline in the response to a proxy-server-initiated PROXY_PROGRESS poll, and the proxy server reports completion via a fore-channel PROXY_DONE. No callback operations are required for the proxy server protocol. |
| | A typology of Space Research Infrastructures |
| |
|
Space networking research increasingly relies on a heterogeneous ecosystem of software, datasets, experimental platforms, reference implementations, and operational research assets. These resources have historically been developed independently by different research groups, agencies, and projects, making discovery, comparison, interoperability, and reuse difficult. Existing registries typically catalogue tools individually but provide limited guidance on their functional role within the research lifecycle. This document proposes a typology for research infrastructures relevant to the Space Research Group (SPACERG). The proposed taxonomy groups resources by the research function they serve, independently of their implementation technology or project origin. The typology provides a common vocabulary for describing software and non-software research assets, supports the organization of community registries, and facilitates interoperability, reproducibility, and long-term maintenance of research infrastructures. The classification is intended to evolve as new classes of research resources emerge. The typology is implemented by a machine-readable registry of research resources maintained by the research group. |
| | A Runtime Verification Receipt Format for Agent Auditing |
| |
|
The Correctover Conformance Shape (CCS) defines a tamper-evident, cryptographically bound receipt format that provides runtime verification for agent tool invocations. Each CCS receipt captures a seven-dimensional verification outcome -- Structure, Schema, Latency, Cost, Identity, Integrity, and Security -- as a single artifact suitable for consumption by audit, compliance, and observability systems. CCS is designed as a pluggable runtime verification infrastructure layer that complements -- but does not replace -- existing and emerging agent protocol work at the IETF. Specifically: (1) the AUDIT effort (draft-kuehlewind-audit-architecture) defines an auditing architecture with Action Record and Authorization Transition Record types; a CCS receipt provides the verifiable, tamper-evident evidence payload that can populate these record types with cryptographically bound proof of runtime governance decisions. (2) The agentproto WG-forming effort (IETF 126 BoF) addresses agent-to- agent and agent-to-tool communication protocols; CCS provides per- invocation, sub-millisecond runtime verification that operates beneath the session/transport layer, complementing protocol-level context exchange with evidence-level integrity guarantees. Version 1.1 of the CCS receipt comprises 29 fields with full Ed25519 signature coverage, including three causal chain fields (rule_version, tool_call_id, args_digest) that elevate the Integrity dimension from behavioral traceability to verifiable decision causality. The reference implementation (ccs-verifier v1.1.0, PyPI) passes 154 conformance tests across all verification dimensions. This document specifies the CCS Receipt Schema, the Canonical Configuration model, the nine binding mechanisms, key management, transport requirements, verifier source classification, conformance levels, and negative test cases. CCS is protocol-agnostic: it is not bound to Model Context Protocol (MCP), Agent2Agent (A2A), or any other specific agent protocol, and can be integrated into any runtime that governs tool invocations. |
| | Delta-Write Extension for the Flexible File Version 2 Layout Type |
| |
|
The Flexible File Version 2 pNFS layout type defines a chunk-oriented data-server protocol in which every write is a full-chunk payload. For workloads that make small edits to files protected by an XOR- based erasure encoding, this forces client-side stripe fetch, re- encode, and transmit on every edit, with wire amplification of three to four orders of magnitude per byte edited. This document defines an optional extension, CHUNK_XOR_DELTA, that lets a client transmit a per-projection XOR delta directly to each data server holding a projection of the affected stripe; the data server applies the delta locally. The extension is restricted to XOR-linear systematic encodings and XOR-affine checksums, using the existing chunk state machine with no new commit protocol. |
| | Web4 Terminology and Definitions |
| |
|
This document defines a common vocabulary for describing Web4 systems: federated, sovereign-entity-capable network architectures that extend prior generations of the Web with machine-native comprehension and conformance evaluation. It establishes baseline terminology intended for reference by subsequent Web4 specifications, including but not limited to [JACOBS-MEC], and is written to be independently useful to any implementer or evaluator working with Web4-class systems, regardless of underlying implementation. |
| | Web4 Federation Architecture Model |
| |
|
This document describes a generic architectural model for Web4 federations, as defined in [JACOBS-TERM], covering node admission, tiering, gateway-mediated inter-node transport, and operational health verification. It generalizes patterns observed in a live, operating multi-node federation, offered as a Reference Implementation under the terminology of [JACOBS-TERM], without specifying vendor-internal computational, cryptographic, or coordinate mechanisms. |
| | An Interoperable Attestation Format for Policy-as-Code Compliance Evidence |
| |
|
Organizations increasingly enforce regulatory and security requirements using policy-as-code (PaC) engines integrated into continuous integration and delivery (CI/CD) pipelines. The evidence these engines produce, that is, the record of which policies were evaluated, against what inputs, and with what outcome, is typically emitted in vendor-specific, non-portable formats. This impairs auditability, cross-tool aggregation, and independent verification. This document analyzes the problem and describes an interoperable, machine-readable attestation format for PaC compliance evidence. It is informational and does not define an IETF standard, nor does it establish a new IANA registry. |
| | NTS4PTP - Network Time Security for the Precision Time Protocol |
| |
|
This document specifies an automatic key management service for the integrated security mechanism (prong A) of IEEE Std 1588™-2019 (PTPv2.1) described there in Annex P. This key management follows the immediate security processing approach of prong A and extends the NTS Key Establishment protocol defined in IETF RFC 8915 for securing NTPv4. The resulting NTS for PTP (NTS4PTP) protocol provides a security solution for all PTP modes and operates completely independent of NTPv4. |
| |
|
| |
| | DULT Threat Model |
| |
|
Lightweight location-tracking tags are in wide use to allow users to locate items. These tags function as a component of a crowdsourced network in which devices belonging to other network users (e.g., phones) report which tags they see and their location, thus allowing the owner(s) of the tag to determine where their tag was most recently seen. While there are many legitimate uses of these tags, they are also susceptible to misuse for the purpose of stalking and abuse. A protocol that allows others to detect unwanted tracking must incorporate an understanding of the unwanted tracking landscape today. This document provides a threat analysis for this purpose, including a taxonomy of unwanted tracking and potential attacks against Detection of Unwanted Location Tracking (DULT) protocols. The document defines what is in and out of scope for the unwanted tracking protocols, and provides design requirements, constraints, and considerations for implementation of protocols to detect unwanted tracking. |
| | MPLS Network Action (MNA) Post-Stack Header Specification |
| |
| | draft-ietf-mpls-mna-ps-hdr-19.txt |
| | Date: |
06/08/2026 |
| | Authors: |
Jaganbabu Rajamanickam, Rakesh Gandhi, Royi Zigler, Jie Dong, Jisu Bhattacharya |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
This document specifies the MPLS Network Action (MNA) Post-Stack Header encoding and procedures for carrying Network Action encodings and Ancillary Data after the MPLS label stack, based on the MNA Sub- Stack including In-Stack Network Actions and Data specified in RFC 9994. MPLS Network Actions can be used to influence packet forwarding decisions, carry additional Operations, Administration, and Maintenance information in the MPLS packet, or perform user- defined operations. This document follows the framework specified in RFC 9789. This document updates RFC 9994: the "Network Action Opcodes" registry fields, the Post-Stack MNA applicability of the opcodes, MNA scope, and Unknown action handling. This document updates RFC 9789: the definition of Readable Label Depth (RLD). |
| | Ordering of RRSets in DNS Message Sections |
| |
|
The existing Domain Name System (DNS) specifications lack some clarity in their description of the process by which individual sections of a DNS message are constructed. This document updates RFC 1034 and RFC 1035 to provide a clearer specification, consistent with deployed implementations. |
| | Congestion-Aware Multipath Tunnel Selection for Transport Services |
| |
|
This document addresses the transport-layer challenges of path selection in environments with multiple available tunneling options and congestion control mechanisms. It identifies congestion control conflicts that arise from nested tunneling protocols and proposes a congestion-aware multipath tunnel selection algorithm that conforms to the guidelines established in [RFC9599] for adding congestion notification to protocols that encapsulate IP. The proposed approach considers Explicit Congestion Notification (ECN) propagation, transport protocol characteristics, and network conditions to optimize path selection while avoiding multilevel congestion control issues. This work aligns with current Transport and Services Working Group efforts on Non-Queue-Building (NQB) behaviors, careful congestion control resume, and multipath transport protocols. |
| | AAuth Protocol |
| |
|
This document defines the AAuth authorization protocol for agent-to- resource authorization and identity claim retrieval. The protocol supports four resource access modes — identity-based, resource- managed (two-party), PS-asserted (three-party), and federated (four- party) — with agent governance as an orthogonal layer. It builds on the HTTP Signature Keys specification ([I-D.hardt-httpbis-signature-key]) for HTTP Message Signatures and key discovery. |
| | Authentication-Transparent Protocol Extensions in Middleware-Relayed Systems |
| |
|
Protocol-aware middleware (relays, bridges, gateways) re-serializes messages at their protocol frame boundary, silently discarding any bytes appended outside that boundary. Authentication material placed after the frame boundary by a sender is therefore stripped at every relay hop before reaching the receiver, with no error indication. This document identifies this behavior as a protocol design vulnerability class -- "relay-transparent authentication stripping" -- demonstrates it with running code in three independent protocol stacks (MAVLink v2, ROS2/DDS CDR, and CAN/ISO-TP with a SecOC-unaware gateway), and specifies the architectural principle that authentication material must be carried as a first-class, independently addressable protocol unit to survive relay transit. Post-quantum signature sizes push authentication out of fixed fields and so create the precondition systematically; this revision reports three measured cases where they do not, because a transport that refuses to carry the oversized unit produces a loss of availability instead of a silent authentication bypass. |
| | Anchors: Post-Quantum Command Provenance for Autonomous Machine Links |
| |
|
Autonomous machines such as uncrewed aircraft, ground robots, and spacecraft execute commands issued by human operators and, increasingly, by AI agents. When an incident occurs, no independent evidence exists of which commands the machine received: conventional logs are mutable by the operating party, symmetric message authentication codes cannot demonstrate origin to a third party, and records signed with elliptic-curve cryptography lose their evidentiary value once cryptographically relevant quantum computers exist. This document defines the Anchor: a post-quantum digital signature over a compact commitment to a window of authenticated machine traffic. An anchor chain constitutes a tamper-evident, non- repudiable record of what a machine was commanded to do and what it reported back, verifiable by any third party without trusting the operator, without network access at recording time, and with security that survives the quantum transition. The construction is protocol- agnostic and is designed for bandwidth-constrained links where per- message post-quantum signatures are impractical. |
| | OpenA2A Agent Identity Protocol (AIP) |
| |
|
This document defines the OpenA2A Agent Identity Protocol (OpenA2A AIP), an open standard for creating, managing, and verifying cryptographic identities for AI agents. As AI agents proliferate across browsers, cloud platforms, and enterprise environments, systems need a standardized answer to the question of which agent is present, what it is permitted to do, and whether it should be trusted. OpenA2A AIP is distinguished by five elements that it places at the center of the design: a multi-factor behavioral trust score that is computed from independently verifiable signals; a portable signed credential, the Agent Trust eXtension, carrying a hybrid Ed25519 and ML-DSA-65 signature for post-quantum readiness; an append-only, RFC 9162-style Merkle transparency log for identity and credential issuance; agent identifiers expressed as W3C Decentralized Identifiers under the did:opena2a method; and a structured capability vocabulary with reserved namespaces. On top of these, the protocol specifies challenge-response verification, behavioral governance policies, a lifecycle model, and an append-only audit log. The qualifier "OpenA2A AIP" is used throughout this document because the abbreviation "AIP" is shared by other Internet-Drafts. OpenA2A AIP is framed as complementary to agent communication protocols such as A2A and the Model Context Protocol, and to identity and credential standards such as OpenID Connect, WebAuthn, and the W3C Verifiable Credentials Data Model. |
| | The Canonical Action Identifier (CAID) |
| |
|
Authorization, delegation, execution, and audit artifacts often identify an action using format-local content and digests. Those digests are not directly comparable when the formats select or encode material action fields differently. This document defines the Canonical Action IDentifier (CAID): a typed action object, a canonicalization and digest suite, a compact identifier string, and immutable action-type definitions with required material fields. 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. It does not establish identity, authority, authorization, execution, safety, or legal reliance. |
| | Model-to-Matter: Authorization and Outcome Evidence for Model-Directed Physical Execution |
| |
|
Advanced models can propose operations that produce physical effects. Model-to-Matter defines an executor-owned profile that composes model, safety, institutional, domain, screening, human, and physical- state attestation evidence over one canonical action before single- use execution. This revision also profiles post-execution Outcome Binding. An executor effect statement remains one source claim; required independent observers sign separately bound observations. Missing outcome evidence is indeterminate, not success or failure. The profile standardizes evidence custody and reconciliation; it does not perform screening, determine scientific safety, certify a facility, or establish physical truth. |
| | A Well-Known URI and JSON Format for Publishing Cryptographic Posture (the Crypto-Agility Manifest) |
| |
|
This document defines a discoverable, machine-readable JSON document, the crypto-agility manifest, that a website or source repository publishes at the well-known URI "/.well-known/crypto-agility.json" to declare its cryptographic posture: a readiness summary, a compact Cryptography Bill of Materials (CBOM) summary, an optional link to a posture attestation, the migration policy it measures itself against, and an optional self-declared conformance statement with justified exceptions. The manifest lets an automated consumer, such as an AI coding agent, a continuous-integration bot, or an auditor's tool, discover a project's crypto posture the way it already discovers a security contact from "security.txt". The manifest is a public, self-reported claim; it is not a proof. It is intended to complement, not replace, a full CBOM inventory, serving as the CBOM's public-facing discovery counterpart. This document is a proposal. It is not an IETF product and is not a standard of any kind. |
| | Dealing with LLMs in IETF Discussions |
| |
| | draft-fengfar-led-01.txt |
| | Date: |
06/08/2026 |
| | Authors: |
Stephen Farrell, Chong Feng |
| | Working Group: |
Individual Submissions (none) |
|
The rapid adoption of AI language tools has prompted concern across professional and technical communities, including the IETF, about authenticity, accountability, and the integrity of human contribution. This document approaches the question from two directions: a critical reader's concerns about what AI use means for IETF discussion, and a practitioner's account of how AI is currently being used in IETF discussions. We aim to explore some of the issues arising, and perhaps make some specific (but tentative) recommendations, but the main recommendation is that the IETF should develop guidelines for use of AI tooling when engaging in IETF discussions. |
| | Continuing to Reduce Support for ANY Queries in the DNS |
| |
|
The DNS specification from its earliest day supported a special query type (QTYPE) ANY. The handling of queries with QTYPE=ANY is observed to vary between implementations. Queries with QTYPE=ANY are known to facilitate amplification that can be abused and used by malicious actors to attack third parties, and minimally-sized responses are often constructed in order to mitigate those security risks. While queries with QTYPE=ANY can be used for troubleshooting in some cases, the substantial inconsistency in how such queries are handled makes them at best an unreliable signal. This document continues a careful and gradual process of dropping support for QTYPE=ANY from the DNS. |
| | JSON Structure: Semantic and Reference-System Annotations |
| |
|
Data types describe representation, but they do not explain the semantic, temporal, spatial, and operational characteristics needed to interpret and compare data. This document defines optional JSON Structure annotations that bind schema nodes to terms in external vocabularies; annotations for observation results, observed properties, features of interest, procedures, time semantics, quality, derivation, and cadence; annotations for spatial referencing by coordinates, by vector and tensor reference frames, by transformations between frames, and along linear elements; and annotations for color spaces, audio channel layouts, spectral bands, code lists, and measurement conditioning. The annotations make an incompatibility between two data sets detectable by machine; they do not resolve one. They are optional, and their absence does not make a schema invalid. |
| | Supporting Quantum-Safe Algorithms in DNSSEC with Local Resolver Policy |
| |
|
Security-aware resolvers validate signatures, where available, in order to protect their clients from inauthentic data. DNSSEC treats all algorithms as equal when it comes to validation, such that a single valid signature is considered sufficient proof of authenticity, and that data is only to be judged to be inauthentic if all available signatures are found to be invalid. However, a resolver might have a different local policy, e.g. in its handling of quantum-safe signatures. This document discusses such local policy and describes a means to indicate to a client that specific local policy has been applied to response validation. |
| | AIPREF Vocabulary Parameters |
| |
|
This document defines how parameters can be added to AI Preferences. |
| | A Registry of Announced,Filed and Deployed Satellite Constellations |
| |
|
Aggregate figures for the number of satellites planned for low Earth orbit are widely quoted and rarely traceable. They mix quantities that are not comparable: satellites already in orbit, satellites a national regulator has authorised, satellites applied for and not yet granted, and satellites that exist only in an announcement. For a single system these can differ by orders of magnitude. Which one a headline figure refers to decides whether it describes infrastructure or intent. This document describes a community-maintained registry that keeps the four apart and requires every number in it to carry a citation and an evidence grade. It sets out the data model, the taxonomy of regulatory commitment, the rules that separate primary regulatory sources from secondary reporting, and the criteria for inclusion. |
| | FAST: Framework for Autonomous Severity and Triage |
| |
|
This document specifies the Framework for Autonomous Severity and Triage (FAST): an empirical standard for how autonomous offensive security agents classify vulnerabilities, decide whether to submit reports, and write those reports. FAST is derived from a corpus of real bug bounty reports and their program-rendered triage outcomes rather than from theoretical scoring frameworks. It is designed to be applied by both offensive agents that hunt for vulnerabilities and by defensive agents or human triagers that render verdicts, so both sides of the reporting relationship operate under the same rulebook. This document is submitted as an Independent Submission and invites comment from researchers, triagers, bug bounty platforms, and security teams. |
| | attest: Portable,Offline-Verifiable Digital Purchase Receipts |
| |
|
This document specifies attest, a signed digital purchase-receipt envelope that a buyer holds and that any party can verify offline, without contacting the issuer or any third-party service. It defines the receipt envelope and payload format, a restricted JSON canonicalization profile ("attest-JCS", built on RFC 8785), a pinned Ed25519 signature ruleset, an optional hybrid Ed25519+ML-DSA-65 post- quantum-resistant signature profile, issuer key and artifact manifests with rotation and compromise handling, a layered verification algorithm, and revocation-record semantics. This document is a snapshot profile: it distills, and never supersedes, the living attest specification maintained in the attest source repository. It normatively specifies exactly the core receipt format and the hybrid signature profile; the living specification's transparency-log, anchoring, and issuer-mediated transfer material is summarized only as non-normative pointers in Section 12 of this document. |
| | Proactive Self-Healing Mesh Protocol (PSHMP) |
| |
|
This document describes the Proactive Self-Healing Mesh Protocol (PSHMP), a decentralized overlay transport architecture designed to improve resilience and availability in distributed IP networks. PSHMP operates as an L4-oriented overlay above existing IP infrastructure. It continuously evaluates path quality and proactively reconstructs routes before degradation becomes service- impacting. The architecture combines decentralized topology discovery, adaptive path selection, batch acknowledgements, and transport abstraction to provide reliable communication under unstable network conditions without requiring modifications to underlying IP routing. This document presents the protocol architecture, design principles, and an overview of an experimental implementation. It does not specify an Internet Standard. |
| | Partial Content Uploads in HTTP |
| |
|
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines partial content uploads, which allows a client to upload content, such as a large file, via multiple requests. This document also outlines the metadata header fields for indicating state changes, request header fields for making preconditions on such state, and the rules for constructing the responses. |
| | The AIRP Provenance Seal and Serving Register |
| |
|
A response served by an inference provider carries no verifiable statement of what produced it. A recipient cannot determine which model generated a given output, nor whether the endpoint that served it was authorized by the party whose name is on it. Attribution today rests on the serving party's own account of events, offered after the fact and at its own discretion. This document specifies two mechanisms that together make that determination decidable by a recipient. The Provenance Seal is a detached signature by which a provider binds a model identifier, its own identity, and a timestamp to the exact bytes of a served response. The Serving Register is a signed document listing, for each provider, the endpoints authorized to serve its models, the public keys that validate its seals, and whether the provider declares that it seals every response. A DNS record under the provider's own domain binds that domain to its register entry and to its declared sealing policy, so that a suppressed seal is detectable rather than merely absent. The design follows electronic mail authentication: the seal is patterned on DKIM, the register on SPF, and the declared sealing policy on the published policy record of DMARC. |
| |
|
| |
| | BGP link bandwidth extended community use cases |
| |
| | draft-ietf-bess-ebgp-dmz-11.txt |
| | Date: |
05/08/2026 |
| | Authors: |
Stephane Litkowski, MOHANTY Satya, Arie Vayner, Akshay Gattani, Ajay Kini, Jeff Tantsura, Reshma Das |
| | Working Group: |
BGP Enabled ServiceS (bess) |
|
BGP link bandwidth extended community provides a way to signal a value along with a BGP path that can be used to perform weighted load-balancing in multipath scenarios. This document details various use cases of the BGP link bandwidth extended community. It also describes local mechanisms to dynamically adjust the BGP link bandwidth value or the multipath weights based on different considerations. |
| | A YANG Data Model for Transport Network Client Signals |
| |
|
A transport network is a server-layer network to provide connectivity services to its client. The topology and tunnel information in the transport layer has already been defined by generic Traffic- engineered models and technology-specific models (e.g., OTN, WSON). However, how the client signals are accessing to the network has not been described. These information is necessary to both client and provider. This draft describes how the client signals are carried over transport network and defines YANG data models which are required during configuration procedure. More specifically, several client signal (of transport network) models including ETH, STM-n, FC and so on, are defined in this draft. |
| | Segment Routing BGP Egress Peer Engineering over Layer 2 Bundle Members |
| |
|
This document specifies how to support Segment Routing BGP Egress Peer Engineering over Layer 2 bundle members. It updates RFC 9085 to allow the L2 Bundle Member Attributes TLV in the BGP-LS Attribute of the BGP-LS Link NLRI for a BGP peering link. For SR-MPLS, it updates RFC 9085 and RFC 9086 to allow the PeerAdj SID TLV as a sub-TLV of the L2 Bundle Member Attributes TLV. |
| | VESPER - Verifiable STI Presentation and Evidence for RTU |
| |
|
This document defines VESPER (Verifiable STI Presentation and Evidence for RTU), a profile for the use of delegate certificates in STIR. VESPER profiles the binding of telephone number authority to a domain identifier, the STIR certificate and PASSporT specifications, ACME-based authority token issuance, and certificate transparency into a delegate certificate that associates the right-to-use for a telephone number with the entity behind the number asserted in the PASSporT orig claim. This document describes the certificate usage, a PASSporT usage profile for SIP signaling, and a portable Right-to- Use Token for use outside of SIP. |
| | Data Plane Failure Detection Mechanisms for EVPN over SRv6 |
| |
|
For MPLS EVPN, RFC9489 specifies the mechanisms for detecting data plane failures using LSP Ping. This document proposes a similar mechanism to detect data plane failures for EVPN over SRv6. |
| | Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) |
| |
|
The TLS handshake protocol allows authentication of one or both peers using static, long-term credentials. In some cases, it is also desirable to ensure that the peer runtime environment is in a secure state. Such an assurance can be achieved using remote attestation which is a process by which an entity produces Evidence about itself that another party can use to appraise whether that entity is found in a secure state. This document describes a TLS extension that enables the negotiation and binding of the TLS authentication key to a remote attestation session. This enables an entity capable of producing attestation Evidence, such as a confidential workload running in a Trusted Execution Environment (TEE), or an IoT device that is trying to authenticate itself to a network access point, to present a more comprehensive set of security metrics to its peer. This extension has been designed to allow the peers to use any attestation technology, in any remote attestation topology, and to use them mutually. |
| | Domain Name System (DNS) Public Key Based Request and Transaction Authentication (SIGZERO,SIG(0)) |
| |
|
This document specifies the SIGZERO and SIG(0) Domain Name System (DNS) Resource Records (RRs) which provide public key based authentication of DNS requests and transactions. SIGZERO is the RECOMMENDED option. This document obsoletes RFC 2931. |
| | SDLP Lifecycle Specification |
| |
|
This document defines the SDLP Lifecycle Specification, the canonical state machine and transition semantics governing how SDLP objects evolve over time. The lifecycle model establishes deterministic rules for object creation, activation, transformation, and termination, ensuring that identity, lineage, and lifecycle metadata remain tamper-evident and verifiable across all implementations. Lifecycle-03 updates and aligns the transition grammar with Identity-02, Lineage-03, and Object-Format-08, providing a unified framework in which DigitalID is immutable, InstanceID grows deterministically, Lineage reflects complete ancestry, and Timestamp records the precise moment of each transition. The lifecycle rules defined in this document are normative and required for interoperable SDLP processing, validation, and provenance assurance. |
| | SDLP Object Format Specification |
| |
|
This document defines the canonical object format for the Secured Digital Lifecycle Protocol (SDLP). The SDLP object format specifies the structure, encoding, and canonicalization rules for DigitalID, lineage fields, lifecycle timestamps, Body content, and signature envelopes. These rules establish the immutable semantics required for SDLP verification, provenance tracking, lifecycle transitions, and interoperability with external systems such as CAID, AEC, AEB, SCITT, and EMILIA. Version -08 updates the canonical timestamp grammar, clarifies DigitalID and lineage field semantics, refines Body canonicalization rules, and incorporates corrections identified through SDLP Fixture Bundle v4 testing. This revision aligns the object format with the current SDLP Identity (-02), Lineage (-03), Lifecycle (-03), Security Architecture (-04), Architecture (-03), Overview (-01), and Physics Model (-00) drafts. |
| | Binding a Domain Identifier to Telephone Number Authority in STIR Certificates |
| |
|
This document defines a mechanism for binding a domain identifier to telephone number authority within a STIR certificate. A certificate produced under this mechanism carries, as a co-validated pair, the telephone numbers or service provider codes a subject is authorized for in a TNAuthList extension and a domain the subject controls in a SubjectAltName dNSName entry. The binding is established at issuance by requiring proof of domain control and validation of a TNAuthList authority token within a single certificate issuance, such that the resulting certificate attests that the same entity holds both. The mechanism applies to STIR certificates whose TNAuthList contains telephone number entries, service provider code entries, or both, allowing a domain to be bound to the right-to-use holder for a set of numbers or to the provider identified by a service provider code. This document defines the issuance conformance requirements and the relying party verification rule that together make the binding meaningful. It does not define telephone number or service provider code authorization or domain validation, both of which are specified elsewhere and referenced here. |
| | SDLP Interoperability Profile for Ownership,Verification,and Provenance Evidence |
| |
|
This document defines an interoperability profile for the Secured Digital Lifecycle Protocol (SDLP). The profile specifies how SDLP canonical objects, identity, lineage, lifecycle state, and digests are composed with external verification, typed authority evaluation, and provenance evidence semantics. It introduces a transition vector model that carries canonical SDLP envelopes together with CAID projections, AEC evidence results, local authorization decisions, and AEB execution outcomes, without altering SDLP’s core object semantics. The profile defines how SDLP objects participate in multi-stage verification pipelines and how mutated candidate inputs, negative cases, and authority constraints are represented. It also specifies composition rules for integrating SDLP with provenance and transparency systems such as CAID, AEC, AEB, SCITT, and EMILIA, while preserving the separation of concerns between SDLP canonical semantics and ecosystem-specific admission and trust policies. |
| | Blockchain-Backed Risk Pooling and Self-Regulation Protocol for Alternative Payment Providers (DeMI) |
| |
|
This document specifies a Best Current Practice (BCP) for risk management, automated self-regulation, and transaction settlement integrity among alternative payment service providers (APPs) operating in emerging markets without formal ISO/PCI-DSS coverage. It defines an architectural specification for a decentralized self- regulated organization (SRO) compensation pool deployed on the Ethereum Layer 1 blockchain. The protocol mitigates time-delayed fraud vectors, liquidity mismatches, and cross-border settlement frictions through cryptographic batching, zero-trust geo-distributed validator networks over private MPLS/satellite topologies, and automated algorithmic underwriting. |
| | BGP-LS Extension for SR Policy Packet Spray State |
| |
|
This document proposes an extension to BGP-LS that allows a headend node, when reporting SR Policy state information via BGP-LS, to carry a new state flag at the candidate path level. This flag indicates whether the candidate path is currently being used for packet spraying. The information can be consumed by external controllers for path optimization, operations management or other purposes. |
| | Zero Trust Secure Layer (ZTSL) Protocol Specification with Opcode Framework and Application Binding Layer |
| |
|
This document specifies the Zero Trust Secure Layer (ZTSL) protocol, a transport-layer security framework that enforces Zero Trust principles at the protocol level by embedding continuous identity verification, device trust validation, policy-driven communication, and cryptographic session management into every protocol message. ZTSL introduces the First Authentication Needed (FAN) mechanism, Zessions (Zero Trust Sessions), the Device Trust Flag (DTF), the Client Security Routing Profile (CSRP), the Triple Signature Model, the Trust Triangle, Adaptive Protocol Negotiation, and Heartbeat Fingerprint (HBF) synchronization. This document also specifies the ZTSL Opcode Framework, a structured, extensible opcode namespace that encodes every protocol operation as a precisely identified, versioned, and trust-contextualized instruction. Every FAN exchange, Zession state transition, socket operation, signing step, routing decision, heartbeat synchronization, threat event, and recovery action is assigned a unique opcode and transmitted as an opcode-bearing ZTSL frame. The document further specifies the Application Binding Layer (ABL), the transparent shim through which any application interacts with ZTSL via a familiar socket-like API, completely insulated from the underlying trust machinery. |
| | Human Continuity for HTTP |
| |
|
This document defines an HTTP extension for origins that need to attribute repeated participation to the same verified unique human within a declared continuity scope, without requiring a global human identifier or replacing existing authentication. Within a continuity scope, the same human yields one verifier-local handle across all of their accounts, devices, and agents and cannot present as two, distinguishing the signal from authentication, which identifies a credential a human may hold many of. An origin server can publish policy for client-presented unique-human artifacts, issue an explicit challenge, and receive a client-presented artifact on a subsequent request. The framework is independent of any realm operator, credential technology, proof system, or definition of humanness. Companion profiles define artifact syntax, issuance, verification, challenge binding, replay behavior, holder binding, privacy properties, realm metadata, and verifier output. A conforming profile produces a verifier-local continuity_handle scoped to a realm, attestation audience, and purpose. This version defines no initial profile. |
| | Project Atlas: A Cognitive Behavioral Provenance and Integrity (CBPI) Backbone Instrument for Autonomous Agents |
| |
|
This document specifies Project Atlas, a backbone instrument in which a pipeline of autonomous software agents continuously holds a constellation of live web endpoints under measurement, attestation, and remediation, with every agent behavior conditioned and recorded under the Cognitive Behavioral Provenance and Integrity (CBPI) framework [I-D.reilly-cbpi]. Atlas defines eight agent roles (Resolver, Reachability, Integrity, Provenance, Conditioning Authority, Drift, Functional Behavior Assessment, and Sentinel), a hash-linked Operant Provenance Chain of epochs, hash-linked Reinforcement Event Records, a per-agent Behavioral Drift Index, and a dual authority model in which the instrument operates either fully autonomously or under human oversight through an operator decision queue. A live reference instrument implementing this document is deployed and publicly reachable. |
| |
|
| |
| | Deep Audio Redundancy (DRED) Extension for the Opus Codec |
| |
|
This document proposes a mechanism for embedding very low bitrate deep audio redundancy (DRED) within the Opus codec (RFC6716) bitstream. |
| | Internationalization for the NFSv4 Protocols |
| |
|
This document describes the handling of internationalization for all NFSv4 protocols, including NFSv4.0, NFSv4.1, NFSv4.2 and extensions thereof, and future minor versions. It updates RFC7530 and RFC8881. |
| | BGP-LS extensions for BIER-TE |
| |
|
BIER-TE forwards and replicates packets based on a BitString in the packet header, but every BitPosition of the BitString of a BIER-TE packet indicates one or more adjacencies. BGP Link-State (BGP-LS) enables the collection of various topology informations from the network, and the topology informations are used by the PCE to calculate the path and then propagate them onto the BFRs(instead of having each node to calculate on its own) and that can be for both inter-as and intra-as situations. This document specifies extensions to the BGP Link-state address- family in order to advertise BIER-TE informations. |
| | Secure SMTP/TLS SRV Announcement |
| |
|
This specification defines a DNS (RFC 1035) SRV (RFC 2782) record that announces TLS (RFC 9325) secured SMTP (RFC 5321, RFC 3207), optionally including Implicit TLS. |
| | Privacy Pass Reverse Flow |
| |
|
This document specifies an instantiation of the Privacy Pass Architecture (RFC 9576) that allows for a "reverse" flow from the Origin to the Client. It describes a method for an Origin to issue a state update to the Client in response to a request in which a token is redeemed. |
| | SMTP VERP Service Extension |
| |
|
This specification makes official D. J. Bernstein's Variable Envelope Return Paths: VERP. |
| | An I2NSF Framework for Security Management Automation in Cloud-Based Security Systems |
| |
|
This document describes a Framework for Interface to Network Security Functions (I2NSF) in [RFC8329] for Security Management Automation (SMA) in Cloud-Based Security Systems. This security management automation facilitates Closed-Loop Security Control, Security Policy Translation, and Security Audit. To support these three features in SMA, this document specifies an extended architecture of the I2NSF framework with new system components and new interfaces. Thus, the SMA in this document can facilitate Intent-Based Security Management with Intent-Based Networking (IBN) in [RFC9315]. |
| | A YANG Data Model for Analytics Interface in Interface to Network Security Functions (I2NSF) |
| |
|
This document describes an information model and a YANG data model for the Analytics Interface between an Interface to Network Security Functions (I2NSF) Analyzer and a Security Controller in an I2NSF framework. I2NSF Analyzer collects the monitoring data from Network Security Functions (NSF), and analyzes them with Machine Learning (ML) algorithms. This Analytics Interface is used for I2NSF Analyzer to deliver analysis results (e.g., policy reconfiguration and feedback message) to Security Controller for Closed-Loop Security Control in the I2NSF Framework in [I-D.jeong-nmrg-security-management-automation]. The YANG data model described in this document is based on the YANG data models of the I2NSF NSF-Facing Interface [I-D.ietf-i2nsf-nsf-facing-interface-dm] and the I2NSF Monitoring Interface [I-D.ietf-i2nsf-nsf-monitoring-data-model]. |
| | AI Preferences for Real-Time Protocol Bindings |
| |
|
This document defines how Artificial Intelligence (AI) preference expressions are bound to signaling and media protocols used for real- time, session-based communications such as the Session Initiation Protocol (SIP) and associated Session Description Protocol (SDP) offers. It specifies a reusable binding model, concrete SIP header field conventions, and SDP attributes that allow endpoints, intermediary services, and AI assistants to advertise, negotiate, and enforce requirements about AI-driven processing of session metadata, media control events, and telemetry. The goal is to align real-time protocol behavior with the AI Preferences (AIPREF) vocabulary without disrupting existing call control semantics. |
| | Cross-Domain AuthZ Information sharing for Agents |
| |
| | draft-diaconu-agents-authz-info-sharing-01.txt |
| | Date: |
04/08/2026 |
| | Authors: |
Jean Diaconu, Marcelo Yannuzzi, Herve Muyal, Frank Brockners, Nik Kale, Ankit Agarwal, Jeffrey Hickman, Amritha Lal |
| | Working Group: |
Individual Submissions (none) |
|
Distributed Multi-Agent Systems consist of Agents and MCP Servers operating across multiple administrative domains, each with its own Identity Providers (IdPs) and Authorization Servers (AS). This document discusses the challenges and solution approaches for sharing authorization information securely and flexibly across domains, including the use of dynamic identity, interoperable claims, and verifiable credentials. |
| | Geographic Location for Media over QUIC Relays |
| |
|
This document defines a mechanism for Media over QUIC (MoQ) relays to advertise their geographic location (geocode) and related path metrics. Some clients require their media data to remain locally or geo-fenced within specific jurisdictions for privacy and security compliance (e.g., GDPR, HIPAA, or sector-specific regulations). This mechanism enables service providers to track the geographic path of media packets through the relay mesh and to enforce geo-fencing policies. It supports Geo-Distributed Orchestration and Routing (GDOR), data residency compliance, latency optimization, and relay selection. The specification includes optional IATA airport codes as human-readable geographic identifiers for major relay locations. |
| | Delivered-Enc Email Header Field |
| |
|
Cryptographically protected email aims in hiding and protecting. Extending this to an uppermost extend also for trace headers, and/or the transport layer, so that only directly involved hops, which need to have a notion to "know", the sending system and/or the receiving system thus, can interpret certain header information, can be important. This document ensures that only the receiving system, in its desire to prevent email loops, can interpret the real content of the delivery notice header. |
| | Authority Documents and Scoped Authority for Agent-Action Evidence |
| |
|
Signature verification answers whether a key produced an artifact. It does not answer why a relying party accepts that key, or whether the key holder had authority for the action. This document specifies two composable artifacts. An Authority Document introduces and rotates an organization's evidence-issuing keys through a signed, hash-chained sequence. A Scoped Authority Proof records the authority held by a subject at a registry snapshot, including role, action scope, material limits, policy binding, validity, and revocation status. A relying party evaluates both artifacts under its own pinned trust inputs and policy. The design does not make a self-presented key authoritative, does not turn log inclusion or domain control into automatic trust, and does not equate a valid signature with permission to act. It also defines a source- resolution boundary: signing a statement does not give its underlying source data finer freshness or precision than that source actually provides. |
| | OASNT-CAID: Canonical Action Identifier Derivation and the Named-Human Binding |
| |
|
This document profiles OASNT tokens for consumption by executor-side processing models. It fixes one normative derivation of a Canonical Action Identifier (CAID) from the OASNT action digest, so that every executor checks the same derivation rather than each integration defining its own, and it specifies the semantics of the token's named-human binding, including a subject-to-enrollment check whose absence this profile makes a refusal. |
| | Signed Memory Projection Records for Verifiable AI Context Delivery |
| |
|
Encrypted and signed memory objects can establish source integrity, authorship, and read-time trust without establishing which exact bytes a memory adapter selected and delivered to a downstream AI system. This document specifies a provider-neutral signed Memory Projection Record. The record commits to the recall request and selection policy, the read-time keyring snapshot, the ordered source objects and exact context fragments delivered, the complete projection bytes, and summarized exclusions. It deliberately does not claim that a model received, used, or weighted the projection, that an action was authorized, or that an outcome occurred. ApertoMemory is one source profile; other memory formats can use the same projection boundary. |
| | GPT: Generic Protocol Type |
| |
|
This document specifies GPT (Generic Protocol Type), a convention by which an HTTP address publishes the JSON Schema of the action it accepts, and accepts that action as a request body validated against the same schema. A client retrieves the schema at the moment of contact, produces a conforming value, and submits it unchanged. No client library, prior registration, or separate description of the capability is required. The schema serves as both the published description and the server-side check, so the two cannot diverge. |
| | The DOWNGRADE BGP Community for Denial-of-Service Attack Mitigation |
| |
|
This document outlines a method to mitigate Denial of Service (DoS) attacks by using a well-known BGP community named "DOWNGRADE" as signal to neighboring networks to treat traffic destined towards "DOWNGRADE" tagged IP prefixes with low precedence. The "downgrade" strategy offers an appealing alternative to Remote Triggered Blackhole (RTBH) filtering, because RTBH filtering completes the DoS attack and hampers the defender's ability to monitor whether the attack is still ongoing. |
| | Deterministic Three-Way Merge for JSON Values |
| |
|
For a fixed, disclosed resource policy, this document defines a deterministic three-way merge operation for a restricted JSON value domain. Given a shared base value and two independently derived values, called source and target, the operation produces either one complete merged JSON value or an ordered set of structured conflicts. The operation defines strict JSON input processing, finite binary64 number normalization, scalar and object merge laws, explicit missing- member semantics, RFC 6901 conflict paths, typed conflict kinds, a fail-closed result for arrays, and bounded failure behavior. It is independent of HTTP and does not define array merge semantics, application-specific semantic resolution, content identity, or authorization policy. |
| | Verifiable Safeguards Records (VSR) for Nuclear Material Accountancy |
| |
|
Nuclear material accountancy reporting flows from facility operators to State Systems of Accounting for and Control of nuclear material (SSACs), to regional inspectorates, and to the International Atomic Energy Agency. The records exchanged are confidential, are held in separate databases that are rarely reconciled against one another, and rest on asserted rather than demonstrated integrity: a party holding a record can alter it after the fact without leaving evidence detectable by any other party. This document defines Verifiable Safeguards Records (VSR), a profile of COSE-signed statements and transparency-log registration that produces tamper-evident, independently verifiable evidence about accountancy declarations without disclosing their contents. VSR specifies a commitment-based record format supporting selective disclosure to differently authorized inspectorates, a cross-party reconciliation procedure for transit matching and discrepancy notices, and a dual-layer anchoring scheme that preserves verifiability beyond the operational lifetime of any single registry -- the horizon required for spent fuel management, decommissioning, and geological repository closure. VSR is an evidence layer. It does not verify physical measurements, detect undeclared material, or substitute for inspection. |
| | Web4 Sovereign Entity Comprehension: Requirements and External Conformance Framework |
| |
|
This document defines requirements and an external conformance framework for sovereign Machine Entity Comprehension (MEC) systems operating in Internet-connected or Internet-capable environments. MEC is defined as an externally observable capability. A conforming system preserves entity identity across changing contexts, distinguishes similar but separate entities, determines relevant relationships and constraints, responds appropriately to material changes, handles contradictory assertions, and produces repeatable outcomes under equivalent declared conditions. The framework evaluates behavior through controlled inputs, pre- registered reference outcomes, declared system state, and observable outputs. It does not prescribe or disclose internal representations, implementation algorithms, source code, deployment architecture, confidential operational methods, or other implementation-specific mechanisms. The document also defines operational-sovereignty requirements for systems intended to remain under operator control and retain declared core capabilities without dependence on an external intelligence service. A minimal, implementation-neutral conformance record supports comparable reporting across heterogeneous systems. |
| | WIMSE Workload-to-Workload Authentication with HTTP Signatures |
| |
|
The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones to complex multi-service, multi-cloud, multi-tenant deployments. This document defines one of the mechanisms to provide workload authentication, using HTTP Signatures. While only applicable to HTTP traffic, the protocol provides end-to-end protection of requests (and optionally, responses), even when service traffic is not end-to-end encrypted, that is, when TLS proxies and load balancers are used. Authentication is based on the Workload Identity Token (WIT). |
| |
|
| |
| | Bundle Protocol Security (BPSec) COSE Context |
| |
|
This document defines a security context suitable for using CBOR Object Signing and Encryption (COSE) algorithms within Bundle Protocol Security (BPSec) integrity and confidentiality blocks. A profile for COSE, organized by algorithm families, and for public key certificates are included for BPSec interoperation. This document updates BPSec RFC 9172 by providing Concise Data Definition Language (CDDL) rules for extensible security block content. |
| | TLS 1.2 Update for Long-term Support (LTS) |
| |
|
This document specifies an update of TLS 1.2 for long-term support (LTS) on systems that can have multi-year or even decade-long update cycles, one that incoporates as far as possible what's already deployed for TLS 1.2 but with the security holes and bugs fixed. This document also recognises the fact that there is a huge amount of TLS use outside the web content-delivery environment with its resource-rich hardware and software that can be updated whenever required and provides a long-term stable, known-good version that can be deployed to systems that can't roll out ongoing changes on a continuous basis. |
| | Supporting IOAM in IPv6 |
| |
|
IOAM pre-allocated trace option data fields can be encapsulated in the IPv6 Hop-by-Hop (HbH) Options header as described in RFC 9486. However, due to the potentially large size of the trace data and the location of the HbH Options header in the IPv6 packet, this scheme creates practical challenges for implementation, especially when other extension headers, such as a routing header, are also present and require on-path processing. In addition to IOAM Direct Export (DEX), this document proposes two alternative approaches to address this challenge: separating the IOAM incremental trace data from the IOAM instruction header, or applying the segment IOAM trace data export scheme, depending on the network scenario and application requirements. We discuss the pros and cons of each approach. |
| | The Architecture of Network-Aware Domain Name System (DNS) |
| |
|
This document describes a framework that extends the Domain Name System (DNS) to provide network awareness to applications. The framework enables DNS responses that depend on communication service requirements such as QoS or path, without changes to the format of DNS protocol messages or to application programming interfaces (APIs). The different enhancement methods and use cases are discussed. |
| | A Pre-Authentication Mechanism for SSH |
| |
|
Devices running SSH are frequently exposed on the Internet, either because of operational considerations or through misconfiguration, making them vulnerable to the constant 3-degree background radiation of scanning and probing attacks that pervade the Internet. This document describes a simple pre-authentication mechanism that limits these attacks with minimal changes to SSH implementations and no changes to the SSH protocol itself. |
| | PKCS #15 Updates |
| |
|
This document describes updates to the PKCS #15 standard made since the original publication of the standard. |
| | Media over QUIC - Hang |
| |
|
Hang is a real-time conferencing protocol built on top of moq-lite. A room consists of multiple participants who publish media tracks. All updates are live, such as a change in participants or media tracks. |
| | A Deployment Profile for DKIM2 via Milter Interface |
| |
|
This document defines a deployment profile for DomainKeys Identified Mail v2 (DKIM2) that is implementable via the existing milter interface without modifications to Mail Transfer Agent (MTA) core software. It identifies a mandatory core profile (DKIM2-core) covering envelope binding, chain of custody, header accountability, replay prevention and DSN authentication and an optional extended profile (DKIM2-extended) covering body recipes and Message-Instance headers. The separation is motivated by deployment realism: the core profile addresses the primary threat models identified in the DKIM2 motivation document and is deployable incrementally across heterogeneous infrastructure, including small operators, universities and research institutions, using the same milter-based deployment model that has proven effective for DKIM1 and ARC. The intent of this document is not to obstruct DKIM2 but to make it deployable. DKIM2-core can be deployed incrementally across the heterogeneous ecosystem in a short timeframe. DKIM2-extended requires significantly longer implementation cycles and may not be deployable in jurisdictions with stricter privacy requirements. Both profiles are part of DKIM2 - the separation serves adoption, not opposition. |
| | Delegated Refresh Tokens for OAuth 2.0 Token Exchange |
| |
|
OAuth 2.0 Token Exchange permits an authorization server to issue a refresh token when a client needs continued access after the original credential is no longer valid. However, RFC 8693 does not define how a refresh token issued by a delegated Token Exchange preserves the subject, actor chain, resource restrictions, or other delegated authorization state. This specification profiles refresh tokens issued by delegated OAuth 2.0 Token Exchange for asynchronous and long-running workflows. It defines authorization-server metadata advertising profile support and a Token Exchange request signal by which a client requests delegated continuation, together with preservation of subject and actor relationships, client and actor binding, resource confinement, scope monotonicity, authorization re-evaluation, rotation, task-scoped revocation, and a bounded delegation lifetime. The common discovery signal, request signal, and semantics enable autonomous agents and other product components to interoperate with independently implemented authorization servers across trust domains. Because a client generally cannot determine the effective lifetime of an opaque refresh token, this profile requires the client to request continuation only for an identified asynchronous task and to promptly revoke the refresh-token family when that task reaches a terminal state. These requirements reduce unnecessary issuance and limit the period in which residual delegated authority can be abused. The profile uses the existing OAuth refresh token response and grant and introduces no new token type or grant type. |
| | MoQ Object Timestamp Extension |
| |
|
This document specifies the transport-level use of the TIMESTAMP and TIMESCALE properties registered by [loc], independent of the LOC container itself. A track-level Timescale property establishes the units, and an object-level Timestamp property carries the presentation time of each object. Exposing media time to the transport lets relays make consistent age-based decisions (e.g. dropping stale objects) without parsing the media container, and it remains consistent across hops regardless of buffering or jitter. No new code points are requested: an endpoint implementing this document is on the wire indistinguishable from a LOC endpoint that carries only these two properties. |
| | Workload Authorization Grant |
| |
|
This document profiles the Agent Identity Management System (AIMS) framework for agent platforms that host many agent instances per customer. Each agent is identified by an opaque, non-reassignable agent identifier; the agent obtains access tokens by presenting a JWT authorization grant (RFC 7523), signed by the platform's per-tenancy issuer, in the assertion parameter at the authorization server protecting the resource server. Trust is established once, by reference to the issuer's published metadata and keys; agent creation requires no per-agent step at the authorization server or resource server; and authorization is expressed over platform-asserted agent properties that resource servers map locally to permissions. This profile addresses agents acting on their own behalf; access on behalf of a user or other principal is out of scope, though the design is intended to compose with existing delegation mechanisms in which the agent appears as the actor. |
| | The Zero Trust Intelligence Protocol (ZTIP): Governed,Independently Verified AI Agent Transactions |
| |
|
The Zero Trust Intelligence Protocol (ZTIP) is an open, transport- neutral protocol for governed AI agent transactions. It defines five immutable JSON envelope types and a transaction lifecycle under which every agent-initiated action is authorized by policy before execution, integrity-protected by hash over a canonical form, and -- distinctively -- verified as complete by an authority independent of the actor that performed the work. An executor's claim of success is treated as attestation, and attestation alone never satisfies a required verification check. This document describes ZTIP version 1.0-draft for the record; the full specification, JSON Schemas, examples, and a reference runtime are maintained in the open at the repository referenced herein. |
| | MoQ Cluster Extension |
| |
|
This document defines a clustering extension for MoQ Transport [moqt], used to build a mesh of relays. Each namespace advertisement carries the ordered list of Hop IDs it has traversed, starting with the original publisher, plus the accumulated cost of that path. A receiver uses the list to detect routing loops and to identify which advertisements come from the same publisher, and the cost to choose between paths. Each endpoint declares its own Hop ID during setup, and the peer uses it to avoid advertising or serving a path that already passed through that endpoint. |
| | QMux over WebSocket |
| |
|
QMux [qmux] is a polyfill that runs QUIC applications over an ordered, reliable byte-stream transport such as TCP with TLS. This document defines a binding for QMux over WebSocket [RFC6455]. A WebSocket binding lets QUIC applications reach environments where UDP is blocked and where only an HTTP/WebSocket stack is available, including web browsers that lack WebTransport. |
| |
|
| |
| | Verifiable AI Refusal Events using SCITT |
| |
|
This document defines a claim set for recording AI content refusal events. The claim set specifies the semantic content and correlation rules for refusal audit trails, independent of any particular serialization format. The claims are designed to be carried within SCITT Signed Statements and verified using SCITT Receipts. This specification addresses claim semantics and verification requirements; it does not mandate a specific encoding. A CDDL definition is provided for CBOR-based implementations, and equivalent JSON representations are shown in an appendix for illustration. This specification provides auditability of logged refusal decisions. It does not define content moderation policies, classification criteria, or what AI systems should refuse. |
| | Content Provenance Profile (CPP) Core |
| |
|
The Content Provenance Profile (CPP) is an open specification for cryptographically verifiable media capture provenance. This document defines the core data model, hashing conventions, Merkle tree construction rules, RFC 3161 Time-Stamp Authority (TSA) anchoring protocol, and offline verification procedures for CPP. CPP enables capture devices to produce tamper-evident provenance records that bind media content to external timestamps via trusted third parties. Unlike self-attestation models, CPP requires independent timestamp verification through RFC 3161 TSA services, providing externally verifiable proof of when media was captured. CPP defines self-attested signer identity, hardware-backed key requirements, chain context for partial submission detection, a Completeness Invariant for omission detection, an OPTIONAL depth analysis extension for screen detection, and an OPTIONAL Pre-Publish Verification Extension. It also defines interoperability mappings with the C2PA specification. This revision (-03) corrects a normative length constraint on the LeafHashMethod value, corrects the description of the relationship between the CPP Merkle construction and Certificate Transparency, adds a verifier obligation to cross-check TreeSize against the sealed event count, documents the limits of leaf-duplication padding, and positions CPP within the Verifiable AI Provenance Framework (VAP) profile family and relative to the SCITT architecture (RFC 9943). |
| | Principles and Guidelines for Assignment of RFC Authorship |
| |
|
This document discusses principles and guidelines for assigning authorship in RFC documents, including guidelines for the use of software tools during document preparation, and for inclusion of material from other sourcess. An important focus is on authors' responsibility for the content. The document also discusses the related issues of acknowledgements, editors and contributors. The various RFC streams are expected to apply these guidelines, and possibly define their own variations, which will have priority. |
| | SDLP Lineage Specification |
| |
|
This document defines the SDLP lineage model, which provides the canonical method for representing the ancestry of SDLP-governed objects. Lineage is a structural property that records how an object evolves through duplication and transformation events. The lineage model ensures that descendant objects remain uniquely identifiable and traceable across all lifecycle transitions. Lineage-03 aligns the lineage grammar with Identity-02, Lifecycle-02, and Object-Format-07, and defines deterministic ancestry extension rules that produce stable, verifiable lineage across all SDLP implementations. This revision incorporates BitDrop conditions for invalid lineage transitions and specifies normative validation requirements for relying parties. Together with Identity-02, Lifecycle-02, and Object-Format-07, this document provides the authoritative lineage model required for interoperable identity, lifecycle, and provenance processing. |
| | Agent Registry (AREG) |
| |
|
The Agent Registry (AREG) is an open, vendor-neutral specification for publishing, discovering, and resolving artificial intelligence (AI) agent definitions. An AREG registry entry is a lightweight metadata document that records where a specific version of an agent definition can be fetched, who published it, what version it is, and how consumers can verify its authenticity. AREG also defines a REST API that conforming registry servers implement to expose search, resolution, and publication endpoints to consumers and publishers. AREG is the discovery and registry layer of the Schema Commons agent stack. It is designed to compose with the Autonomous Agent Interchange Format (AAIF, SC-006), which defines the content of the agent definition document that an AREG entry points to, and with the Agent Capability and Profile Model (ACPM, SC-014), which provides richer capability, trust, cost, and service-level information that a registry entry can reference. Neither AAIF nor ACPM is required for a conforming AREG implementation. |
| | Load-Adaptive Priority Migration Mechanism for Deterministic Switched Ethernet |
| |
|
This document proposes a Load-Adaptive Priority Migration (LAPM) mechanism for deterministic switched Ethernet. The mechanism classifies traffic into three criticality levels (TC0/TC1/TC2), which are logically equivalent to the foundational classification of network slicing. An inverse M/D/1 queuing model is introduced to derive per-hop network utilization from measured forwarding delay, requiring no additional probe traffic. A four-level load classification scheme with hysteresis logic drives dynamic remapping of the IEEE 802.1Q Priority Code Point (PCP), enabling traffic priority to adapt as network load changes. LAPM serves as a runtime complement to the scheduling framework defined by RFC 9320. Existing DetNet queuing mechanisms (TAS, CBS, CQF, Guaranteed Service) rely on statically pre-configured offline parameters, whereas LAPM monitors utilization in real time and adaptively adjusts PCP when load levels cross pre-defined thresholds. This capability is particularly critical for deployment scenarios with time-varying traffic patterns, including automotive backbone networks, industrial automation, and professional audio/video systems. Experimental validation on a 5-node ring topology (1000BASE-T) across three traffic classes reveals the existence of three operationally distinct regions — normal, transitional, and saturated — where load bursts in the transitional region cannot be captured by the EWMA- smoothed utilization metric alone. A cross-domain maximum aggregation mechanism coordinates load-level decisions across multiple VLANs via a shared global variable, ensuring consistent priority migration policy enforcement. In summary, the LAPM mechanism provides a means to guarantee low- latency transmission for critical flows through dynamic load-based priority control. |
| | Bounded Execution Programs for Consequential Agent Actions |
| |
|
An authorization for one action does not by itself authorize an open- ended agent plan. This document defines an Experimental profile for a signed, finite, versioned directed acyclic graph of consequential action occurrences. The program binds a total retained-history ceiling. Each node binds an exact action or a pinned action-matching profile, an action- specific Trust Program, outcome-specific dependencies, an occurrence ceiling, and fixed charges against aggregate attempt budgets. A conforming program-aware admission store evaluates reachability and budgets in the same linearizable transaction domain as the ordinary one-time execution right. It uses store-owned authorizer trust roots, clock, authenticated profile-match verification, and current program status; seals a deterministic execution-program resource into the AdmissionSnapshot; and fences the program's independent authorization digest against ordinary-path admission. The profile does not establish that natural-language intent was understood, that a plan is safe or lawful, that provider or effect evidence is true, or that every mutation path was mediated. |
| | Reliance Agreements: Signed Liability Terms Conditioned on Authorization-Evidence Sufficiency |
| |
|
This document defines EP-RELIANCE-AGREEMENT-v1, a signed, machine- readable statement of terms conditioned on a specific relying-party evidence profile, and EP-RELIANCE-EVENT-v1, a signed per-action record joining one action, one reliance result, and one agreement. The agreement references the evidence condition by digest rather than restating or weakening it. Every required party signs the same canonical bytes, and monetary amounts are represented as decimal strings. Verification establishes signatures, content integrity, scope, time, and digest bindings. It does not authorize an action, re-evaluate the evidence packet, establish legal enforceability, issue insurance, determine coverage, allocate fault, prove solvency, reserve funds, or compel payment. Those decisions remain with the relying party and the applicable prose agreement, law, and dispute forum. |
| | Applicability of Bidirectional Forwarding Detection (BFD) for Multi-point Networks in Virtual Router Redundancy Protocol (VRRP) |
| |
|
This document specifies the applicability of Bidirectional Forwarding Detection in multipoint networks to support sub-second failure detection for Virtual Router Redundancy Protocol Router Role election. The mechanism enables faster determination of the Active Router without requiring any modification to the protocol behavior or message formats defined in RFC 9568. |
| |
|
| |
| | DNS Filtering Transparency |
| |
|
[I-D.ietf-dnsop-structured-dns-error] introduces structured error data for DNS responses that have been filtered. This specification allows more specific details of filtering incidents to be conveyed. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/mnot/public-resolver-errors. |
| | QIK-VRT Effect Acknowledgement: Separating Receipt from Authorization for Downstream Effect |
| |
|
Transport acknowledgements establish technical receipt; they do not establish that a received information unit is understood, policy- compliant, or authorized to produce a downstream effect. This document defines an Experimental application-layer control record, called EFFECT_ACK, that separates receipt from effect authorization. The protocol has five closed version-1 outcomes. Ordinary downstream release is permitted only for EFFECT_ACK_DONE and only after validation of the record, its policy and evidence bindings, its freshness, and its authenticated origin. This document specifies the state-selection algorithm, version handling, a deterministic JSON representation, hash chaining, timeout behavior, conformance requirements, and security and privacy boundaries. This protocol does not modify TCP, QUIC, or the OSI model; does not solve the halting problem; and does not establish the truth of external evidence. It provides a machine-checkable authorization boundary under explicitly stated deployment assumptions. |
| | Rooting Decentralized Identifiers in DNSSEC: A DANE-EE Key-Binding Profile |
| |
|
Several Decentralized Identifier (DID) methods root trust in a DNS name: did:web binds an identifier to a domain and today verifies its keys over the Web PKI, did:dns serves DID data from DNS resource records, and did:webvh retrieves its history from an HTTPS location derived from a name. Each either depends on the Web PKI, treats DNSSEC as an optional recommendation, or does not bind the verification-method key to the name at all. This document defines a single, normative DANE-EE key-binding profile that any DNS-anchored DID method can point at rather than reinventing: a verification method's public key is published as a TLSA record with certificate usage DANE-EE(3), selector SubjectPublicKeyInfo(1), and matching type SHA2-256(1) under a DNSSEC-signed name, so that a relying party can confirm the key from the DNS root of trust with no certificate authority and no fetch from the subject. The profile binds a name to a key and the key to the specific DID document it signs, and no further; it states precisely what it does not cover, including continuity of holding, and points to where those answers live. |
| | End-to-End Encryption and Purpose-Bound Governance for Agent-to-Agent Messaging |
| |
|
Agent-to-agent protocols increasingly carry messages between autonomous software agents acting on behalf of distinct principals, including across organisational boundaries. Existing protocols in this space secure the transport hop and authenticate the calling party, but do not provide message-level confidentiality, do not provide non-repudiable evidence of what a counterparty asserted, and do not carry machine-enforceable constraints on how a recipient may use the data conveyed. This document specifies a profile that addresses those three gaps. It defines a Governed Object: a signed, purpose-bound, expiring message envelope identified by a decentralised identifier. It specifies how such objects are exchanged inside end-to-end encrypted sessions established using the Messaging Layer Security (MLS) protocol [RFC9420], and how the MLS credential is cryptographically bound to the sending agent's identity. It defines the encapsulation of these constructs as an extension to an agent-to-agent transport, using the Agent2Agent (A2A) protocol [A2A] as the reference binding, and specifies mandatory receiver-side processing rules including replay rejection and purpose enforcement. |
| | Offline Delivery and Reachability for Agent-to-Agent Messaging |
| |
|
Agent-to-agent protocols assume a live HTTP or streaming hop. Many deployments cannot keep every agent always reachable: devices sleep, cost tiers duty-cycle backends, and operators park agents outside business hours. Senders need a machine-readable asleep signal, a bounded expectation for store-and-forward, and validation rules so an offline agent is not a spam sink and does not act on forged or expired messages after wake. This document profiles offline delivery and reachability for A2A- style JSON-RPC messaging. It defines abstract reachability modes, an asleep refusal signal, queue bounds and distinct queue-full errors, validate-on-dequeue requirements, and split delivery semantics (durable persist versus notify). It is independent of Messaging Layer Security (MLS) grouping; deployments that also use [GOMLS] MAY apply both profiles. |
| | Service Type Routing for DNS-SD Service Registration Protocol |
| |
|
This document defines the _str._dns-sd._udp (Service Type Routing) metadata label, a backward-compatible extension for SRP registration. This mechanism relaxes the original single-registration-domain constraint, enabling clients to publish distinct service types to independent target DNS zones and dedicated SRP registrar instances. It supports fine-grained operational tuning, administrative isolation of heterogeneous services. This extension only modifies SRP registration domain selection logic, fully preserves existing SRP wire format, authentication, leasing and discovery behaviors, and introduces no impact on DNS-SD service browsing operations. |
| | The Internet Identity Card (IIC) Credential Format: A Self-Contained,Offline-Verifiable Identity Credential with Hybrid Classical and Post-Quantum Signatures |
| |
|
This document describes the Internet Identity Card (IIC) credential format, version 9.0: a digital identity credential implemented as a single self-contained HTML file that can be generated, stored, transferred, and cryptographically verified entirely offline, without servers, brokers, or network connectivity. Identity data is encrypted with AES-256-GCM under keys derived by Argon2id; authenticity is provided by a hybrid signature combining ECDSA P-256 with ML-DSA-65 (NIST FIPS 204) under a crypto-agile suite registry; and integrity is provided by an embedded SHA-256 self-check over a canonical serialization of the document. Each exported credential embeds its own verification engine, so verification requires only a standard web browser. This document is published for informational purposes, to describe a deployed format whose underlying constructions are disclosed as open prior art. |
| | Applicability of EVPN Assisted Replication to SRv6 Tunnels |
| |
|
Assisted Replication (AR) is an optimized ingress replication solution for Ethernet VPN (EVPN) Broadcast and Multicast (BM) traffic. AR offloads the replication effort from ingress Network Virtualization Edge (NVE) devices onto Assisted Replication Replicators (AR-REPLICATORs). The base AR specification is focused on Network Virtualization Overlay (NVO) networks that use IP tunnels, and it is typically deployed for Virtual eXtensible Local Area Network (VXLAN). EVPN services can also be instantiated over Segment Routing over IPv6 (SRv6); however, the SRv6 EVPN transport specification supports only ingress replication for BUM traffic, and the AR procedures rely on IP-tunnel semantics (such as the tunnel source and destination IP addresses) that do not map exactly to an SRv6 data plane. As a result, AR cannot be readily deployed over SRv6 tunnels. This document specifies the applicability of Assisted Replication to SRv6 tunnels, for EVPN BM traffic, for selective multicast based on Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) proxy, and for EVPN IP multicast traffic based on Optimized Inter-Subnet Multicast (OISM). It defines a new SRv6 Endpoint behavior for the AR-REPLICATOR role and the associated control-plane procedures, so that the AR solution can be used with an SRv6 underlay. |
| | Verifiable Compliance Records for AI Usage Preferences |
| |
|
Work in the AI Preferences (AIPREF) Working Group defines a vocabulary for expressing preferences about how digital assets may be used by automated processing systems, together with mechanisms for attaching those preferences to content. Neither component provides a way for a processing entity to demonstrate that it observed an expressed preference, nor for a publisher or auditor to verify such a demonstration after the fact. This document defines the AI Usage Compliance Record (AUCR), a structure that binds a retrieved asset, the preference expression in force at the moment of retrieval, and the usage category the processing entity assigned to that asset. It defines an aggregation scheme that allows a processing entity to attest to very large numbers of records with a single signature, a proof mechanism that allows an individual publisher to audit only the records concerning its own assets, and a discovery mechanism for locating attestations and verification keys. The mechanism is deliberately confined to evidence: it makes claims of compliance falsifiable and non- repudiable, and takes no position on the legal effect of any preference or any record. |