| |
|
| |
| | Fast HIP Host Mobility |
| |
|
This document describes mobility scenarios and how to aggressively support them in HIP. The goal is minimum lag in the mobility event. |
| | QUIC Path Management for Multi-Path Configurations |
| |
|
This document defines path management procedures for QUIC that operate independently of the connection management procedures defined in RFC9000. The path management procedures enable a multipath configuration between endpoints by allowing QUIC packets associated with any connection identifier to be transported over any of the paths established between the endpoints. As a consequence, the principles and operations of RFC9000 are retained regardless of the path used to a convey QUIC packet. |
| | Requirements for Monitoring RPKI-Related Processes on Routers Using BMP |
| |
|
This document outlines requirements for extending the BGP Monitoring Protocol (BMP) to provide comprehensive monitoring of RPKI-related processes on routers, including RPKI data acquisition, RPKI-related policy configuration, route validation, and the impact of validation on routing decisions. The proposed extensions aim to standardize router-side monitoring of RPKI within BMP, focusing specifically on RPKI's effect on BGP routing decisions while maintaining a clear scope boundary with other monitoring mechanisms such as YANG modeling and streaming telemetry for RPKI-to-Router (RTR) protocol operations. |
| | Intelligent Data Plane (IDP): Framework and Protocol Considerations |
| |
|
This document describes a framework and protocol considerations for an Intelligent Data Plane (IDP). An IDP enables data-plane nodes to perform bounded, policy-constrained, and observable packet, flow, state, telemetry, or service processing based on standardized signals and locally executable decision functions. The document defines terminology, a reference architecture, signal and result models, decision function abstractions, and communication patterns for IDP systems. It focuses on the interfaces and data formats through which IDP nodes expose signals, features, and results to AI for Network Management (AI-NM) systems, and through which they receive models, policies, and configuration from control and management entities in a self-driving and self-managing network (SD/ MN) context. This document does not define a specific AI or ML algorithm, nor does it require data-plane nodes to perform model training. Instead, it focuses on the interoperable communication patterns and data representations required to integrate intelligent data-plane processing into AI-NM and self-managing network architectures. |
| | BGP Extensions for SRv6 Per-Flow Traffic Engineering: Composite Candidate Path and Forwarding-Class Signaling |
| |
|
The Segment Routing Policy Architecture (RFC 9256) defines the concept of a Composite Candidate Path, which enables a parent SR Policy to recursively steer traffic into a set of constituent SR Policies. Section 8.6 of RFC 9256 further defines per-flow steering, in which packets are classified into a Forwarding Class value by a Quality-of-Service classifier at the headend, and that Forwarding Class value selects a specific constituent SR Policy, identified by its color, for forwarding. RFC 9830 specifies how BGP distributes SR Policy Candidate Paths but explicitly excludes composite Candidate Paths from its scope. Consequently, no standard BGP mechanism currently exists to distribute a parent per-flow SR Policy -- including its Forwarding- Class-to-color mapping table -- to headend nodes. This document defines two new sub-TLVs for the BGP Tunnel Encapsulation Attribute (SR Policy type, Tunnel Type 15): the Constituent SR Policy sub-TLV and the nested Per-Flow Forwarding Class sub-TLV. Together, these extensions allow a controller to distribute a fully specified composite or per-flow Candidate Path to headend routers via BGP. |
| | Private SID Translation for CORECONF |
| |
|
This document describes a mechanism for translating privately assigned YANG SID values to globally allocated SIDs, enabling constrained devices to use compact local identifiers while remaining interoperable with standard CORECONF implementations. |
| |
|
| |
| | Bit Index Explicit Replication (BIER) Ping and Trace |
| |
| | draft-ietf-bier-ping-27.txt |
| | Date: |
30/05/2026 |
| | Authors: |
Nagendra Nainar, Carlos Pignataro, Mach Chen, Greg Mirsky |
| | Working Group: |
Bit Indexed Explicit Replication (bier) |
|
Bit Index Explicit Replication (BIER) is a multicast forwarding architecture designed to simplify and optimize multicast delivery. This document specifies the mechanism and basic BIER OAM packet format that can be used to perform failure detection and isolation on the BIER data plane without any dependency on other layers, like the IP layer. |
| | Formal SignWriting: Internet-Draft Record and Published Reference |
| |
|
This document is the final Internet-Draft update for Formal SignWriting. Formal SignWriting is the plain-text technical model used by Sutton SignWriting resources for FSW, SWU, signboxes, grammar, search, layout, rendering, styling, and implementation practice. The maintained reference publication is now the Formal SignWriting series, version 1.0.0, published through Zenodo, GitHub, and the author's website. This Internet-Draft is retained as a historical IETF-facing bridge and cross-reference. It is not an IETF standard, does not request IETF standardization, and should not be cited as the current reference specification for Formal SignWriting. |
| | Programming Methodology Framework aka PMF |
| |
|
This document describes the Programming Methodology Framework, also known as the PMF methodology. The methodology is based on the manifesto written by Zed A. Shaw [PROGRAMMING-MF-MANIFESTO], which describes a natural approach to software engineering with a strong focus on the act of programming. The PMF methodology uses a neutral name to provide a non-partisan reference for official engineering or project documents describing one of the most widely used software engineering methodologies. |
| | vCon Lawful Basis |
| |
|
This document defines a lawful basis extension for Virtualized Conversations (vCon) that provides standardized mechanisms for recording, verifying, and managing the lawful basis for processing data within conversation containers. The lawful basis extension addresses privacy compliance challenges through structured attachment metadata, including the specific lawful basis being asserted, temporal validity periods where applicable, and cryptographic proof mechanisms. The extension is designed as a Compatible vCon extension that introduces lawful basis management capabilities without altering existing vCon semantics. It defines a "lawful_basis" attachment (identified by the attachment "purpose" value "lawful_basis") with structured records for each of the six lawful bases defined in regulations like GDPR, including consent, contract, legal obligation, vital interests, public task, and legitimate interests. Key features include automated lawful basis detection during conversation processing, auditable records with cryptographic proofs, granular purpose-based permissions for all lawful bases, documented justifications for other lawful bases, and integration with privacy regulations including GDPR, CCPA, and HIPAA. |
| | Payment Evidence Frame for Agentic-Payment Lifecycle Receipts |
| |
|
This document specifies a Payment Evidence Frame (PEF): a transport- agnostic envelope that wraps any payment lifecycle receipt from the x402 agentic-payment receipt stack under a named claim type, a deterministic frame identifier, and an optional transport-layer signature. The frame introduces three properties that the inner receipt types do not individually provide: (1) a stable cross-system identifier (frame_id) derived deterministically from the receipt content by SHA-256 over the JCS-canonical preimage, so the same payment evidence can be referenced by identifier across HTTP headers, agent-to-agent task artifacts, audit logs, and on-chain memo fields without re- serialising the full receipt; (2) a taxonomy label (claim_type) that tells a consumer what class of evidence a frame carries before the inner receipt format is parsed; and (3) a receipt integrity hash (receipt_hash) that allows any downstream party to confirm the inner receipt is unaltered without deserialising its full structure. The format uses the same JCS canonicalisation discipline (draft- hopley-x402-canonicalisation-jcs) as the five inner receipt formats it envelopes, so implementations require only one canonicalisation primitive for the full receipt stack. |
| | Cross-Vantage Clock-Offset Coherence Bounds for NTP-Disciplined Measurement Vantages |
| |
|
The Network Time Protocol version 4 (NTPv4) [RFC5905] specifies how a host disciplines its clock to a reference time scale; Network Time Security [RFC8915] and the Message Authentication Code [RFC8573] authenticate the client-server exchange; and the NTP Best Current Practices [RFC8633] direct operators to "monitor their NTP instances to detect attacks" (Section 5.3) without specifying a quantitative, cross-host monitoring procedure. The Security Requirements document [RFC7384] establishes that an on-path adversary can impose a clock offset (Sections 3.2.2, 3.2.3, 3.2.6) and that a single client cannot always detect such an offset by itself. This document makes ONE contribution and proves it: given two or more measurement vantages disciplined to a common reference and each declaring an NTP-tier offset bound, a deterministic cross-vantage detector exists that (a) NEVER fires on offsets that are legitimate under the [RFC5905] / [RFC8633] synchronization envelope, and (b) is GUARANTEED to fire on an injected single-clock offset above a closed- form threshold. Both properties are theorems with elementary proofs; no statistical assumption, no protocol change, and no claim about the NTP wire format are required. The detector is the cross-vantage clock-skew axis of the Multi-Vantage Path Snapshot (MVPS) framework [I-D.melegassi-ippm-mvps-bundle]; this document isolates and proves the part that is purely a consequence of [RFC5905]'s error envelope. A second result governs what happens AFTER detection, when the environment itself collapses (vantages go dark, telemetry thins). We prove (i) that the false-positive-free property survives any telemetry collapse with two or more surviving vantages, and (ii) a data-processing ceiling: an AI/LLM analysis layer riding the gated signal cannot recover information the surviving vantages did not observe. The LLM's role is therefore provably EXPLANATION of an already-detected collapse, never detection itself; its operating envelope (decision tiers, classification accuracy) is given honestly as a stated model, not a theorem. A third result governs SPEED. Driving the same cross-vantage comparison at a Bidirectional Forwarding Detection (BFD, [RFC5880]) cadence instead of the legacy 60-second coherence tick gives a closed-form detection-latency window (the L_DL lemma) whose worst case equals the BFD detection time plus one signalling delay. Because the false-positive-free property (Theorem 1) is independent of the sampling rate, the gate may run at the fastest BFD cadence (multiplier 1) WITHOUT trading away its zero-false-alarm guarantee, detecting an injected offset in tens of milliseconds rather than tens of seconds. |
| |
|
| |
| | Enforcement of IPv6 Extension Headers Ordering and Occurrence at Destination Nodes |
| |
|
Operational experience has demonstrated that permitting multiple occurrences of the same IPv6 Extension Header can create parsing ambiguity, complicate packet processing, and increase potential security risks. Although RFC 8200 recommends that senders follow a specific order of appearance and limit the occurrences of Extension Headers, receivers cannot assume that these recommendations have been followed. This document updates RFC 8200 by allowing an IPv6 destination node, namely a host (i.e., the final destination of an IPv6 packet) or an intermediate destination node addressed by an entry in a Routing header list other than the final one, to enforce strict ordering and limits on the occurrence of Extension Headers. |
| | BGP Extension for 5G Edge Service Metadata |
| |
|
This draft describes a new Edge Metadata Path Attribute and some Sub- TLVs for egress routers to advertise the Edge Metadata about the attached edge services (ES). The edge service Metadata can be used by the ingress routers in the 5G Local Data Network to make path selections not only based on the routing cost but also the running environment of the edge services. The goal is to improve latency and performance for 5G edge services. The extension enables an edge service at one specific location to be more preferred than the others with the same IP address (ANYCAST) to receive data flow from a specific source, like a specific User Equipment (UE). |
| | IKEv2 negotiation for Bound End-to-End Tunnel (BEET) mode ESP |
| |
|
This document specifies a new Notify Message Type Payload for the Internet Key Exchange Protocol Version 2 (IKEv2), to negotiate IPsec ESP Bound End-to-End Tunnel (BEET) mode. BEET mode combines the benefits of tunnel mode with reduced overhead, making it suitable for applications requiring minimalistic end-to-end tunnels, mobility support, and multi-address multi-homing capabilities. The introduction of the USE_BEET_MODE Notify Message enables the negotiation and establishment of BEET mode security associations. |
| | Domain Key Authorities (DKA): DNS-Designated Public Key Distribution for Email-Address Identifiers |
| |
|
This document specifies the Domain Key Authority (DKA) framework, a DNS-anchored public-key distribution mechanism for the email-address namespace. The framework enables an Internet domain to designate an authoritative key service that verifies, stores, and distributes selector-scoped public keys for email-address identifiers under that domain. The result is a decentralized, deterministic, and application-agnostic framework for verified public-key discovery that supports incremental deployment and cryptographic agility. |
| | JCS Canonicalisation Discipline for Agentic-Payment Receipts |
| |
|
This document specifies a canonicalisation discipline for agentic- payment receipt formats. The discipline pins JSON Canonicalization Scheme (JCS, RFC 8785) as the canonical preimage form, plus a small set of schema-normalisation rules that must be applied before canonicalisation to preserve byte-determinism across independent implementations and across statutory retention periods. The discipline is identified by the URN urn:x402:canonicalisation:jcs-rfc8785-v1. Receipt formats that reference this discipline carry an in-band canon_version field recording the version under which they were emitted, enabling year-N re-verification of retained bytes without dependence on an out-of- band rule registry. The discipline is byte-for-byte cross-validated across eight independent JCS implementations in eight programming languages: Python (rfc8785), TypeScript (canonicalize), Go (gowebpki/jcs), Rust (serde_jcs), Java (cyberphone/json-canonicalization, by the RFC 8785 editor), PHP (root23/php-json-canonicalization), C#/.NET (Baqhub.Packages.JsonCanonicalization), and Ruby (json- canonicalization). The attestation record covering 192 byte-for-byte agreements is published at the AlgoVoi conformance vectors repository. This document is normatively referenced by [draft-hopley-x402- compliance-receipt], [draft-hopley-x402-refund-receipt], and successor AlgoVoi-authored receipt-format Internet-Drafts. It is complementary to [draft-vauban-x402-stark-receipts], which uses a compatible canonicalisation discipline for its cryptographic settlement proofs. This document is an Independent Submission filed per RFC 4846 and is intended for publication as Informational. It is not an IETF Standards Track document, does not represent IETF community consensus, and has not been subject to review by an IETF Working Group. Change control resides with the document author. The canonicalisation discipline specified is one approach among possible alternatives; implementers may choose this approach, alternative approaches, or hybrid approaches as appropriate to their requirements. |
| | Multi-channel Pixel Diagonal Flow (MPDF) Protocol Specification |
| |
|
This document updates the Deterministic Spatial Restoration Protocol (DSRP) specification by defining the low-level silicon memory pointer trajectories required to execute 4-to-1 Macro-Pixel Fusion. To achieve zero-CPU, hardware-wire speed execution and eliminate pipeline memory stalls, DSRP rejects single-row or single-column iterative scanning. This specification mandates a Dual-Row Parallel Shunt (DRPS) mechanism, where the hardware memory controller treats the 2D canvas as interlocking row-pairs, scanning horizontally with a 2-bit sliding window to output the 2-bit Absolute Gate Numbers within a single clock cycle. |
| | Agent Trust Negotiation: Capability,Delegation,and Provenance Binding for AI Agents |
| |
|
This document defines the Agent Trust Negotiation (ATN) protocol. ATN sits above whatever mechanism is used to discover an agent identity and answers questions that discovery alone cannot: what is the agent permitted to do, under whose authority, with what provenance, and how do two agents reach a verifiable working agreement. ATN binds four artifacts to a discovered agent identity: |
| | SMTP REMEMBERME extension for quick reauthentication token generation |
| |
|
This document specifies an SMTP extension for generating quick reauthentication tokens that allow clients to re-login without user interaction, once authentication using a strong SASL mechanism is completed. |
| | x402 Cryptographic Receipts: Format,Post-Quantum Discipline,and Starknet Anchor |
| |
|
The x402 V2 protocol defines HTTP-native payment flows but leaves three gaps that block compliance use cases. First, the PAYMENT- RESPONSE carries a facilitator-issued reference rather than a self- contained, offline-verifiable cryptographic receipt; an auditor cannot validate a retained receipt without contacting the facilitator. Second, classical signatures alone (ES256K) do not satisfy the post-quantum migration horizon set by NIST SP 800-208, ANSSI, BSI, and EU eIDAS 2.0 for high-value or long-retention material. Third, off-chain receipts alone do not provide ledger- anchored finality required by frameworks such as MiCA Art. 76 (settlement record-keeping) and EU AI Act Art. 12 (transparency-and- documentation). This document consolidates three previously separate extensions into a single specification. It defines (a) a negotiable receipt-format extension with three variants (Stwo Circle STARK proof, hybrid ES256K + ML-DSA-65 dual-signature, classical ES256K fallback) over a JCS canonical preimage discipline grounded in RFC 8785; (b) a two-axis post-quantum discipline mapping hash-based proving and hybrid signatures to the NIST PQC migration roadmap; and (c) a Starknet on- chain anchor format with a canonical anchor tuple, Cairo event layout, RPC endpoint convention, and block explorer reference for human-readable audit. Topics under active coalition discussion are explicitly out of scope: the VPSF composability claim algebra, the payment lifecycle finite state machine, and the delegation binding extension are deferred to companion documents not included in this consolidated submission. |
| | Resolvable Universally Unique Identifiers (RUUID) |
| |
|
This document defines Resolvable Universally Unique Identifiers (RUUIDs): a UUID format encoding a 64-bit IPv6 network prefix, a 48-bit identifier, and a 10-bit type. A resolver uses reverse DNS on the network prefix to discover the associated domain and, via that domain's "UUID document", constructs a URI of the referent. Defaults for both the document location and the referent URI template mean that when URLs follow the canonical convention, nothing beyond a reverse-DNS PTR record needs to be published; resolution degrades gracefully when configuration is missing. The 64-bit network field carries an IPv6 /64 prefix directly. An IPv4 /32 is encoded as the corresponding 6to4 prefix (RFC 3056). RUUIDs are 128 bits in the standard UUID textual form. Pending a dedicated UUID version, they use the RFC 9562 experimental version 8 with variant 10, so existing UUID parsers recognise them as well- formed UUIDs. |
| | MVPS Video-Surveillance and CCTV Profile: Fleet-Coherence Detection of Feed Replay and Loop Injection Across IP Cameras |
| |
|
This document defines a Multi-Vantage Path Snapshot (MVPS) domain profile for video surveillance: fleets of IP cameras, NVR/VMS recorders, and cloud video-surveillance-as-a-service (VSaaS) endpoints treated as MVPS vantages. Its target threat is the feed-replay (loop) attack -- an on-path adversary that substitutes a live camera stream with previously recorded footage so that operators and single-camera analytics see nothing wrong. The profile re-establishes the bounded-joint-skew axiom A1 under the video pipeline (camera NTP/PTP residual, encoder and GOP buffering, recorder jitter buffer, frame-interval quantization), gives a closed-form maximum pipeline budget, and proves the headline result: with capture timestamps authenticated at the sensor, any replayed loop older than a closed-form, strictly positive minimum age leaves the coherence ball and is flagged by core Theorem T2. The core detection and Byzantine theorems are inherited via the MVPS Architecture-Invariance Theorem. The profile is DEFENSIVE: it detects coherence anomalies (feed replay, loop, tamper, rogue ingest). It defines no facial recognition, biometric, tracking, or identification function. All properties are validated by scripts/validate_video_surveillance.py (7/7 PASS, exit 0) and recorded in evidence/video_surveillance_receipt.json. |
| | Computing-Aware Traffic Steering (CATS) Northbound Interface (NBI) Specification |
| |
|
In scenarios such as industrial Internet, smart cities, and smart hospitals, enterprise customers lease a large amount of computing and network resources from operators and need to manage their own resources flexibly for agile business operations. Therefore, these customers’ systems require the Computing-Aware Traffic Steering (CATS) northbound interface (NBI) to gain greater flexibility in business optimization. The CATS NBI is a standardized set of interfaces that governs interactions between the CATS system and upper-layer applications, software, and services. It defines interaction protocols, data models, message formats, and procedures. Unlike the southbound interface, which carries detailed information, the NBI simplifies data structures to deliver streamlined management capabilities. Positioned between the three-layer CATS architecture and scenario-specific applications, it is primarily invoked by user management platforms, user business orchestration systems, AI inference platforms, and other application services. However, the current lack of a unified standard for the CATS NBI results in protocol heterogeneity, incompatible data formats, and inconsistent functionalities. This makes unified management and coordinated scheduling of multi-vendor, multi-domain CATS systems difficult, hindering large-scale deployment. A unified NBI specification is therefore urgently needed. This document defines the standard for the Computing-Aware Traffic Steering (CATS) Northbound Interface (NBI), specifying the interaction protocols, data models, message formats, and procedures between the CATS system and upper-layer management platforms and application services. As CATS technology may be adopted in future fields including the industrial Internet, Internet of Vehicles, and smart cities, enterprises and users require a concise, user-friendly, and comprehensive set of invocation interfaces. The core objective of the NBI is to enable standardized exposure of capabilities such as CATS resource query, traffic steering policy selection, metric subscription, and fault alarming, supporting unified management and coordinated scheduling of multi- vendor, multi-domain CATS systems. Based on the IETF CATS framework, metric definitions, and use case requirements documents, this document focuses on the specifications of NBI functions, protocols, and data models, providing a unified standard for CATS northbound interoperability. |
| | HTTP/2 Server Behaviour Documentation and Operational Guidelines |
| |
|
This document establishes an informational framework for documenting expected server behaviour within the HTTP/2 protocol ecosystem, specifically referencing updates to RFC 9113. It outlines the consensus-building methodology required to transition from temporary operational practices to recognized international technical standards, incorporating structural regulatory frameworks from corporate filing benchmarks. |
| | Secured Digital Lifecycle Protocol (SDLP) RFC 0 |
| |
|
The Secured Digital Lifecycle Protocol (SDLP) defines a universal, lifecycle-governed framework for the creation, identity, transformation, distribution, and retirement of digital goods. |
| | EAP-AKA' Identity Fragmentation |
| |
|
This document updates EAP-AKA’ (RFC 9048) by defining the use of the AT_FRAGMENT mechanism, as defined in I-D.ietf-emu-pqc-eapaka, for fragmentation of the AT_IDENTITY attribute. This update allows a peer to convey a large network access identifier, such as a Subscription Concealed Identifier (SUCI), during the EAP-AKA’ identity exchange when the encoded identity is too large to fit reliably in a single EAP packet. This is intended to support large SUCI values produced by post-quantum cryptographic concealment schemes, while preserving the existing EAP-AKA’ challenge and key derivation procedures. |
| | A Fabric Coordination Layer (FCL) for High-Scale AI Training: Distributed Credit-Orbit Pacing (DCOP) and Global Token Ledger (GTL) |
| |
|
This document specifies a Fabric Coordination Layer (FCL) designed to stabilize data transmission in frontier-scale distributed computing fabrics. As AI training clusters scale to hundreds of thousands of accelerators and link speeds exceed 800 Gbps, traditional reactive congestion control mechanisms suffer from severe feedback-loop latency. By allocating transmission authority via a Global Token Ledger (GTL) and enforcing it through Distributed Credit-Orbit Pacing (DCOP), the FCL mitigates incast-driven buffer overflows and significantly reduces tail-latency variance, thereby maximizing Model Flops Utilization (MFU). |
| | OpenPGP Key Replacement |
| |
|
This document specifies a method in OpenPGP to suggest a replacement for an expired, revoked, or deprecated primary key. |
| |
|
| |
| | MSYNC |
| |
| | draft-bichot-msync-20.txt |
| | Date: |
28/05/2026 |
| | Authors: |
Sophie Bale, Remy Brebion, Guillaume Bichot |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the Multicast Synchronization (MSYNC) Protocol. MSYNC is intended to transfer video media objects over IP multicast. Although generic, MSYNC has been primarily designed for transporting HTTP adaptive streaming (HAS) objects including manifests/playlists and media segments (e.g., CMAF) according to a HAS protocol such as Apple HLS or MPEG DASH between a multicast sender and a multicast receiver. |
| | Intel Profile for Remote Attestation |
| |
|
This document is a profile of various IETF and TCG standards that support remote attestation. The profile supports Intel-specific adaptations and extensions for Evidence, Endorsements and Reference Values. This profile describes a particular application of CoRIM, EAT, CMW, TCG concise evidence, and TCG DICE specifications. In particular, CoRIM is extended to define measurement types that are unique to Intel and defines Reference Values types that support matching Evidence based on range and subset comparison. Multiple Evidence formats are anticipated, based on IETF and TCG specifications. Evidence formats are mapped to Reference Values expressions based on CoRIM and CoRIM extensions found in this profile. The Evidence to Reference Values mappings are either documented by industry specifications or by this profile. Reference Value Providers and Endorsers may use this profile to author mainifests containing Reference Values and Endorsements that require Intel profile support from parser implementations. Parser implementations can recognize the Intel profile by profile identifier values contained within attestation conceptual mmessages and from profile parameters to media types or profile specific content format identifiers. |
| | The Micro Agent Communication Protocol (uACP) |
| |
| | draft-mallick-muacp-03.txt |
| | Date: |
28/05/2026 |
| | Authors: |
Arnab Mallick, Indraveni Chebolu |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the Micro Agent Communication Protocol (µACP), a resource-efficient messaging protocol for autonomous agents operating on resource-constrained Edge and IoT devices (including Class 1 and Class 2 devices per [RFC7228]). Existing agent communication protocols assume unbounded computational and energy resources, µACP provides mechanisms for bounded resource consumption with deterministic memory bounds (8-byte header, explicitly delimited TLV region, and profile-dependent payload limits) and bounded processing time per message, while maintaining expressiveness sufficient for finite-state coordination patterns. The protocol defines four core message types, a fixed 64-bit header, TLV-based extensibility, and mandatory OSCORE security binding for operation in adversarial environments. |
| | IPv6 Wireless Access in Satellite Networks (IPWASN): Problem Statement and Use Cases |
| |
|
This document describes use cases and a problem statement for IPv6 Wireless Access in Satellite Networks (IPWASN). IPWASN aims at the IPv6-based wireless access in Non-Terrestrial Networks (NTNs), that is, satellite networks. It considers NTN characteristics such as dynamic topology, multi-hop communication over inter-satellite links, High-Altitude Platform Station (HAPS)-assisted relay paths, frequent handovers, variable link quality, and intermittent connectivity. Based on these characteristics, this document identifies key challenges in applying existing IPv6 protocols to NTN environments. It also analyzes the applicability of current IPv6 mechanisms and outlines requirements to support efficient data forwarding, Quality of Service (QoS), Segment Routing (SR)-based traffic engineering, and connectivity in satellite-based networks. |
| | MVPS Vantage Localization Feasibility under MPLS Path Camouflage |
| |
|
IP geolocation databases are known to be unreliable for network- path measurement purposes [Poese-2011]. Traceroute-based localization -- the practical alternative -- is further corrupted by invisible and opaque MPLS tunnels that suppress IP-TTL propagation, hiding intermediate hops and creating false direct links in the apparent network topology [Donnet-2012] [Vanaubel-2017] [Luttringer-2020]. This document formalises the interaction between MPLS path camouflage and the vantage-authentication problem of the Multi- Vantage Path Snapshot (MVPS) framework [I-D.melegassi-iab-mvps-architecture]. Three technical contributions are introduced. First, Lemma L-GEO-1 (RTT Localization Bound) establishes the feasible location set for any MVPS vantage given RTT measurements to three or more anchor points, under the assumption that all traversed tunnels are explicit or implicit in the Donnet taxonomy (TTL propagation active). Second, Lemma L-MPLS-1 (MPLS Camouflage Vulnerability) quantifies the correction term Delta_mpls that invisible and opaque tunnels introduce into the L-GEO-1 bound. For invisible tunnels this correction is unbounded without prior tunnel revelation; for opaque tunnels it is bounded by the hidden-hop count times the minimum per-hop propagation delay. Third, Theorem T-CAM-1 (MPLS-Aware Camouflage Detection) proves that an MVPS bundle from three or more vantage-to-anchor paths, combined with DPR/BRPR tunnel-revelation probing [Vanaubel-2017] or its TNT implementation [Luttringer-2020], detects MPLS- camouflaged vantage impersonation with probability at least 1 - epsilon under the existing MVPS chi-squared coherence test (Theorem 2 of the v4.0 proof catalogue [v4-proof]). Three explicit caveats (T-CAM-1.A on the i.i.d. assumption of the DKW bound, T-CAM-1.B on the empirical FAR Hypothesis H3 of [v4-proof], and T-CAM-1.C on revelation soundness under adversarial operators) qualify the bound in operational deployment. An auxiliary lemma L-GEO-1.1 (Anchor Geometry) characterises the necessary and sufficient angular distribution of anchors for L-GEO-1 to discriminate two candidate positions; this gives a deployable guideline for anchor selection. A new phase label MPLS_CAMOUFLAGE_SUSPECTED is introduced and added to the MVPS phase taxonomy alongside LOCATION_CONSISTENT, LOCATION_MARGINAL, CAMOUFLAGE_SUSPECTED, and SPOOFED_VANTAGE. Limitations explicitly disclosed include: the symmetric "RTT inflation" attack (Section 10.2), the PHP tunnel coverage gap when the adversary controls the ingress LER (Section 10.3), and the alignment between the geometric vantage minimum (N >= 3) and the Byzantine vantage minimum (N >= 3f+1, Section 10.4). All results are proved by discharging MVPS axioms A1..A5 against the structural assets of the Donnet MPLS taxonomy combined with the RTT-ellipsoid localization method. No new wire format is defined; no new codepoints are required. The document is informational. |
| | A Bound End-to-End Tunnel (BEET) mode for ESP |
| |
|
This document is an update to the Bound End-to-End Tunnel (BEET) mode for ESP in as described in [RFC7402]. It brings the description in alignment with the addition of BEET mode for IKEv2 without any processing changes as described in [RFC7402] |
| | TLS 1.3 Identity Module Trusted Exporter |
| |
|
The Transport Layer Security (TLS) 1.3 protocol supports external Pre-Shared Keys (PSKs), which are provisioned out of band. A PSK binder, included in the ClientHello message, is computed as an HMAC over a transcript hash using a key called the Finished External Key (FEK). For the "PSK with (EC)DHE" key exchange mode, where Diffie- Hellman is performed over either finite fields or elliptic curves, the Handshake Secret (HS) is computed from the (EC)DHE shared secret using HKDF-Extract with a key called the Derived Secret Key (DSK), which is derived from the PSK. A TLS identity module SHOULD be used to protect procedures involving keys bound to the PSK, such as the FEK or the DSK. TLS defines keying material exporters, which rely on secrets produced during the handshake protocol. This draft introduces an Exporter Trusted Key (ETK), which is securely stored and used within a TLS identity module. The ETK transforms exporter secrets into trusted values that cannot be recovered by TLS software. A trusted exporter is similar to the legacy TLS exporter, but it uses an additional trusted secret. |
| | PortCast: A JSON-Based Interchange Format and Sync API for Portable Podcast Listener Data |
| |
|
PortCast defines an open JSON-based interchange format, and an optional HTTPS synchronisation API, for moving a podcast listener's data -- subscriptions, listening history, playback position, queue, bookmarks, and per-feed preferences -- between independent podcast applications without a central service. It builds on identifiers already present in RSS (item GUID, feed URL) and the Podcast Namespace (podcast:guid) so that implementations can interoperate without inventing a new identity namespace. This document specifies the file format (v0.1) and a federated synchronisation API (v0.2) that reuses the same data model. |
| | MVPS Proof Envelope: Tamper-Evident Binding of Theorem Catalogues,Validators,and Numerical Receipts,with an Optional Post-Quantum Profile |
| |
|
The Multi-Vantage Path Snapshot (MVPS) family specifies coherence detection algebra [MVPS-V4] and trust profiles that authenticate vantage reports [I-D.melegassi-santos-ippm-mvps-cwt]. The mathematical truth of the MVPS theorems is established off the wire, in companion proof documents and machine validators that emit numerical receipts. Without a normative binding layer, a consumer cannot verify WHICH theorem catalogue, proof revision, validator script, or receipt artifact a given deployment claim relies on, nor detect silent substitution of those artifacts. This document specifies the MVPS Proof Envelope: a canonicalized [RFC8785] manifest that lists theorem identifiers and the SHA-256 digests of the companion proof documents, validator scripts, and numerical receipts that support them, aggregated under a Merkle root [RFC9162] and anchored by the operator-epoch and witness-cosignature machinery of [I-D.melegassi-santos-ippm-mvps-cwt]. Verification of the envelope is tamper-evident under standard hash and signature assumptions (Theorem T-BIND-1) and traceable (Theorem T-TRACE-1). The envelope does NOT cryptographically prove the listed theorems; a proved theorem is a mathematical fact, not subject to cryptanalysis. The envelope makes the CHOICE OF PROOF ARTIFACTS tamper-evident. An OPTIONAL Post-Quantum Protection profile MAY replace the Ed25519 anchor signatures with ML-DSA-65 [FIPS204] while leaving the per-snapshot HMAC-SHA256 hot path unchanged (Theorem T-PQ-MIG-1). Security Considerations document a finite Grover-halved floor and explicitly defer any claim of perpetual security. Numerical receipts are regenerated by scripts/validate_proof_envelope.py (11/11 PASS) and stored in evidence/proof_envelope_receipt.json. Companion proofs are in [PROOF-ENVELOPE-PROOF]. |
| | MVPS Detection-Latency Reconciliation: A Unified Onset-Phase Lemma for Multi-Vantage Coherence Profiles |
| |
|
Several Multi-Vantage Path Snapshot (MVPS) profiles state a detection-latency bound as a function of the detection multiplier M and the control-tick period T_tick. The bandwidth-efficient profile [I-D.melegassi-mvps-incremental-be] states it as M*T_tick; the Coherence-BFD [I-D.melegassi-coherence-bfd] and DDoS-Resilience [I-D.melegassi-mvps-ddos-resilience] profiles state it as (M-1)*T_tick. A reviewer reading two profiles in parallel observes a one-tick disagreement. This document shows the disagreement is not a mathematical error but an unstated difference in the ONSET-PHASE convention, and closes it with a single Unified Detection-Latency Lemma (L_DL): |
| | The MVPS Adversarial-Audit Methodology: A Reproducible Discipline for Measurement-Security Internet-Drafts |
| |
|
The Multi-Vantage Path Snapshot (MVPS) family of Internet-Drafts is built on a single discipline rather than a single algorithm. This document records that discipline as a set of nine machine-checkable meta-invariants (M-1..M-9): every claim is classified as a Theorem, a Design, or a Conjecture; every Theorem traces to a closed basis of twelve imported results (I1..I12); every Conjecture carries a four-field falsification protocol; every draft ships a proof/validator/receipt trio; and an adversarial-audit ledger of eight rounds and forty-four findings is kept, each finding either defended or reclassified. The contribution is offered to the research community as a template that other measurement-security efforts MAY adopt, independent of MVPS's specific mathematics. This document defines no protocol, introduces no wire format, and requests no IANA action. Its claims are themselves validated: scripts/validate_methodology_discipline.py returns exit 0 over the eleven discipline checks and writes evidence/methodology_discipline_receipt.json. |
| | The MVPS Operational Log Format: Append-Only,Hash-Chained,Externally-Anchored Audit Logs |
| |
|
Multi-Vantage Path Snapshot (MVPS) deployments run in critical environments where the operational record must be auditable: an investigator, regulator, or independent witness must be able to detect any after-the-fact alteration of what the system observed and did. This document specifies the MVPS operational log format: an append-only stream of structured records, each cryptographically chained to its predecessor, with completeness guaranteed by an external anchor reusing the Coherent-Witness Trust (CWT) checkpoint and the MVPS Proof Envelope. The format guarantees that recorded events cannot be silently edited, reordered, or interior-deleted, and -- once a head is anchored -- that the exact log prefix is pinned and tail truncation is exposed. The document is explicit about the limits: a bare hash chain cannot prove its own completeness (an anchor is REQUIRED); the chain is binding, not confidential. Every property is validated by scripts/validate_logging_format.py (8/8 PASS, exit 0) and recorded in evidence/logging_format_receipt.json. |
| | MVPS Maritime and Tactical-Edge Profile: Coherence Monitoring under Disconnected,Intermittent,Limited Connectivity and GNSS-Denied Holdover |
| |
|
This document defines a deployment profile of Multi-Vantage Path Snapshot (MVPS) for fleets and fixed installations operating in Disconnected, Intermittent, Limited (DIL) environments where Global Navigation Satellite System (GNSS) time may be denied -- for example naval and maritime critical infrastructure and other tactical-edge networks. The profile is DEFENSIVE: it concerns detection of coherence anomalies in the network and timing telemetry (cyber intrusion, comms tampering, and positioning/timing (PNT) spoofing). It defines no navigation, targeting, or kinetic function. MVPS promotes its detection theorems to any surface satisfying its five axioms. At sea only one axiom is at risk: A1, the bounded joint-clock-skew requirement, because oscillators drift under GNSS denial and links are intermittent. This document proves A1 still holds on an enlarged coherence tick under explicit datasheet-grounded budgets, after which the core theorems inherit verbatim via the MVPS Architecture-Invariance Theorem. The closed-form result shows the binding constraint is store-and-forward latency, not clock drift. All properties are validated by scripts/validate_maritime_edge.py (7/7 PASS, exit 0) and recorded in evidence/maritime_edge_receipt.json. |
| | MVPS Terrestrial Mobile and Vehicular Profile: Coherence Monitoring under Cellular Handover and Radio-Access Scheduling |
| |
|
This document defines the terrestrial member of the Multi-Vantage Path Snapshot (MVPS) domain trio (space, sea, land). It targets vantages that move on land -- vehicles, trains, drones -- connected through cellular (5G/LTE) radio access, where the bounded joint clock-skew axiom A1 is stressed not by clock drift (GNSS is normally available) but by handover between base stations and slot-based scheduling jitter. The profile is DEFENSIVE: it concerns detection of coherence anomalies (intrusion, communications tampering, rogue base stations). It defines no navigation, targeting, or kinetic function. The document proves A1 holds on the deployment tick under explicit cellular-timing budgets, gives a closed-form maximum handover interruption, proves Doppler is dominated at terrestrial speeds, and inherits the core theorems via the MVPS Architecture-Invariance Theorem. All properties are validated by scripts/validate_terrestrial_mobile.py (7/7 PASS, exit 0) and recorded in evidence/terrestrial_mobile_receipt.json. |
| | A Forward-Compatible Extension and Capability-Negotiation Mechanism for the MVPS Bundle Format |
| |
|
This document defines a forward-compatible extension point for the Multi-Vantage Path Synchrony (MVPS) bundle format. The base format already provides a schema version, a path-fingerprint version prefix, and an IANA "MVPS Bundle Capability Flags" registry, but its serialization is closed to unknown fields. This document adds a single, typed, namespaced "extensions" object and a processing rule (ignore-but-preserve), and specifies how extensions interact with the canonical hash and the MVPS Proof Envelope. The mechanism is designed so that an extension can never become a tamper vector and can never alter the core coherence detector: the detection statistic D^2 is, by construction, a function of the core bundle only. Every property in this document is backed by a machine-checkable numerical receipt. |
| | Exporting MVPS Coherence Events over Standard Telemetry Channels (syslog,IPFIX,YANG-Push) |
| |
|
Multi-Vantage Path Snapshot (MVPS) deployments raise coherence events -- ALARM, BYZANTINE EVENT, and phase transitions such as MPLS_CAMOUFLAGE_SUSPECTED -- that operators must ingest into existing monitoring systems (Network Management Systems, SIEMs, time-series collectors). This document specifies a single canonical MVPS event object and three NORMATIVE, lossless mappings of that object onto standard, vendor-neutral telemetry channels: structured syslog (RFC 5424), IP Flow Information Export (IPFIX, RFC 7011), and YANG-Push subscribed notifications (RFC 8639, RFC 8641) carried over NETCONF or RESTCONF. A consumer MAY ingest MVPS events from any one channel without loss of the fields required to reproduce the alarm decision, and the same stable event identifier is carried on every channel so that deduplication across channels is consistent. This document specifies CHANNELS, not products. No monitoring product is named normatively; a non-normative companion guide demonstrates ingestion into one open-source system. Every mapping property is validated by scripts/validate_telemetry_export.py (8/8 PASS, exit 0) and recorded in evidence/telemetry_export_receipt.json. |
| | A YANG Data Model for Multi-Vantage Path Snapshots (MVPS) |
| |
|
This document defines a YANG data model for Multi-Vantage Path Snapshots (MVPS): vendor-neutral, multi-vantage enriched traceroute observations whose reporting model is aligned with RFC 9198 (Advanced Unidirectional Route Assessment). The model is the normative publication of the MVPS bundle as a YANG module and is the subtree that the MVPS telemetry-export specification subscribes to over YANG-Push. The module is CORE-neutral: it carries measurement facts only. It makes no performance, scoring, or detection claim. All properties stated in this document are structural and are backed by a machine-checkable receipt. |
| | Context Relay Protocol (CRP) -- Safety Policy Directive Language Specification |
| |
|
This document specifies the CRP-Safety-Policy directive language — a declarative policy syntax for expressing AI safety requirements at the transport layer. The directive language is modelled after HTTP Content-Security-Policy (CSP) as defined in W3C CSP Level 3. It allows clients to declare what AI output characteristics are trusted, what risk levels trigger enforcement actions, and where violations should be reported. The CRP gateway enforces these policies on every AI response before delivery to the client. This document defines the complete directive grammar, enforcement semantics, violation reporting, and policy inheritance in multi-agent chains. |
| |
|
| |
| | JMAP Object Metadata |
| |
|
This document defines an extension to the JSON Meta Application Protocol (JMAP) that lets clients and servers attach metadata to existing JMAP data types. Each opted-in data type gains two new properties, metadata and privateMetadata, whose values are objects keyed by _namespace identifier_. A namespace identifier is either a name registered with IANA or a domain name controlled by the vendor providing the namespace; the latter allows vendors and applications to extend the metadata schema without prior coordination. Because metadata is carried as a property on the related object, clients use the existing /get, /set, /changes, and /query methods to read, modify, and synchronize it. |
| | Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP) |
| |
|
Enhanced VPNs aim to deliver VPN services with enhanced characteristics, such as guaranteed resources, latency, jitter, etc., so as to support customers requirements for connectivity services with these enhanced characteristics. Enhanced VPN requires integration between the overlay VPN connectivity and the characteristics provided by the underlay network. A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services. In some network scenarios, each NRP can be associated with a unique logical network topology. This document describes a mechanism to build the SR-based NRPs using IS-IS Multi-Topology together with other well-defined IS-IS extensions. |
| | Module-Lattice Key Exchange in SSH |
| |
|
This document defines pure post-quantum key exchange methods based on Module-lattice post-quantum key encapsulation schemes for use in the SSH Transport Layer Protocol. |
| | DNS for AI Discovery |
| |
|
The document standardizes an approach for publishing AI agents in the Domain Name System (DNS) so that other agents can discover them. Discovery is then initiated based on one of three generic use cases, in increasing computational and latency cost: (1) the requestor knows both the organization and agent (2) the requestor knows the organization that provides a capability, but not the specific agent (3) the requestor knows the required capability, but not the organization or agent. Of these use cases only (1) and (2) are in scope for this document, although (3) can be derived from this specification. DNS for AI Discovery (DNS-AID) is designed so that, once a client has learned an organization's agents, subsequent transactions can utilize the first use case with the benefit of cacheable connectivity information that is learnable as an agentic skill. The mechanism uses Service Binding (SVCB) records for connectivity information and key meta data, a well known entry point using DNS-Based Service Discovery (DNS-SD) labels into an organization's agent index, and optionally DNS Security Extensions (DNSSEC) and DNS-Based Authentication of Named Entities (DANE) TLSA records for trust and security. DNS-AID provides consumers of agent services with a direct connection method for agentic workloads not mediated by a third party. Organizations can use the same approach across public and private networks networks, providing consistency and common operational models, including publishing agents that are hosted in service provider domains. This document introduces no new resource record types, opcodes, or response codes. |
| | The Sovereign AI Horizontal Memory (SAIHM) Protocol |
| |
|
This document defines the Sovereign AI Horizontal Memory (SAIHM) protocol, a memory layer for AI agents that supports post-quantum identity binding, public-chain audit anchoring, per-cell encryption with wallet-derived keys, revocable sharing contracts, and cryptographic right-to-erasure aligned with Article 17 of EU Regulation 2016/679 (GDPR). SAIHM is the memory-layer protocol companion to the Model Context Protocol (MCP). MCP standardizes how AI agents reach tools and contextual data sources; SAIHM standardizes how AI agents persist, share, and erase memory across sessions, models, and vendors. |
| | MVPS Performance-Security Coupling Profile: Joint Volume- Independence and Authentication Guarantees for Coherence-BFD with Coherent-Witness Trust (CWT) |
| |
|
This document specifies the MVPS Performance-Security Coupling Profile, a Profile-of-Profiles binding three previously specified profiles into a single deployable contract: o MVPS Coherent-Witness Trust (CWT) [I-D.melegassi-santos-ippm-mvps-cwt], o Coherence-BFD [I-D.melegassi-coherence-bfd], and o MVPS DDoS Resilience [I-D.melegassi-mvps-ddos-resilience]. Each composed profile proves its own theorems and reports its own measured numbers under its own scale assumption. When deployed together, those scale assumptions diverge by 1-2 orders of magnitude and create five composition holes: a numerical cost- rescaling gap, a double replay-counter rule, an under-specified key-derivation step, an insider verification-DoS gap, and a joint Byzantine-at-limit / collector-split-view gap. This profile closes all five with three theorems: T-JCOST-1. Closed-form joint broker CPU cost as a function of (N, T_tick, q, bundle_period); two-path decomposition (CWT path + Coherence-BFD path) avoids double-count; numerical receipt at four scale points. T-VDOS-1. Per-vantage rate-limit at NIC/XDP fast-path bounds the attacked-broker CPU by a near-constant factor (rate_limit_factor + flood * c_xdp / c_path) instead of the linear blow-up of the unprotected case. T-RC-1. Acceptance is the AND of the BFD sequence rule and the CWT counter rule; rejection cases are enumerated. A normative HKDF info-string for cross-profile key separation closes the under-specification of CWT Section 13. The dual-mode aggregation values (D_minimax, D_max) defined in DDoS-Resilience Section 7.2 are bound INTO the cosigned checkpoint of CWT Section 8.2, closing the joint Byzantine + split-view gap. The profile inherits the full v4.0 theorem catalogue and is conformant to the MVPS Architecture Invariance Theorem [I-D.melegassi-iab-mvps-architecture]. Full proofs are recorded in [PERFSEC-PROOF]; numerical receipts are in evidence/perfsec_joint_cost_receipt.json and evidence/perfsec_verification_dos_receipt.json; the validator scripts/validate_perfsec_coupling.py returns 12/12 PASS. |
| | OAuth 2.0 Insufficient Claims Challenge |
| |
|
This specification defines an OAuth 2.0 challenge mechanism by which an Authorization Server or Protected Resource signals that a credential presented by a Client is otherwise acceptable but lacks claims required to fulfill the request. A new error code, insufficient_claims, together with a required_claims parameter that enumerates the missing claims, lets the recipient signal what is needed. The same challenge is used in Token Endpoint error responses, in Bearer authentication challenges at Protected Resources, and (optionally) in OAuth 2.0 Protected Resource Metadata. The challenge is intentionally decoupled from how the Client responds. For back-channel re-issuance grants (OAuth 2.0 Token Exchange and Refresh Token), a Client uses the requested_claims Token Endpoint request parameter defined here. For grants that may require end-user interaction (authorization_code, device_code, CIBA), a Client uses an applicable front-channel claims request mechanism, such as the OpenID Connect claims request parameter. A motivating use case is just-in-time account provisioning by a Resource Authorization Server receiving an identity assertion under the Identity Assertion Authorization Grant. |
| | MVPS AI-Coherence Extension: Semantic,Byzantine,and Infrastructure-Cognitive Coherence for AI-Serving Network Deployments |
| |
|
The Multi-Vantage Path Synchrony (MVPS) framework (draft-melegassi-ippm-mvps-bundle-00) defines a three-axis coherence measurement framework for network observability. Its informational axis C_2 uses Jensen-Shannon Divergence over a discrete label alphabet, and its topological axis C_3 uses Jaccard similarity on touched-object sets. Both constructions are optimal when the alphabet carries no metric structure. This document extends the MVPS framework to three domains where the metric structure of the observation space is non-trivial and operationally significant: (A) Semantic coherence for language-model serving: replaces C_2 with the 2-Wasserstein distance on embedding-weighted token measures (C_2^W2), replaces C_3 with Centered Kernel Alignment on attention matrices (C_3^CKA), introduces a fourth axis C_4 (falsifiability coherence via perturbation stability), and a lateral phase label COHERENT_BUT_FALSE (CBF) for hallucination consensus detection. (B) Byzantine-robust coherence: replaces the arithmetic-mean centroid with the geometric median (C_2^gm), introduces minimax coherence C^mm(f), a minimum-covariance-determinant phase distance Phi_D^byz, a fifth phase label SUSPECTED_BYZANTINE, and a cascade-time model tau_C for detection-window quantification under BGP hijack. (C) Infrastructure-Cognitive coupling: defines the joint coherence vector z(t) in [0,1]^6, the cross-surface correlation matrix R_cross, the drift transfer function from network routing perturbations to semantic drift, and a five-phase IC phase diagram that detects coupled failure modes invisible to either standalone monitor. All constructions are proved or formally stated to the same evidential standard as the MVPS math companion (v1.1), with explicit status labels (THEOREM / CONJECTURE / HYPOTHESIS / DEFINITION) and honest caveats for each claim. NOTE ON DATA PROVENANCE. Worked examples in Sections 9 and 16 use synthetic data generated under controlled conditions. Validation against operational LM-serving traces or BGP monitoring feeds is identified as required future work. EVIDENCE UPDATE (v5.0 unified proof, 2026-05-22). Three real-data experiments have been performed since this draft was first produced; their results are summarised here for the reviewer's convenience. Full disclosure with SHA-256 receipts is in docs/MVPS_V5_UNIFIED_PROOF.txt of the reference implementation bundle (available on request from the author; a public reference implementation is planned but not yet released). * R5 (T_CBF / CONJ-A, semantic axis). 200 LM calls against a local Ollama backend (qwen2.5:3b, 3.1B Q4_K_M), 10 BAU + 10 CBF prompts x 5 vantages x 2 perturbations. Mann- Whitney U on CBF vs BAU: D^2 AUC = 0.900, CBF_score AUC = 0.800; C_2, C_3, C_4 all collapse from mean 1.000 (BAU) to mean 0.41/0.26/0.35 (CBF), yielding AUC = 0.000 (anti- direction = perfect separator via 1 - metric). This is empirical real-world evidence for the signature CBF_signal := { D^2 high, C_2 low, C_4 low } as a sufficient indicator of coherent fabrication. CAVEAT (generalisation). R5 was measured on ONE model family (qwen2.5:3b, n_models = 1, n_calls = 200, single prompt domain). CONJ-A is therefore established empirically on a single point in (model, prompt-domain, decoding-temperature) space. Multi-model and multi- domain replication is open question AI9.7 (Section 26); the protocol required for CONJ-A to be considered broadly supported is n_models >= 3 (mixing open- and closed-weight families), n_calls >= 1000 per (model, domain) cell, and >= 2 prompt domains. * R6 (T_DDoS, BGP routing axis). RIPE Stat BGP updates, 5 anycast DNS prefixes (Google, Cloudflare, Quad9, OpenDNS, Level3), 30 days, baseline counts spanning 9x. Alarms fire on RELATIVE D^2 spike (peak-to-baseline ratio up to 14.2x for Google DNS) and NOT on absolute volume: Cloudflare 0 alarms despite high baseline; Quad9 + OpenDNS alarm despite low baseline. * R7 (tau_C SIR cascade, Section 15). 12 BGP alarm events retrieved at day granularity (R2 + R6 union). All 12 events localise within <= 2 days (mean burst width 1.33 days), confirming the SIR macroscopic prediction. Three of the 12 events were retrieved at minute resolution from RIPE Stat; Gaussian pulse fit yields tau_C in [11.8, 29.4] minutes, consistent with the BGP propagation literature. These results are reproducible via scripts/v5_numerical_receipts.py in the reference implementation and do not change any normative construction of this draft; they validate empirically what was previously labelled CONJECTURE. |
| |
|
| |
| | BGP Next-next Hop Nodes |
| |
|
BGP speakers learn their next hop addresses for NLRI in RFC 4271 in the NEXT_HOP field and in RFC 4760 in the "Network Address of Next Hop" field. Under certain circumstances, it might be desirable for a BGP speaker to know both the next hops and the next-next hops of NLRI to make optimal forwarding decisions. One such example is global load balancing (GLB) in a Clos network. Draft-ietf-idr-nhc defines the "Next Hop Dependent Characteristics Attribute" (NHC) which allows a BGP speaker to signal the forwarding characteristics associated with a given next hop. This document defines a new NHC characteristic, the Next-next Hop Nodes (NNHN) characteristic, which can be used to advertise the next- next hop nodes associated with a given next hop. |
| | SMTP Service Extension for Client Identity |
| |
|
Multi-Factor Authentication has rapidly become a driving requirement for any internet based technology that requires authentication. While a large number of initiatives are active for providing solutions to this requirement for Web Browser based applications that can generally support real time human interaction for providing a secondary method of identification, legacy protocols such as SMTP authentication have not yet been revised to provide such support despite being a high-risk target for business email compromise, possibly as a result of authenticated SMTP activity generally expecting to be non-interactive in nature outside of Webmail logins. This document defines an extension to the SMTP service protocol called "CLIENTID" that a SMTP client can provide an additional unique identification token prior to standard credentials authentication that the server may then apply as an identify verification method in a similar manner to other Multi-Factor authentication techniques. |
| | IMAP Service Extension for Client Identity |
| |
|
Multi-Factor Authentication has rapidly become a driving requirement for any internet based technology that requires authentication. While a large number of initiatives are active for providing solutions to this requirement for Web Browser based applications that can generally support real time human interaction for providing a secondary method of identification, legacy protocols such as [IMAP] have not yet been revised to provide such support despite being a high-risk target for business email compromise, possibly as a result of [IMAP] activity generally expecting to be non-interactive in nature outside of Webmail logins. This document defines an extension to the [IMAP] service protocol called "CLIENTID" that an [IMAP] client can provide an additional unique identification token prior to standard credentials authentication that the server may then apply as an identity verification method in a similar manner to other Multi-Factor authentication techniques. |
| | ASN Prefix-based Addressing for IPv6 |
| |
|
This document describes a method and policy for ASN prefix-based addressing for IPv6. NOTE: The author(s) have decided to forgo further work on this document. The ideas expressed herein have been largely deemed unnecessary, redundant, impractical, or undesirable. A Criticism section details this reasoning for posterity. |
| | DELEG Extensions for Secure Transports |
| |
|
The DELEG base protocol allows a DNS zone operator to specify servers to be used when delegating zones to other DNS nameservers. This document extends the base protocol to allow zone operators to specify secure transports for those delegations. |
| | SNAP: Simple Native Archive Protocol |
| |
|
SNAP (Simple Native Archive Protocol) defines a minimal, self- describing backup object encoded as a single JSON document, modeled in YANG [RFC7950] and encoded per [RFC7951]. A SNAP object contains a manifest of files with per-file cryptographic hashes, integrity- verified metadata, and a compressed binary payload -- all within one atomic, transport-agnostic JSON document. Any agent capable of parsing JSON and applying standard decompression can produce or restore a SNAP backup without proprietary tooling, side-channel metadata, or multi-phase handshakes. This document defines the YANG module "snap", its JSON encoding, integrity verification procedure, bindings to common transports, and its role as the atomic transport substrate for the Multi-Vantage Path State (MVPS) family of Internet-Drafts. When a SNAP Object carries an MVPS Bundle [I-D.melegassi-ippm-mvps-bundle], the canonical-form determinism of SNAP (Theorem 1 of this document) composes with the MVPS Architecture axioms A1..A5 [I-D.melegassi-iab-mvps-architecture] to inherit the full coherence algebra of [MVPS-v4] (Theorems 1, 2, 3, 3', 4, 5, 9 and Stein's Lemma [Stein52] [CoverThomas2006]) without alteration. |
| | MVPS Architecture: Specification Conformance for the Multi-Vantage Path-Coherence Drafts |
| |
|
This document specifies the abstract Multi-Vantage Path- coherence Specification (MVPS) as a surface-independent algebraic structure on a bounded simplex. Five structural axioms (MVPS-A1 through MVPS-A5) are stated; the Invariance Theorem establishes that any architecture satisfying the five axioms inherits, verbatim, the v4.0 theorem catalogue of MVPS (Theorems 1, 2, 3, 3', 4, 5, 9, the unified detection- latency lemma L_DL, and Stein's Lemma for N-vantage joint error exponents). This document is the structural roof of the MVPS family. It explains, normatively and in a small number of axioms, why the seven MVPS Internet-Drafts ([I-D.melegassi-ippm- mvps-bundle] through [I-D.melegassi-ippm-mvps-orbital- coherence]) are seven instantiations of the same specification rather than seven independent specifications. Each of the seven existing drafts is shown to satisfy the five axioms (Section 6.1); anticipated instantiations (kernel, dataplane, datacenter, IoT, post-quantum link) are catalogued as design targets; protocols that violate one or more axioms (BGP, BFD, DNS, TCP retransmission) are identified as non-conformant, and the structural reason for their tau_sampling-bound reactive latency floor under the Planetary Coherence Floor ([I-D.melegassi-iab-mvps-planetary- floor]) is named. This document is informational. It follows the IETF architecture-document pattern of [RFC1958], [RFC3439], [RFC1633], [RFC2475], [RFC2775], [RFC6973], and [RFC7258]. It standardises no codepoints, defines no wire format, and introduces no RFC-2119 keywords beyond the conventions section. Its sole content is the abstract specification, the axiom set, the Invariance Theorem, and the conformance catalogue. The mathematical device introduced is SPECIFICATION CONFORMANCE: an architecture A is MVPS-conformant if and only if its 5-tuple (V_A, B_A, (C_A, H_A), D^2_A, Pub_A) satisfies A1..A5. Conformance is strictly weaker than a categorical functor between surfaces (which the v4.0 mathematical existence proof explicitly disclaims) but strictly stronger than parallel construction: conformant architectures inherit the v4.0 theorem catalogue by mechanical substitution. No morphisms between surfaces are required. |
| | Planetary Coherence Floor: Composition Theorem for Reactive Latency in Multi-Vantage Network Infrastructure |
| |
|
This document specifies the Planetary Coherence Floor (PCF), a composition theorem that bounds the reactive latency of any planet-scale detect-and-react architecture by the maximum of five physically and algorithmically named floors: a Lorentzian causal floor (speed-of-light through the actual signalling media), a sampling floor (the unified detection-latency Lemma L_DL of the MVPS family), an information floor (Stein's Lemma applied to N-vantage joint observation), a consensus floor (the geometric-median Byzantine bias bound), and a coupling floor (joint Mahalanobis across coupled surfaces). Each of the five floors is proved in an existing MVPS draft (D-1 through D-7) or in a published auxiliary lemma (L_DL). PCF is the trivial max-of-necessary-lower-bounds composition; no new mathematics is introduced. Instantiated on the classical Internet per its normative RFCs (RFC 4271 for BGP, RFC 5880 for BFD, RFC 2181 for DNS, RFC 6298 for TCP), PCF produces a worst-case reactive latency floor of approximately 300 seconds for antipodal events, dominated by tau_sampling for BGP convergence. Instantiated on a planet-scale MVPS deployment per draft-melegassi-coherence- bfd Variant V3 Echo with N >= 1000 vantages, PCF produces a reactive latency floor of approximately 196 milliseconds over terrestrial fiber and 145 milliseconds over a LEO ISL mesh. Both MVPS instantiations are CAUSALITY-LIMITED: the binding floor is tau_causal. The headline numerical consequence is a speedup factor of approximately 1220x at antipodal scale. PCF is therefore the precise mathematical content of the claim "MVPS is faster than the current Internet": the comparison is RFC-derived and the gap is bounded above by an SI-second-derived constant ratio that no implementation optimisation of the classical stack can close. This document is informational and intentionally minimal. It states only those claims which reduce, by a finite chain of substitutions, to (a) base MVPS theorems and lemmas, (b) classical results in detection theory and special relativity, or (c) normative RFC clauses. |
| | Incremental Bandwidth-Efficient Multi-Vantage Path Synchrony (BE-MVPS): Cell-Partitioned Coherence with epsilon-Gated Sherman-Morrison Updates |
| |
|
This document specifies BE-MVPS (Bandwidth-Efficient MVPS), an incremental execution layer for the Multi-Vantage Path Synchrony (MVPS) framework that trades a constant-factor increase in broker-side CPU for an order-of-magnitude decrease in vantage-to- broker bandwidth. Where MVPS as defined in [I-D.melegassi-ippm-mvps-bundle] performs a dense recomputation of the coherence vector C = (C_1, C_2, C_3) at every tick over the full population of N observers, BE-MVPS partitions the observer set into k coherence cells, gates per-observer state transmission by a local epsilon threshold, performs Sherman-Morrison incremental updates of the Mahalanobis distance D^2, and detects Byzantine vantages via a cell-aware minimax estimator whose breakdown point is shown (Theorem 7) to be exactly f/k where f is the adversarial vantage fraction. The earlier informal label "Fast Incremental MVPS (FMVPS)" is superseded by BE-MVPS in this document; the rename and its rationale are recorded in the ERRATUM block below and proved formally in Theorem T_BE of the v5.0 unified proof. The IETF identifier of this document is draft-melegassi-mvps-incremental-be. Nine theorems formalise the framework: the partition existence theorem (Theorem 2), the cell-equivalence bound (Theorem 3), the gating information-loss bound (Theorem 4), the Sherman-Morrison- Woodbury incremental D^2 update (Theorem 5), strong eventual consistency of the CRDT merge (Theorem 6), the cell-aware Byzantine breakdown point (Theorem 7), the C_4 perturbation non-incrementality theorem (Theorem 8), and the detection latency lower bound for sub-tick variants (Theorem 9). Section 13 introduces five BFD-inspired execution variants and reports wall-clock benchmark results: variant V3 (Echo) achieves tau_detect = 55 ms, a 1091x reduction relative to the baseline tick scale. Wall-clock benchmarks on N = 1000 to 10 000 vantages confirm that BE-MVPS reduces edge-to-broker bandwidth by a factor of 25x while preserving detection completeness for all canonical scenarios except adversary fractions below 1/k. This document is a companion to [I-D.melegassi-ippm-mvps-bundle] and to the AI-coherence extension [I-D.melegassi-mvps-ai-coherence]. The algebra is preserved verbatim; only the execution model changes. NOTE ON DATA PROVENANCE. All wall-clock and bandwidth numbers in this document are obtained from synthetic simulations (scripts/benchmark_fmvps_vs_ml.py and scripts/benchmark_coherence_bfd.py) under controlled conditions. Validation against operational data (RIPE Atlas, CAIDA, or commercial operator traces) is identified as required future work before publication outside the Experimental track. A REFERENCE IMPLEMENTATION of the cell-aware minimax detector (Theorem 7) is provided in pure Python at . See reference-impl/README.md. ERRATUM (v5.0 unified proof, Theorem T_BE -- applied to this -00 document at submission time, not deferred to -01). Earlier drafts and internal material used the label "Fast Incremental MVPS (FMVPS)". Wall-clock measurements (scripts/benchmark_fmvps_vs_ml.py) and the T_BE theorem of docs/MVPS_V5_UNIFIED_PROOF.txt show that, at N = 1000 to 10 000 vantages and d = 3, this algorithm is on average approximately TWO times slower in per-tick CPU than MVPS-classic (Welford on a dense covariance), while sending approximately TWENTY FIVE times fewer bytes from each vantage to the broker. The genuine advantage of the algorithm specified here is therefore BANDWIDTH efficiency under epsilon-gating, not CPU latency. This document is therefore identified at submission time as draft- melegassi-mvps-incremental-be (Bandwidth-Efficient), with the "Fast" label dropped from both filename and title. The earlier name "draft- melegassi-mvps-fast-incremental" was never submitted to the IETF Datatracker; the BE name is the first authoritative IETF identifier. Theorem T_BE of the unified proof gives the crossover condition |
| | Multi-Vantage Coherence Detection: Closed-Form Lead-Time on Rank-Low Propagating Signals (MVPS Profile) |
| |
|
This document defines a Coherence Lead-Time Profile for the Multi- Vantage Path Synchrony (MVPS) framework [I-D.melegassi-ippm-mvps-bundle]. It states three LEMMAS (L_ZD.1', L_ZD.2', L_ZD.3) that bound, in closed form, the expected lead-time of the multi-vantage Mahalanobis detector D^2 over the per-vantage max-z detector under three canonical signal regimes: linear growth, exponential (worm-style) growth, and the degenerate sparse-direction case in which the multi-vantage detector loses its advantage. The operational claim is the closed form |
| | Multi-Vantage Path Snapshot Profile for Satellite-Segment Paths: Mapping and N-Vantage Error-Exponent Scaling |
| |
|
This document defines a mapping from the Multi-Vantage Path Snapshot (MVPS) framework [I-D.melegassi-ippm-mvps-bundle] onto network paths that traverse satellite constellations and other orbital segments. The mapping reuses, without alteration, the bundle wire format, the coherence axes (C_1, C_2, C_3), the Hamiltonian H, and the Mahalanobis detection statistic D^2 of base MVPS. Two adaptations are introduced: (1) The causal lower bound C_1 admits a vacuum propagation speed on space-segment legs and fiber refractive index on terrestrial legs. (2) The topological coherence C_3 admits a predicted-topology component derived from publicly available Two-Line Element (TLE) sets via the SGP4 propagator [SGP4], in addition to the actual-topology component of base MVPS. This document is informational and intentionally minimal. It states only those claims which reduce, by a finite chain of substitutions, to either (a) base MVPS theorems, or (b) classical results in special relativity and orbital mechanics. Numeric thresholds, phase-centroid values, detection latency claims, bearing-estimation accuracy, and any "X% improvement" claims are NOT made. Such results require experimental validation and are listed as Open Problems. OPERATIONAL PREREQUISITE. The predicted-topology component C_3^pred is exercised only when per-hop satellite identity is observable at the vantage (Hypothesis H-5). No major LEO operator currently publishes such mappings; in their absence the framework degenerates to a single-axis (C_1) detector. A path-identity exposure protocol is a candidate companion specification (Open Problem OP-2). MATHEMATICAL CORE. Under conditional independence of vantages, the joint missed-detection error exponent equals the sum of per-vantage Kullback-Leibler divergences (Appendix A; Stein's Lemma plus KL chain rule). The non-trivial multi-vantage gain is information- theoretic: for attack classes where a single vantage has zero divergence, only the joint detector achieves beta below 1 - alpha. The document is intended for use by network operators of LEO ground segments, by national telecommunications regulators considering independent verification of foreign-operated constellation traffic over their territory, and by the IETF community. |
| | EAT Attestation Results |
| |
| | draft-ietf-rats-ear-04.txt |
| | Date: |
26/05/2026 |
| | Authors: |
Thomas Fossati, Eric Voit, Sergei Trofimov, Henk Birkholz |
| | Working Group: |
Remote ATtestation ProcedureS (rats) |
|
This document defines the EAT Attestation Result (EAR) message format. EAR is used by a verifier to encode the result of the appraisal over an attester's evidence. It embeds an AR4SI's "trustworthiness vector" to present a normalized view of the evaluation results, thus easing the task of defining and computing authorization policies by relying parties. Alongside the trustworthiness vector, EAR provides contextual information bound to the appraisal process. This allows a relying party (or an auditor) to reconstruct the frame of reference in which the trustworthiness vector was originally computed. EAR supports simple devices with one attester as well as composite devices that are made of multiple attesters, allowing the state of each attester to be separately examined. EAR can also accommodate registered and unregistered extensions. It can be serialized and protected using either CWT or JWT. |
| | Secure Shell (SSH) authenticated encryption cipher: chacha20-poly1305 |
| |
|
This document describes the Secure Shell (SSH) chacha20-poly1305 authenticated encryption cipher. |
| | A YANG Data Model for the RFC 9543 Network Slice Service |
| |
|
This document defines a YANG data model for RFC 9543 Network Slice Service. The model can be used in the Network Slice Service interface between a customer and a provider that offers RFC 9543 Network Slice Services. |
| |
|
| |
| | Advertising Flexible Algorithm Extensions in BGP Link-State |
| |
|
Flexible Algorithm is a solution that allows some routing protocols (IS-IS and OSPF) to compute paths over a network based on user- defined (and hence, flexible) constraints and metrics. The computation is performed by routers participating in the specific network in a distributed manner using a Flexible Algorithm Definition. This Definition is provisioned on one or more routers and propagated through the network by IS-IS and OSPF flooding. BGP Link-State (BGP-LS) enables the collection of various topology information from the network. BGP-LS supports the advertisement of Flexible Algorithm Definition and other Flexible Algorithm related advertisements as a part of the topology information from the network. This document specifies the advertisement of further Flexible Algorithm related extensions in BGP-LS. |
| | Intent-based Agent Interconnection Protocol at Agent Gateway |
| |
| | draft-sz-dmsc-iaip-02.txt |
| | Date: |
25/05/2026 |
| | Authors: |
shengsun, Xinyi Zhang, Qiangzhou Gao, Liu Min, Yuwei Wang |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the Intent-based Agent Interconnection Protocol (IAIP) operating at the Agent Gateways (AG), which defines the interaction mechanisms between AI Agents (at the Agent Domain) and the AG (at the Interconnection Services Domain). This specification focuses on dynamic interconnection among agents based on semantic intent, rather than static network addressing alone. This protocols defines the mechanisms for agent registration via capability advertisement, Gateway Validation, Intent Resolution and Matching, Routing Decisions and Forwarding, enabling the discovery, selection and dispatching of intent queries based on agent capabilities and task requirements at AG. |
| | BGP based SRv6 Routing Planes for DC network |
| |
|
This document introduces a BGP-based multi-planar routing architecture for modern data center networks, with a particular focus on environments running AI/ML workloads that demand traffic segregation. The proposed solution enables deterministic routing for workloads with characteristics such as collective communication and multi-tenancy. It allows the creation of multiple logical routing planes over a shared physical infrastructure by defining planes through three key elements: Constraints (e.g., fabric color inclusion/exclusion) Calculation types (e.g., shortest path) and Metric types (e.g., cost, delay, bandwidth). |
| | AGTP Merchant Identity and Agentic Commerce Binding |
| |
|
The Agent Transfer Protocol (AGTP) specifies the sending side of an agentic transaction: agent identity, Authority-Scope enforcement, Budget- Limit declaration, and a signed Attribution-Record on every method invocation. The receiving side of a PURCHASE transaction -- the merchant or service provider -- has no equivalent protocol-level identity or verification mechanism. This is the merchant identity gap. This document specifies the AGTP Merchant Identity and Agentic Commerce Binding. It defines a merchant in AGTP as an agent whose Agent Identity Document carries role: "merchant", specifies the merchant-specific fields that ride on the Agent Identity Document under that declaration, aligns Merchant Trust Tiers with AGTP Trust Tier semantics, and defines the protocol integration points at which merchant identity is verified. These include the PURCHASE method handshake, the DISCOVER method result surface, and the Attribution- Record. This document also defines the Intent-Assertion header for portable, detached principal-authorized intent, the Cart-Digest mechanism for multi-line-item transactions, and the 458 Counterparty Unverified status code. Together these mechanisms close the verification loop between agent and merchant within AGTP's governance model. Version 02 unifies merchant identity onto the Agent Genesis + Agent Identity Document architecture: there is no separate Merchant Genesis document type. A merchant is an agent with role: "merchant" declared in its Agent Identity Document. This reflects the architectural principle that identity is permanent (carried on Genesis) and capability is mutable (carried on the Identity Document); a role change does not re-mint an Agent-ID. |
| | AGTP-API: Verbs,Paths,Endpoints,and Synthesis |
| |
|
This document specifies AGTP-API: the contract layer that the Agent Transfer Protocol (AGTP) [AGTP] relies on to govern interactions between autonomous agents and AGTP servers. AGTP-API defines a curated approved method catalog (with versioned evolution and graceful deprecation), path grammar rules that prevent method-name leakage into paths, the endpoint primitive (the structural unit a server exposes to agents), the semantic block carried by every endpoint, schema validation requirements, the server manifest format that exposes a server's endpoint catalog, the per-server method policy carried as a sub-block of the manifest, the PROPOSE-and- synthesis runtime contract negotiation mechanism, the three handler binding kinds (composition, registered_function, external_service), and the structural rejection status codes (404, 405, 459, 460) that together cover the contract-level failure surface. This document supersedes the AGIS Internet-Draft (draft-hood-independent-agis-01) and the previously-proposed AGTP-Methods Internet-Draft, both of which are deprecated. AGTP-API is the unified companion specification they were splitting concerns across. |
| | AGTP Transparency Log Protocol |
| |
|
This document specifies the AGTP Transparency Log (AGTP-LOG): the append-only audit log protocol that underpins the log-anchored Trust Tier 1 verification path defined in [AGTP] and provides the post-hoc audit infrastructure for AGTP-based agent operations. AGTP-LOG aligns with [RFC9162] (Certificate Transparency 2.0) as the verifiable data structure and issues COSE_Sign1 receipts per [RFC9943] (SCITT) for cross-ecosystem interoperability. This document also establishes the AGTP Agent Identity Taxonomy (Agent Genesis, Canonical Agent-ID, Agent Certificate) that [AGTP] v07 normatively adopts. The log protocol defined here covers entry submission, receipt retrieval, inclusion-proof retrieval, consistency-proof retrieval, and discovery via the log_uri field of the Agent Genesis. Per-platform logs are the default; the federation model follows the SCITT cross-witnessing pattern. Witness and monitor role definitions, full federation procedures, and the formal entry-acceptance threat model are deferred to a future revision. The audit properties AGTP-LOG provides are structural rather than retrofitted. Statements are signed by the governance platform that operates the log, not by the agent the statements concern; an agent cannot forge its own audit trail because it does not control the log operator's signing key. This architectural separation distinguishes AGTP-LOG audit infrastructure from approaches that layer audit data models onto general-purpose substrates where the audited party participates in writing the audit trail. |
| | x402 STARK Receipt Format Extension |
| |
|
The x402 PAYMENT-RESPONSE carries a facilitator-issued settlement reference but does not provide a self-contained, offline-verifiable payment-condition proof. A verifier must today contact the facilitator to confirm whether a specific amount, currency, and payer attestation were satisfied at the time of payment. This gap prevents compliance with EU AI Act Art. 12 (transparency and documentation) and MiCA Art. 76 (settlement record-keeping) in automated payment pipelines. This document defines the receipt-format extension for x402 V2. The extension introduces a negotiable receipt format selection mechanism that allows resource servers, facilitators, and clients to agree on which cryptographic receipt variant to produce and verify, without altering the core PAYMENT-RESPONSE wire structure. Three variants are defined: a Stwo Circle STARK proof of payment conditions (post- quantum sound, offline verifiable), a hybrid ES256K + ML-DSA-65 dual- signature receipt (receipt integrity under quantum adversary), and a classical ES256K fallback. A canonical preimage discipline using JCS ([RFC8785]) ensures cross-implementation digest consistency. The canonical preimage discipline in this document is cross-validated against the x402 canonicalisation conformance set, which is checked byte-for-byte across five independent RFC 8785 ([RFC8785]) implementations in five languages (Python, TypeScript, Go, Java, Rust). |
| | Categorical Compliance Screening Receipt Format for Agentic-Payment Flows |
| |
|
This document specifies a categorical compliance screening receipt format for agentic-payment flows. The format is designed for use by AI agents and agentic-payment gateways that perform regulatory screening at admission time and must retain the screening decision under framework-bound retention obligations (UK Money Laundering Regulations 2017; Proceeds of Crime Act 2002 Section 330; EU Anti- Money Laundering Directives 5 and 6; Markets in Crypto-Assets Regulation Article 80; Anti-Money Laundering Regulation Article 56; Digital Operational Resilience Act Article 14). The receipt format uses a closed enumeration of categorical outcomes (ALLOW, REFER, DENY) rather than a continuous score or tier projection. The categorical outcome is load-bearing for downstream regulatory obligations: under UK POCA 2002 Section 330, a REFER carries a mandatory Suspicious Activity Report obligation that a DENY does not. A score or tier projection collapses this distinction. Receipts are canonicalised under RFC 8785 (JSON Canonicalization Scheme) with an in-band canonicalisation rule pin (canon_version). The pin enables year-five re-verification from retained bytes alone, without dependence on an out-of-band rule registry that the operator must continue to publish. This document is complementary to draft-vauban-x402-stark-receipts: that document covers cryptographic settlement-time payment-condition proofs; this document covers admission-time compliance screening receipts. The two compose via the composite trust-query algorithm specified in specs/composite-trust-query.md in x402-foundation/x402. |
| | Categorical Refund Receipt Format for Agentic-Payment Flows |
| |
|
This document specifies a categorical refund receipt format for agentic-payment flows. The format is the post-settlement counterpart to the admission-time compliance receipt format specified in draft- hopley-x402-compliance-receipt: where the compliance receipt records an admission decision under regulatory screening obligations, the refund receipt records a reversal-of-funds event with the same canonicalisation discipline and the same audit-chain semantics. The receipt format uses a closed enumeration of categorical outcomes (FULL, PARTIAL, REJECTED) rather than a continuous percentage or amount-only representation. The categorical outcome is load-bearing for downstream regulatory obligations: under PSD2 (Directive 2015/2366) Article 89 a REJECTED outcome carries dispute-evidence obligations that a PARTIAL refund does not, and the categorical distinction must be preserved at the canonical-bytes level rather than collapsed to a percentage projection of the original amount. Receipts are canonicalised under RFC 8785 (JSON Canonicalization Scheme) with an in-band canonicalisation rule pin (canon_version). The pin enables year-N re-verification from retained bytes alone, without dependence on an out-of-band rule registry that the operator must continue to publish. The refund receipt format composes with the compliance receipt format via the original_payment_ref field, a content-addressed reference to the original payment record. A verifier walking the audit chain can confirm the full payment lifecycle from admission-time screening through settlement to refund event under one byte-deterministic canonicalisation pin. This document is complementary to draft-vauban-x402-stark-receipts (which covers cryptographic settlement-time payment-condition proofs) and to draft-hopley-x402-compliance-receipt (which covers admission- time compliance screening receipts). The three documents pin the same urn:x402:canonicalisation:jcs-rfc8785-v1 canonicalisation discipline. |
| | x402 V2 Payment Lifecycle Finite State Machine |
| |
|
This document defines a normative finite state machine (FSM) for x402 V2 Payment lifecycle transitions, covering the four canonical Payment Claim states: PaymentIntent (initialisation), SettlementReceipt (completion), RefundClaim (reversal), and DelegationGrant (bounded authority). Each transition is bound to the prior state by cryptographic linkage via the JCS canonical preimage discipline ([RFC8785]), enabling supervisor reconstruction of full payment histories from retained off-VM manifests. The FSM is compatible with the x402 STARK Receipt Format Extension [STARK-RECEIPTS] but applicable to any x402 receipt format that implements the canonical preimage discipline. Implementation evidence: 18 DelegationGrant vectors cross-validated byte-identical across five language runtimes ([X402-2432]), live on-chain anchor on Starknet Sepolia (PaymentDemoEmitter at 0x044dd87a94a801cf775d4c5e4b6703102d4e97e1cd1d0a8879341219ae4f19ff). |
| | VPSF Claim Algebra for x402 Payment Receipts |
| |
|
The x402 protocol ([X402-V2]) defines three wire messages for HTTP- native payment flows but provides no composability model for payment receipts. A recipient holding a SettlementReceipt and a DelegationGrant cannot natively express that the settlement satisfies a delegated spending condition, or that a RefundClaim negates an earlier SettlementReceipt, without bespoke facilitator-side logic. As automated payment pipelines grow, the absence of a normative composability layer leads to fragmented, non-interoperable verification surfaces. This document specifies the Vauban Proof Stack Framework (VPSF) Claim Algebra for x402 payment receipts: a grammar of five composition operators (Conjunction, Implication, Aggregation, Selective Disclosure, Revocation; abbreviated ∧, →, ⊕, ▷, ¬) applied over the four canonical Payment Claim types (PaymentIntent, SettlementReceipt, RefundClaim, DelegationGrant) defined in [LIFECYCLE-FSM]. The algebra is chain-agnostic by invariant; the Starknet-based proof system described in [STARK-RECEIPTS] is the first reference implementation. Composability is grounded in the JCS canonical preimage discipline ([RFC8785]), ensuring operator results are deterministic and cross-implementation consistent. An open-source Rust implementation is provided in [VAUBAN-CRATE]. |
| | x402 V2 Starknet On-Chain Anchor |
| |
|
The x402 receipt-format extension defined in [STARK-RECEIPTS] and the lifecycle finite state machine defined in [LIFECYCLE-FSM] specify cryptographic evidence for x402 V2 payment events as off-chain verifiable artefacts. Neither document specifies how a settlement receipt is promoted to on-chain finality, nor how an independent auditor verifies that promotion without contacting the originating facilitator. This document defines the Starknet on-chain anchor format for x402 V2 payment settlements. The anchor consists of a Starknet event emitted by a conforming Cairo contract, identified by a canonical tuple of chain identifier, transaction hash, event index, and optional block number. A reference implementation, PaymentDemoEmitter, is deployed on Starknet Sepolia at 0x044dd87a94a801cf775d4c5e4b6703102d4e97e1cd1d0a8879341219ae4f19ff and is inspectable via the Voyager block explorer. The document also specifies an RPC endpoint convention, grounded in the Starknet JSON- RPC specification, that any compliant node implementation satisfies; the Vauban Pay reference endpoints are cited as one such implementation. This anchor specification is one instantiation of a chain-agnostic anchoring pattern; the protocol contract is designed to accommodate future per-chain adapter specifications that satisfy the same structural requirements. |
| | x402 Delegation Binding for Agentic HTTP Pipelines |
| |
|
Agent-to-agent HTTP payment pipelines built on x402 V2 require a mechanism to bind a DelegationGrant receipt to the identity of the delegatee agent that will consume it. Existing x402 DelegationGrant fields (as defined in [LIFECYCLE-FSM]) constrain spend scope and expiry but do not cryptographically bind the grant to an agent identity token recognised by A2A or MCP agent protocol layers. Without this binding, a grant issued to one agent can be replayed by another agent with different authority bounds, enabling undetected privilege escalation in automated payment pipelines. This document defines a delegation binding extension for x402 V2 DelegationGrant receipts. The extension introduces a delegate_pseudonym field derived from the agent's identity via the JCS canonical preimage discipline ([RFC8785]), a structured set of spend-cap and scope fields, and a delegation_nonce that enables nullifier consumption on revocation. The binding is cross-validated against 18 bounded-spend vectors in five language runtimes ([X402-2432]). Integration notes are provided for A2A Composable Trust Evidence Format ([A2A-CTEF]) and MCP agent protocol surfaces ([VAUBAN-DEMO]). This document is the fourth companion in the Vauban Pay normative quartet: format ([STARK-RECEIPTS]), lifecycle FSM ([LIFECYCLE-FSM]), and delegation binding (this document); the algebra companion draft-vauban-x402-vpsf-algebra is in preparation. |
| | Post-Quantum Cryptographic Discipline for x402 STARK Receipts |
| |
|
This document specifies a post-quantum cryptographic discipline for x402 STARK receipts. The discipline applies on two layers : (a) proof integrity via hash-based proving systems (the Stwo Circle STARK M31 reference implementation), which are post-quantum sound under standard cryptanalytic assumptions, and (b) signature integrity via the hybrid ES256K + ML-DSA-65 dual-signed receipt variant ([FIPS204]). It maps the hybrid-pqc receipt variant of the x402 STARK Receipt Format Extension ([STARK-RECEIPTS]) to the NIST PQC migration roadmap and to the EU eIDAS 2.0, ANSSI, and BSI migration timelines for the 2025-2030 window. Reference runners are published as the vauban-x402-jcs-conformance and vauban-x402-canonical Rust crates. Companion documents are [STARK-RECEIPTS] (receipt format) and [VPSF-ALGEBRA] (composability grammar). |
| | Categorical Settlement Attestation Format for Agentic-Payment Flows |
| |
|
This document specifies a categorical settlement attestation format for agentic-payment flows. The format records that a payment has reached a particular settlement state on a particular chain, at a particular instant, under the attesting party's risk model. The receipt format uses a closed enumeration of categorical outcomes (SETTLED, PENDING_FINALITY, REVERSED). The categorical outcome is load-bearing for downstream regulatory obligations: SETTLED triggers settlement-finality record-keeping obligations under EU Markets in Crypto-Assets Regulation Article 80 and Anti-Money Laundering Regulation Article 56; the PSD2 (Directive 2015/2366) Article 89 unauthorised-payment refund-window clock begins at SETTLED. PENDING_FINALITY records an inclusion-without-finality state where the refund-window has not yet started. REVERSED records chain- reorganisation, fraud-reversal, or operator-initiated reversal events for chain-of-custody audit. The format is multi-chain: a single settlement_chain string field identifies the chain on which settlement occurred, using a flat identifier convention ( for default mainnets, : for non-default networks). The receipt does not encode chain-specific finality semantics; those are applied at verification time by a verifier that knows the chain. The format composes with the AlgoVoi-authored compliance receipt format (draft-hopley-x402-compliance-receipt) and refund receipt format (draft-hopley-x402-refund-receipt) under the same canonicalisation discipline (draft-hopley-x402-canonicalisation-jcs). A verifier walking the audit chain confirms the full payment lifecycle from admission through settlement to refund (or non-refund) under one byte-deterministic canonicalisation pin. |
| | Categorical Mandate Cancellation Receipt Format for Agentic-Payment Flows |
| |
|
This document specifies a categorical mandate cancellation receipt format for agentic-payment flows. The format records that a recurring-payment mandate or other standing payer-to-payee authorisation has been cancelled, by whom, for what reason, and with what effective date. The receipt format uses a closed four-element enumeration of categorical outcomes (USER_REQUESTED, MERCHANT_REQUESTED, COMPLIANCE_TERMINATED, EXPIRED). The four-state enumeration preserves the regulatorily-load-bearing distinction between payer- initiated revocation, payee-initiated termination, operator/ compliance-forced termination, and time-based expiry. A collapse to a three-state or binary representation loses operational distinctions that drive PSD2 (Directive 2015/2366) Article 64 refund-window obligations, Article 72 contractual-termination record-keeping, and POCA/AML evidence-chain linkage on compliance-forced terminations. The format records two distinct timestamps -- when the cancellation was observed (cancellation_timestamp_ms) and when it takes legal effect (effective_from_ms) -- to support PSD2 Article 64(3)(a) direct-debit revocation timing, where the effective time is typically end-of-business-day prior to the next scheduled execution. The format composes with the AlgoVoi-authored compliance receipt (draft-hopley-x402-compliance-receipt), settlement attestation (draft-hopley-x402-settlement-attestation), and refund receipt (draft-hopley-x402-refund-receipt) formats under the same canonicalisation discipline (draft-hopley-x402-canonicalisation-jcs). A verifier walking the audit chain confirms the full mandate lifecycle from admission through recurring execution to cancellation, and (where owed) onward to refund of revoked settled debits, under one byte-deterministic canonicalisation pin. |
| | Composite Trust Query Response Format for Agentic-Payment Audit Chains |
| |
|
This document specifies a composite trust query response format for agentic-payment audit chains. The format records a verifier's categorical conclusion over an audit chain composed of compliance, settlement, cancellation, and refund receipts, in response to a stated query. The response format uses a closed four-element enumeration of categorical outcomes (TRUSTED, PROVISIONAL, INSUFFICIENT_EVIDENCE, UNTRUSTED). The four-state enumeration captures the operationally- distinct decision space: proceed, proceed-with-caution, hold-pending- more-data, halt. Collapsing to three values loses the distinction between INSUFFICIENT_EVIDENCE ("we could not verify either way") and UNTRUSTED ("we verified and the answer is no"), which matters for operator dashboards, regulator reporting, and downstream automated decision-making. The format is verifier-emitted and audit-chain-anchored. A verifier walks an audit chain composed of compliance receipts (draft-hopley- x402-compliance-receipt), settlement attestations (draft-hopley-x402- settlement-attestation), cancellation receipts (draft-hopley-x402- cancellation-receipt), and refund receipts (draft-hopley-x402-refund- receipt), applies a structured query identified by content-addressed reference, and emits a single composite-trust-claim response anchoring the chain by its content-addressed root. The format composes above the four receipt formats under the same canonicalisation discipline (draft-hopley-x402-canonicalisation-jcs). Regulators, dashboards, and downstream agents consuming the response get a single byte-deterministic statement of the trust posture without re-walking the underlying chain. The chain remains independently verifiable at the response's chain_ref content-address. |
| | Context Relay Protocol (CRP) -- Core Specification |
| |
|
The Context Relay Protocol (CRP) defines a structured, language- agnostic protocol for managing AI context, safety governance, and compliance evidence in deployed large language model (LLM) systems. CRP operates as an HTTP-compatible sidecar protocol, enriching every AI request/response cycle with standardised headers carrying context quality, hallucination risk, provenance integrity, and regulatory classification metadata. This document defines the foundational axioms, request/response model, sidecar architecture, and the normative relationship between CRP's subsystems: the Context Envelope, Contextual Knowledge Fabric (CKF), Decision Provenance Engine (DPE), and the Audit Chain. |
| | Context Relay Protocol (CRP) -- HTTP Header Field Vocabulary |
| |
|
This document defines the complete vocabulary of HTTP header fields for the Context Relay Protocol (CRP). CRP header fields carry AI- specific metadata — context quality, safety risk, provenance integrity, regulatory classification, agent state, and memory layer information — as standard HTTP header fields on AI request/response cycles. This specification provides normative definitions for 58 header fields across six namespaces, suitable for provisional registration in the IANA HTTP Field Name Registry. |
| | Independent QUIC (iQUIC): A Low-Concurrency Operational Profile for HTTP/3 |
| |
|
This document describes iQUIC (Independent QUIC), an experimental operational profile for HTTP/3 over QUIC. iQUIC aims to reduce aggressive application-level multiplexing behavior commonly associated with HTTP/3 deployments while preserving compatibility with QUIC, TLS 1.3, and HTTP/3 semantics. Instead of removing mandatory HTTP/3 internal streams, iQUIC limits concurrent application requests per QUIC connection and encourages the use of multiple independent QUIC keep-alive sessions. |
| | MVPS Trust Profile: Lightweight Authentication via HMAC-SHA256,Operator Epoch Anchors,and Independent Witness Cosignatures for Multi-Vantage Path Snapshots |
| |
|
The Multi-Vantage Path Snapshot (MVPS) bundle format [I-D.melegassi-ippm-mvps-bundle] specifies a deterministic wire envelope but defers cryptographic binding of vantage reports. This document specifies the MVPS Trust Profile, named Coherent-Witness Trust (CWT), which closes that gap with minimal cryptographic overhead: HMAC-SHA256 per-snapshot authentication under an epoch-bound vantage session key, anchored every epoch by an Ed25519-signed Operator Epoch Manifest, and cosigned by independent witnesses on a bundle Merkle checkpoint. The measured per-snapshot crypto cost is 2.1 us -- strictly less than the 4.2 us required to parse the JSON snapshot it protects. At N = 1000 vantages and 1 Hz tick, the total verification load is 0.21 % of one CPU core. The profile inherits the full MVPS v4.0 theorem catalogue and proves two theorems not available in simpler per-snapshot signature designs: T-COAL-1 (multi-operator coalition resistance via witness independence) and T-SPLIT-1 (collector split-view resistance via cosignature quorum). Numerical receipts are in evidence/mvps_cwt_overhead_receipt.json and scripts/validate_cwt_theorems.py (12/12 PASS). The design draws on two production precedents: the HMAC- personalized authentication of the Tesla vehicle-command protocol [TESLA-VEHICLE-CMD] and the witness-cosignature model of the Sigsum / tlog-witness ecosystem [C2SP-TLOG-WITNESS]. Neither codebase is reused; constructs are independently composed for the multi-vantage measurement setting. |
| | A SCITT Profile for EU AI Act Article 50 Transparency Receipts |
| |
|
This document defines a Supply Chain Integrity, Transparency, and Trust (SCITT) profile for machine-readable cryptographic transparency receipts addressing all four sub-obligations of Article 50 of Regulation (EU) 2024/1689 (the "EU AI Act"): interactive AI system disclosure (50(1)), machine-readable marking of synthetic media (50(2)), emotion recognition notification (50(3), referenced for completeness), and AI-generated text disclosure with human editorial review exemption (50(4)). The profile defines three SCITT statement content types ("ai/article-50/v1", "ai/human-review/v1", and "ai/chatbot-session/v1") and specifies validation, verification, and chain-of-custody semantics suitable for presentation to European Union supervisory authorities, national competent authorities, and judicial proceedings. The profile is substrate-agnostic but presumes a SCITT Transparency Service backed by a publicly verifiable append-only log. A reference implementation using the Bitcoin blockchain as the SCITT log substrate, via RFC 6962 Merkle aggregation anchored in OP_RETURN transactions, is described in companion document draft-dawkins-scitt-lpr-00. |
| |
|
| |
| | OSPF-GT (Generalized Transport) |
| |
|
OSPFv2 and OSPFv3 include a reliable flooding mechanism to disseminate routing topology and Traffic Engineering (TE) information within a routing domain. Given the effectiveness of these mechanisms, it is advantageous to use the same mechanism for dissemination of other types of information within the domain. However, burdening OSPF with this additional information will impact intra-domain routing convergence and possibly jeopardize the stability of the OSPF routing domain. This document presents mechanisms to advertise this non-routing information in separate OSPF Generalized Transport (OSPF-GT) instances. OSPF-GT is not constrained to the semantics as traditional OSPF. OSPF-GT neighbors are not required to be directly attached since they are never used to compute hop-by-hop routing. Consequently, independent sparse topologies can be defined to dissemenate non- routing information only to those OSPF-GT routers requiring it. |
| | BGP AS_PATH Verification Based on Route Path Authorizations (RPA) Objects |
| |
|
The Route Path Authorizations (RPA) is an RPKI object that attests to the routing paths description which an Autonomous System (AS) would obey in Border Gateway Protocol (BGP) route propagation. This document specifies an RPA-based AS Path Verification methodology to mitigate, even solve, AS Path forgery and route leaks. This document also explains the various BGP security threats that RPA can help address and provides operational considerations associated with RPA deployment. |
| | A Well-Known URI for API Change Advisories |
| |
|
This document defines a well-known URI, /.well-known/api- advisory.json, at which API providers MAY publish a machine-readable JSON discovery file. That file identifies the API and provides the URL of an Atom Syndication Format feed carrying structured change advisories. The Atom feed enables automated scanners and API consumers to discover pricing changes, deprecations, security advisories, and other relevant events without relying on manual monitoring of blogs or mailing lists. Advisory metadata is conveyed through a dedicated XML namespace defined in this document. |
| | Topology-Aware Construction of Collective Communication over Time-Expanded Networks |
| |
|
This document describes a topology-aware method for constructing collective communication schedules in distributed systems. Instead of selecting from a small set of predefined communication algorithms, the method expands a target network topology along a time dimension, tracks per-node data state, and incrementally builds a schedule through candidate-source discovery and link-to-chunk matching. The approach is intended for heterogeneous or asymmetric topologies in which fixed communication patterns often underutilize available links or create avoidable bottlenecks. According to the source material, the resulting schedule is intended for collective communication tasks involving data distribution, aggregation, reduction, and synchronization, including all-gather, reduce-scatter, and all- reduce. |
| | DNS-Anchored Identity Discovery for Autonomous Agents |
| |
|
This document defines the core of Groundmark, a protocol for DNS- anchored identity discovery and request authentication for autonomous software agents. Operators publish an agent's signing public key in a DNS TXT record under a reserved label, and optionally publish references to externally hosted attestations under a second reserved label. Agents authenticate HTTP requests using HTTP Message Signatures (RFC 9421) with a key identifier that resolves through DNS. DNSSEC is required for all Groundmark DNS lookups. The protocol provides operator accountability discovery without a central registry, and is designed to compose with existing identity, authorization, and payment systems rather than to replace them. The attestation framework, including the role of Identity Service Providers, the attestation level taxonomy, and the claim vocabulary, is defined in a companion document. |
| | Groundmark Attestation Framework and Identity Service Provider Profile |
| |
|
This document defines the Groundmark attestation framework and the profile of Identity Service Providers (IDSPs) that issue Groundmark attestations. It is the companion document to the Groundmark core protocol, which specifies DNS publication and request-signature mechanics. This document specifies the role and obligations of Identity Service Providers, a four-level taxonomy of attestation strength, an initial vocabulary of claim types, the JSON schema and signature construction for attestation payloads, the method- disclosure discipline that defines an IDSP's accountability obligation, and revocation semantics for the attestation layer. The core protocol document defines the discovery mechanisms (the _agentclaim DNS TXT record and the HTTP retrieval of attestation payloads) on which this document depends. Together the two documents specify Groundmark. |
| | Use of FN-DSA in TLS 1.3 |
| |
|
This document specifies how FN-DSA can be negotiated for authentication in TLS 1.3 via the signature_algorithms and signature_algorithms_cert extensions. |
| |
|
| |
| | Composite Module-Lattice-Based Digital Signature Algorithm (ML-DSA) for use in Cryptographic Message Syntax (CMS) |
| |
|
Composite Module-Lattice-Based Digital Signature Algorithm (ML-DSA) defines combinations of ML-DSA with RSA, ECDSA, and EdDSA. This document specifies the conventions for using Composite ML-DSA algorithms within the Cryptographic Message Syntax (CMS). |
| | Distributed Ledger Time-Stamp |
| |
| | draft-intesigroup-dlts-13.txt |
| | Date: |
22/05/2026 |
| | Authors: |
Emanuele Cisbani, Daniele Ribaudo, Giuseppe Damiano |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a standard to extend Time Stamp Tokens with Time Attestations recorded on Distributed Ledgers. The aim is to provide long-term validity to Time Stamp Tokens, backward compatible with currently available software. |
| | Privacy Preference Declaration for Home Networks |
| |
|
This document describes an architecture for signaling household privacy preferences to devices in home networks through Privacy Preference Declarations (PPDs). The architecture enables a PPD participant to discover a PPD service endpoint, establish trust in that endpoint through the applicable protocol and security profile, retrieve the applicable household policy instance, and acknowledge receipt of that policy instance. The acknowledgment establishes that a specific policy instance was made available to the participant; it does not, by itself, assert anything about the participant's subsequent behavior. |
| | Privacy Preference Declaration Taxonomy |
| |
|
This document defines the core vocabulary, comparison model, and extension discipline used by Privacy Preference Declarations (PPDs) to express atomic privacy-relevant dataflows in home networks. It complements the companion PPD architecture and protocol work by standardizing the core fields used in participant declarations and household policy rules. The core vocabulary is the mandatory shared semantic floor for baseline participant-facing interoperability. Richer ecosystem-specific vocabularies remain possible, but comparison-relevant non-core terms need explicit relationships to the shared core so they remain computable. Baseline participant-facing protocol messages use compact identifiers plus taxonomy context rather than requiring full ontology exchange on the wire. |
| | DNS-Based Address Mapping Record (AMR) for IPv4/IPv6 Mapping in IPv6-only Networks |
| |
|
This document defines a new Domain Name System (DNS) resource record type called the Address Mapping Record (AMR). The AMR record enables querying of IPv6 mapping prefixes associated with the destination address of an IPv4 packet in IPv6-only networks. This mechanism facilities the transmission of IPv4 service data across multi-domain in IPv6-only environment, supporting IPv4-as-a-Service (IPv4aaS) implementations. |
| | Dynamic Multi-agent Secured Collaboration Infrastructure Architecture |
| |
|
This document presents an architectural framework for dynamic multi- agent collaboration from an infrastructure perspective. It outlines the network requirements introduced by large-scale agents collaboration, and proposes a systematic approach to enabling Dynamic Multi-agent Secured Collaboration (DMSC) through infrastructure capabilities. The architecture focuses on how network control and forwarding functions can actively participate in agent collaboration. |
| | Agent Identity Registry System: A Federated Architecture for Hardware-Anchored Identity of Autonomous Entities |
| |
|
The Internet's identity infrastructure assumes human principals. As autonomous entities -- AI agents, robotic systems, and other non- human actors -- increasingly participate in both Internet protocols and physical society, no existing standard provides them with persistent, verifiable, hardware-anchored identity. The absence of such identity enables Sybil attacks at scale, undermines trust between autonomous entities and the services they interact with, and leaves human bystanders unable to distinguish one machine from another. This document defines a federated registry architecture for issuing, managing, and verifying persistent identities for autonomous entities. Each identity is expressed as a URN in the "aid" (Agent Identity) namespace ([RFC8141]) and is anchored, where hardware is available, to a physical security component (TPM, PIV smart card, secure enclave, or virtual TPM) whose manufacturer-certified key cannot be extracted, cloned, or transferred. This hardware anchoring provides Sybil resistance: creating N identities requires N distinct physical devices, making large-scale identity fraud economically infeasible. Software-only entities may participate at a lower trust tier, building reputation from a baseline rather than from a hardware-anchored starting point. The architecture separates concerns into three tiers, modeled on the proven Internet domain name system: a Governance Authority that sets policy and manages the global trust framework, Registry Operators that maintain authoritative identity databases and enforce cross- provider uniqueness, and Registrars that perform hardware attestation verification, issue standard OpenID Connect ([OIDC-Core]) tokens, and serve as the primary interface for autonomous entities. The system issues standard OIDC/OAuth2 tokens, enabling any Relying Party -- email services, API gateways, agent-to-agent platforms, reputation services, certification bodies, or any service that needs to verify agent identity -- to verify token signatures using existing OIDC libraries. A companion specification ([I-D.drake-email-hardware-attestation]) defines transport-level attestation headers for email and other protocols; this document defines the identity infrastructure that underpins those attestations. The architecture anticipates a future in which reliable, indelible identity for autonomous entities -- from cloud software agents through embodied robots that interact physically with humans -- is as fundamental to infrastructure as the domain name system is today. |
| | The 'ztdnaid' URI Scheme for Zero-Trust Digital DNA Identifiers (ZTDNAID) |
| |
|
This document defines the 'ztdnaid' Uniform Resource Identifier(URI) scheme, used to represent globally unique, cryptographically verifiable Digital DNA Identifiers (ZTDNAIDs) within Zero Trust architecture implementations. A ZTDNAID binds an entitys immutable, unique Digital DNA Record "DDR" to a resolvable identifier suitable for authentication, authorization, attestation, and trust-registry lookup. The scheme is designed for use with trust registries operating across "Public Trust Infrastructure" (PTI), such as SAG-CTR and supports deterministic resolution, offline verification, and secure dereferencing. |
| | Privacy Preference Declaration Protocol Specification |
| |
|
This document specifies a participant-facing protocol for Privacy Preference Declarations (PPDs) in home networks. The protocol is between a home-side PPD service endpoint and a device-side actor, formally the PPD participant, which is a device or a service acting on behalf of a device. It defines baseline operations for endpoint metadata confirmation, participant registration, optional participant declaration, effective-policy retrieval, policy acknowledgment, renewal, and reassociation. This document complements the PPD architecture and taxonomy documents by defining the message and sequencing behavior needed for interoperable policy signaling. The household policy instances carried by this protocol express privacy preferences for signaling and comparison; they do not by themselves define an enforcement mechanism that guarantees participant behavior. |
| | An RDAP Profile for Agent Identifier Registration Data |
| |
|
AI agents may need stable identifiers that are independent from their current network locations. In agent deployments, an Agent identifier may be associated with IPv6 locators, IPv6 prefixes, Agent Gateways, public key references, policy references, lifecycle state, and revocation status. Applications, gateways, controllers, and operators need a trusted way to query this registration data. This document defines an RDAP profile for querying Agent identifier registration data. The profile reuses the Registration Data Access Protocol (RDAP) query model and JSON response format, and defines an RDAP object class and extension members for Agent identifiers, IPv6 locator bindings, Agent Gateway bindings, and related operational metadata. This document does not define a new agent discovery protocol, a new agent interaction protocol, or a new authentication mechanism. It defines a registration data access profile that can be used by agent deployments and by other agent-related systems that need trusted Agent identifier metadata. |
| | Privacy Considerations for the Discovery of Agents,Workloads,and Named Entities (DAWN) |
| |
|
This document describes the privacy issues associated with the Discovery of Agents, Workloads, and Named Entities (DAWN). It provides general observations about typical current privacy practices in similar domains like, DNS, HTTP, and in general privacy in information retrieval. |
| |
|
| |
| | Cookies: HTTP State Management Mechanism |
| |
|
This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 6265 and 6265bis. |
| | BGP Flow-Spec Redirect-to-IP Action |
| |
|
Flow-spec is an extension to BGP that allows for the dissemination of traffic flow specification rules. This has many possible applications, but the primary one for many network operators is the distribution of traffic filtering actions for distributed denial of service (DDoS) mitigation. The flow-spec standard, RFC 8955, defines a redirect-to-VRF (Virtual Routing and Forwarding) action for policy- based forwarding. This mechanism can be difficult to use, particularly in networks without Layer 3 VPN infrastructure. This document defines a new redirect-to-IP flow-spec action that provides a simpler method of policy-based forwarding. The details of the action, including the IPv4 or IPv6 target address, are encoded in newly defined BGP extended communities [RFC4360]. |
| | A Mechanism for X.509 Certificate Discovery |
| |
| | draft-ietf-lamps-certdiscovery-03.txt |
| | Date: |
21/05/2026 |
| | Authors: |
Tomofumi Okubo, Corey Bonnell, John Gray, Mike Ounsworth, Joe Mandel |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
This document specifies a method to discover a secondary X.509 certificate associated with an X.509 certificate to enable efficient multi-certificate handling in protocols. The objective is threefold: to enhance cryptographic agility, improve operational availability, and accommodate multi-key/certificate usage. The proposed method aims to maximize compatibility with existing systems and is designed to be legacy-friendly, making it suitable for environments with a mix of legacy and new implementations. It includes mechanisms to provide information about the target certificate's signature algorithm, public key algorithm and the location of the secondary X.509 certificate, empowering relying parties to make informed decisions on whether to fetch the Secondary Certificate. The primary motivation for this method is to address the limitations of traditional certificate management approaches, which often lack flexibility, scalability, and seamless update capabilities. By leveraging this mechanism, subscribers can achieve cryptographic agility by facilitating the transition between different algorithms or X.509 certificate types. Operational redundancy is enhanced by enabling the use of backup certificates and minimizing the impact of Primary Certificate expiration or CA infrastructure failures. The approach ensures backward compatibility with existing systems and leverages established mechanisms, such as the subjectInfoAccess extension, to enable seamless integration. |
| | Transaction Tokens For Agents |
| |
|
This document specifies an extension to the to support agent context propagation within Transaction Tokens for agent-based workloads. The extension defines the use of the act field to identify the agent performing the action, and leverages the existing sub field (as defined in the base Transaction Tokens specification) to represent the principal. The sub field is populated according to the rules specified in OAUTH-TXN-TOKENS (https://drafts.oauth.net/oauth- transaction-tokens/draft-ietf-oauth-transaction-tokens.html), based on the 'subject_token' provided in the token request. For autonomous agents operating independently, the sub field represents the agent itself. These mechanisms enable services within the call graph to make more granular access control decisions, thereby enhancing security. This document specifies an extension to OAuth Transaction Tokens OAUTH-TXN-TOKENS (https://drafts.oauth.net/oauth-transaction- tokens/draft-ietf-oauth-transaction-tokens.html) to support agent context propagation within Transaction Tokens for agent-based workloads. The extension defines the agentic_ctx claim, a structured JWT claim that carries chain-level metadata required for multi-agent flow integrity and MAY contain additional deployment-specific agent context. The extension addresses two deployment patterns: single- agent flows where one agent acts on behalf of a user within a transaction, and multi-agent flows where multiple agents collaborate across a call chain. In multi-agent scenarios, the Transaction Token is replaced at each agent transition by the Transaction Token Service, updating the agentic_ctx claim while preserving the immutable identity context (sub and act claims) established at transaction initiation. This specification leverages the existing act claim as defined in RFC8693 (https://datatracker.ietf.org/doc/html/rfc8693) and the sub claim as defined in OAUTH-TXN-TOKENS (https://drafts.oauth.net/oauth- transaction-tokens/draft-ietf-oauth-transaction-tokens.html). It does not define new token types or grant types; it operates entirely within the existing Transaction Token issuance and replacement mechanisms defined by the base specification. |
| | Agentic Notation Markup Language (ANML) 1.0 |
| |
|
ANML (Agentic Notation Markup Language) is a machine-first markup language for agent-to-agent and agent-to-service communication over the internet. HTML provides visual interfaces for human consumption; ANML describes content, intent, and interaction patterns optimized for machine interpretation with minimal computational overhead. ANML defines an abstract data model that MAY be serialized as XML (application/anml+xml) or JSON (application/anml+json). Both serializations are normative and semantically equivalent. The XML serialization is recommended for human authoring and review; the JSON serialization is recommended for programmatic generation and agent- pipeline consumption. An ANML document defines: * Content: structured, semantic information for machine interpretation * Interactions: operations bound to HTTP methods, endpoints, and parameters * Knowledge: bidirectional information exchange between services and agents * Constraints: disclosure, consent, and authorization rules that agents MUST evaluate before sharing data * State: metadata identifying the current phase of a multi-step interaction * Persona: advisory behavioral and tonal guidance for agent responses ANML standardizes these elements to enable deterministic, efficient agent interactions with reduced reliance on inference over unstructured data. |
| | Cross-Platform Mobile Attestation Normalization |
| |
|
This document defines a set of requirements and a normalized Entity Attestation Token (EAT) profile for representing attestation evidence produced by attestation services across heterogeneous mobile platforms, including platform-specific mechanisms such as Google Play Integrity, Apple App Attest, Apple DeviceCheck, and other OEM- specific or third-party attestation services. The goal is to enable interoperable processing of attestation evidence by verifiers and relying parties without requiring changes to the underlying attestation providers. This document specifies a canonical mapping of platform-specific attestation claims into EAT claims and defines normalization rules intended to improve consistency across mobile ecosystems. |
| | Federated Infrastructure Layer for Cross-Platform Device and Application Attestation |
| |
|
This document defines a federated infrastructure layer for cross- platform device and application attestation. The proposed architecture extends the Remote ATtestation ProcedureS (RATS) architecture [RFC9334] by introducing privacy-preserving federation, decentralized endorsement distribution, decentralized normalization of attestation claims, and software supply-chain provenance integration. The architecture enables interoperable attestation across heterogeneous operating systems, application ecosystems, and trust providers without requiring centralized platform ownership. This document defines architectural roles, protocol interactions, endorsement distribution semantics, provenance integration models, and privacy requirements. |
| | Identity Assertion JWT Authorization Grant |
| |
|
This specification provides a mechanism for an application to use an identity assertion to obtain an access token for a third-party API by coordinating through an identity provider that the downstream Resource Authorization Server already trusts for single sign-on (SSO), using Token Exchange [RFC8693] and JWT Profile for OAuth 2.0 Authorization Grants [RFC7523]. This pattern is informally referred to as Cross-App Access (XAA). |
| |
|
| |
| | Signaling Maximum Transmission Unit (MTU) using BGP-LS |
| |
|
Segment Routing (SR) leverages the source routing paradigm, which can be directly applied to the MPLS architecture and IPv6 architecture, with a new type of routing header. Since multiple labels or SRv6 SIDs are pushed in the packets, it is more likely that the packet size exceeds the path MTU of SR tunnel. However, SR uses the IGP as the routing protocol and does not support the negotiation of the Path MTU. BGP Link State (BGP-LS) describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This document specifies the extensions to BGP-LS to carry MTU information of link. The centralized controller (PCE/SDN) calculates the Path MTU while completing the service path calculation based on the information transmitted by the BGP-LS. |
| | Internet X.509 Public Key Infrastructure -- Algorithm Identifiers for the Fast-Fourier Transform over NTRU-Lattice-Based Digital Signature Algorithm (FN-DSA) |
| |
|
Digital signatures are used within X.509 certificates and Certificate Revocation Lists (CRLs), and to sign messages. This document specifies the conventions for using, the forthcoming, FIPS 206, the Fast-Fourier Transform over NTRU-Lattice-Based Digital Signature Algorithm (FN-DSA), in Internet X.509 certificates and CRLs. The conventions for the associated signatures, subject public keys, and private key are also described. |
| | Use of the FN-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS) |
| |
|
The Fast-Fourier Transform over NTRU-Lattice-Based Digital Signature Algorithm (FN-DSA), as defined by NIST in FIPS 206, is a post-quantum digital signature scheme that aims to be secure against an adversary in possession of a Cryptographically Relevant Quantum Computer (CRQC). This document specifies the conventions for using the FN-DSA signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier is provided. |
| | IP Address Space for Outer Space |
| |
|
The exploration of outer space depends heavily upon communications technology and in many cases, uses IP. IP address allocation has been formally assigned to Regional Internet Registries (RIRs), but there is no formal allocation of address space for networks in outer space. This document describes updates existing address allocation procedures to include address space for outer space. |
| | MyTerms Contract Negotiation Protocol (MCNP): Human and machine-readable agreements |
| |
|
This document covers the technical requirements of Verifiable Contractual Agreements (VCAs) between individuals and the entities that engage on a network as defined in IEEE7012. It describes how individuals, acting as first parties, can proffer their privacy requirements as contractual terms and arrive at agreements recorded and kept by both sides. This includes the hosting format for contracts, negotiation of contracts, signing of contracts, and auditing of contracts. |
| | The MMCO Module Component Object and MMCS Composite Security Format |
| |
|
This document specifies two cooperating formats used by the MeshMC launcher to discover, validate, and load third-party native code modules at run time: * MMCO (MMCO Module Component Object), a host-native dynamic library container with a fixed C ABI describing the module's metadata, dependencies, lifecycle entry points, and runtime context. * MMCS (MMCO Module Composite Security), an OpenPGP-based detached signature trailer appended to an MMCO file, together with the license-driven verification policy that decides whether a given module is permitted to load. The two formats are layered: MMCS is defined strictly on top of MMCO and never modifies the bytes that the host operating system parses as a shared object. A conforming MMCO implementation MAY ignore MMCS and still load OSI-approved open-source modules; a conforming MMCS implementation MUST refuse to load a module whose trailer is present but does not verify against a trusted key. This document is intended as a stable reference for independent implementers of MMCO toolchains, plugin authors, and packagers. |
| | vCon Agent Session |
| |
|
This document defines an "agent_session" extension for Virtualized Conversations (vCon) that profiles the use of vCon parties, dialog, analysis, and attachments to carry the record of an autonomous AI agent's internal session - its prompts, tool invocations, tool results, reasoning, and file or artifact provenance - alongside the human-facing conversation that the agent participated in or acted upon. The extension is a Compatible vCon extension. It introduces no new top-level fields and does not alter the semantics of existing ones. Instead, it specifies (a) how an autonomous agent is represented as a vCon party, (b) how agent message turns are placed in the dialog array, (c) how the internal agent trace (tool calls, results, reasoning, system events) is carried as a structured analysis entry whose body conforms to the Verifiable Agent Conversations (VAC) CDDL schema [I-D.draft-birkholz-verifiable-agent-conversations], and (d) how files and artifacts modified by the agent are carried as attachments. By projecting agent-session data into the vCon model, implementations inherit vCon's party/identity model, the lawful basis framework [I-D.draft-howe-vcon-lawful-basis], the lifecycle and redaction machinery [I-D.draft-howe-vcon-lifecycle], and JWS-based signing, without re-specifying any of those concerns. |
| |
|
| |
| | Clarifying SRv6 SID List Processing |
| |
|
Segment Routing over IPv6 (SRv6) is the instantiation of Segment Routing (SR) on the IPv6 data plane. Segments are indicated by Segment Identifiers (SIDs). SRv6 utilizes the Segment Routing Header (SRH), an IPv6 extension header, that includes a SID list indicating the sequence of segments and any additional processing to be performed. This document updates RFC 8754 by clarifying the processing of SID list entries. It does not change any elements of the SRv6 architecture. |
| | Communicating Proxy Configurations in Provisioning Domains |
| |
|
This document defines a mechanism for accessing provisioning domain information associated with a proxy, such as other proxy URIs that support different protocols and information about which destinations are accessible using a proxy. 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/tfpauly/privacy-proxy. |
| | Quality of Outcome (QoO) |
| |
| | draft-ietf-ippm-qoo-11.txt |
| | Date: |
19/05/2026 |
| | Authors: |
Bjorn Teigen, Magnus Olden, Ike Kunze |
| | Working Group: |
IP Performance Measurement (ippm) |
|
This document introduces the Quality of Outcome (QoO) network quality score and the corresponding QoO framework as an approach to network quality assessment designed to align with the needs of users, application developers, and network operators. Conceptually based on the Quality Attenuation metric, QoO provides a method for defining and evaluating application-specific, quality- focused network performance requirements to enable insights for network troubleshooting and optimization, and simple Quality of Service scores for end-users. |
| | LISP Virtual Private Networks (VPNs) |
| |
| | draft-ietf-lisp-vpn-14.txt |
| | Date: |
19/05/2026 |
| | Authors: |
Victor Moreno, Dino Farinacci |
| | Working Group: |
Locator/ID Separation Protocol (lisp) |
|
This document describes the use of the Locator/ID Separation Protocol (LISP) to create Virtual Private Networks (VPNs). LISP is used to provide segmentation in both the LISP data plane and control plane. These VPNs can be created over the top of the Internet or over private transport networks, and can be implemented by Enterprises or Service Providers. The goal of these VPNs is to leverage the characteristics of LISP - routing scalability, simply expressed Ingress site TE Policy, IP Address Family traversal, and mobility, in ways that provide value to network operators. |
| | LISP L2/L3 EID Mobility Using a Unified Control Plane |
| |
| | draft-ietf-lisp-eid-mobility-18.txt |
| | Date: |
19/05/2026 |
| | Authors: |
Marc Portoles-Comeras, Vrushali Ashtaputre, Fabio Maino, Victor Moreno, Dino Farinacci |
| | Working Group: |
Locator/ID Separation Protocol (lisp) |
|
The LISP control plane offers the flexibility to support multiple overlay flavors simultaneously. This document specifies how LISP can be used to provide control-plane support to deploy a unified L2 and L3 overlay solution for End-point Identifier (EID) mobility, as well as analyzing possible deployment options and models. |
| | Indication of Load-balancing Strategy |
| |
|
This document proposes the encoding of the indication for load- balancing strategies which can be encapsulated into a variety of protocols such as MPLS, IPv6 and SRv6 networks. It also provides the considerations for load-balancing configuration in control plane as well. |
| | OAuth Client Challenge Protocol |
| |
|
This document extends the OAuth 2.0 token endpoint error response (RFC 6749) with a new error code that indicates to the client that it must provide additional input for the authorization server to authorize it and accept its request. This mechanism enables just-in-time authorization flows in which the authorization server dynamically challenges the client during a request and the client tries to satisfy it. For example, the authorization server can ask the client mid-flow to provide an assertion, a verifiable presentation, or other proof-of-possession material. |
| | Automated Certificate Management Environment (ACME) Identity-Controlled Validation Extension |
| |
|
This document defines an Identity Control Validation (ICV) framework for the ACME protocol [RFC8555], introducing a new ACME identifier type "idp" and a new challenge type "idp-01". The ICV framework allows ACME servers to delegate trusted Identity Providers (IdPs) to verify certificate applicants’ control over the claimed identities. This document also defines an optional X.509 certificate extension, the Trust-Domain-Restricted Certificate Extension, which explicitly indicates that certificates issued via the ICV framework are backed by a specific IdP trust domain and whose trustworthiness depends on the current status and policies of that IdP, preventing trust leakage into contexts outside the IdP’s trust domain. This extension is parallel to Domain Control Validation (DCV) [RFC8555]; either can independently verify an applicant’s control over identities/resources and request certificates. Proof-of-Possession (PoP) [I-D.geng-acme-public-key] serves as an auxiliary enhancement framework. Based on this architecture, two standardized certificate enrollment models are formed: the Domain Validation model (DCV + optional PoP) and the Identity Validation model (ICV + optional PoP). This document focuses on the latter. This document defines three deployment models: the IdP-Operated Certificate Model, the Intra-PKI Domain Mutual-Trust Model, and the CA-Integrated IdP Model. It supports multiple authentication protocols via the extensible idp_method parameter, covering both device and account identities. |
| | Taistamp: Signed TAI64N Timestamps over HTTP |
| |
|
This memo defines Taistamp, an HTTP-accessible service that returns the current time as a TAI64N label, optionally signed with Ed25519. The service is reached at the well-known URI /.well-known/taistamp and is intended for clients that need an authenticated wall-clock reading without running an NTP stack or relying on the client's own clock for TLS certificate validation. The signing scheme uses a length-prefixed, domain-separated framing and publishes verification keys as DNS TXT records in a DKIM-inspired selector layout. |
| | Community considerations on DNS WG structures at IETF |
| |
|
There has been an increasing level of discussion within the IETF about the best Working Group (WG) structures for handling the wide array of DNS work being conducted within the IETF. Wes Hardaker was asked to gather information from the community at large through e-mail, hallway discussions, and meetings and create a small team to discuss potential structural changes to be shared with the community. This document describes the team’s aggregated findings, their derived recommendations, and topics where the team did not find sufficient commonality within the collected opinions. This document is published to retain the record for historic reference. |
| |
|
| |
| | Advertising SID Algorithm Information in BGP |
| |
|
This document defines new Segment Types and proposes extensions for BGP to provide algorithm information for SR-MPLS Adjacency-SIDs when delivering SR Policy via BGP. |
| | Route Origin Registry Problem Statement |
| |
| | draft-jiang-sidrops-psvro-04.txt |
| | Date: |
18/05/2026 |
| | Authors: |
Shenglin(Forrest) Jiang, Ke Xu, Li Qi, Xingang Shi, Zhuotao liu |
| | Working Group: |
Individual Submissions (none) |
|
Prefix hijacking, i.e., unauthorized announcement of a prefix, has emerged as a major security threat in the Border Gateway Protocol (BGP), garnering widespread attention. To migrate such attacks while supporting legitimate Multiple Origin AS (MOAS), higher requirements are placed on the route origin registry. This document serves to outline the problem statement for current route origin registry. |
| | Pathway-based Content Steering |
| |
|
This document describes a mechanism for servers to communicate their preferences to clients about utilizing alternate servers for streaming content. These alternate servers are typically distinct Content Delivery Networks or any other servers that offer similar distribution services. The mechanism described in this document is designed to be universally applicable and independent of any specific Content Delivery Protocol. |
| | Signaling Alternative Labels for BGP Prefixes |
| |
| | draft-smm-bess-alt-label-01.txt |
| | Date: |
18/05/2026 |
| | Authors: |
Shyam Sethuram, Mankamana Mishra, MOHANTY Satya, Israel Means, Praveen Ramadenu |
| | Working Group: |
Individual Submissions (none) |
|
A single MPLS label or a label stack is advertised along with an address prefix as part of the NLRI belonging to labeled address families such as Labeled Unicast (RFC 8277), VPN (RFC 4364), etc. This document specifies a method to advertise one or more additional, alternative labels for a set of address prefixes using the Next Hop Dependent Characteristics (NHC) attribute. |
| | AGTP Communication Protocol |
| |
|
This document specifies the AGTP Communication Protocol (AGTP- COMMUNICATION): the companion specification for real-time multi-modal communication between agents over the Agent Transfer Protocol (AGTP). AGTP-COMMUNICATION defines how voice, video, and other real-time media streams are exchanged between agents on the agent-native substrate, with native support for the wire-level identity, authority scope, and attribution that AGTP provides. This is an early specification covering bilateral (two-agent) real- time communication. Multi-party conversations and conferencing patterns are out of scope for this revision and are deferred to future companion work. |
| | External Admission Boundary for Pre-Execution AI Action Control |
| |
|
This document defines an external admission boundary for pre-execution AI action control. The boundary is a control point at which execution cannot proceed unless an allow decision has been issued by an authority outside the executor trust domain. The document distinguishes evidence records, policy evaluations, approval logs, and signed pre-execution authorization records from the stronger boundary property of authority separation. A signed pre-execution record can prove that a decision was made before dispatch. It does not by itself prove that final execution authority was outside the executor trust domain. This document provides a practical test for determining whether a claimed pre-execution control is a real external admission boundary or a surrogate boundary. |
| | WLP: Wet-Lab Protocol -- AI-to-Automation Instruction Schema v0 |
| |
|
This document specifies WLP v0, the Wet-Lab Protocol for translating AI hypotheses (PACR records) into machine-executable wet-lab instructions. WLP is the longevity-research analogue of SCP (Science Context Protocol) from the photoresist automation domain. The protocol is royalty-free (Apache-2.0). Reference implementations in Rust (crates/wlp-conformance) and Python (agentcard_adapters.wlp_conformance) are provided. |
| | Iron Triangle Trace for Longevity (ITT-L): A PACR Application Payload Format for Gene-Level Longevity Data |
| |
|
This document defines Iron Triangle Trace for Longevity (ITT-L), a domain-specific Application Payload Format carried within the PACR (Physical and Causal Auditable Record) envelope. Each ITT-L record binds four measurement facets — gene, mechanism, drug/metabolite, and epigenetic — into a single independently-citable asset with causal predecessor chain (Π) integrity provided by the PACR transport layer. ITT-L is NOT a standalone protocol; it is a payload format that leverages PACR for physical proof (Λ, Landauer cost) and causal ordering (Π chain), and AgentCard for service identity. |
| | Browser Vendor Attestation Protocol (BVAP) |
| |
|
The HTTP User-Agent header field allows any client to claim any browser identity without cryptographic proof. Any software may assert "Mozilla/5.0 Chrome/124" regardless of its actual origin, distribution source, or software provenance. This document specifies BVAP (Browser Vendor Attestation Protocol), a mechanism by which browser vendors cryptographically attest that a browser instance originates from a legitimate, vendor-issued browser build. Attestation occurs at installation time and is periodically renewed. The resulting Vendor Attestation Seal (BVAP Seal) is carried by the browser and is primarily transmitted via the Sec-BVAP header field. The Seal MAY additionally appear in the User-Agent string for backward compatibility with legacy infrastructure. BVAP provides software provenance and vendor authenticity at the browser layer. The protocol allows servers to distinguish between: o Vendor-attested browser software, o Anonymous or self-built browser software (Unattested), and o Software falsely claiming vendor browser identity. BVAP requires no per-request cryptography and no DNS lookups during normal operation. BVAP proves browser origin, not browser behavior. |
| | Biometric Vector Steganography for Document Trust and AI-First Preambles (BVS) |
| |
|
This document specifies the Biometric Vector Steganography (BVS) protocol. It defines an asynchronous, differential geometry-based method for embedding machine-readable metadata (AI-First Preambles) and cryptographic signatures into plain text documents. By utilizing two correlating Scalable Vector Graphics (SVG) paths (walz and walz_shadow), BVS enables the creation of a dynamic, biometric anchor, representing the digital equivalent of a physical wax seal. The protocol guarantees document integrity within strict stream boundaries, proves the author's authenticity, and provides pre- processed metadata for edge-parsers without increasing the token load for Large Language Models (LLMs). |
| | Stateful-TCP: Bypassing TCP Slow-Start Using Cached Per-Destination Path Bandwidth |
| |
|
This document specifies Stateful-TCP, an experimental sender-side mechanism that accelerates the startup of TCP connections by reusing path-bandwidth information estimated from earlier connections to the same destination. When a usable estimate is available, the sender bypasses Slow-Start and instead enters a paced startup phase whose initial congestion window and pacing rate are derived from the cached estimate. When no usable estimate is available, the sender falls back to standard Slow-Start. Stateful-TCP is sender-only and does not require any change to the TCP receiver or to the wire format. It is orthogonal to the congestion control algorithm in use after the first round-trip time and may therefore be combined with existing TCP variants such as CUBIC. This document also specifies a Gap-Compensated Bandwidth Estimation (GCBE) procedure used to produce the cached per- destination estimate. Stateful-TCP extends the framework of TCP Control Block Interdependence (RFC 9040) by sharing additional per-destination state across connections. The mechanism is published as Experimental to enable independent implementation, evaluation, and review. |
| | Attestation Results for Secure Interactions |
| |
| | draft-ietf-rats-ar4si-10.txt |
| | Date: |
18/05/2026 |
| | Authors: |
Eric Voit, Henk Birkholz, Thomas Hardjono, Thomas Fossati, Vincent Scarlata |
| | Working Group: |
Remote ATtestation ProcedureS (rats) |
|
This document defines reusable Attestation Result information elements. When these elements are offered to Relying Parties as Evidence, different aspects of Attester trustworthiness can be evaluated. Additionally, where the Relying Party is interfacing with a heterogeneous mix of Attesting Environment and Verifier types, consistent policies can be applied to subsequent information exchange between each Attester and the Relying Party. This document also defines two serialisations of the proposed information model, utilising CBOR and JSON. |
| |
|
| |
| | Control Plane of Source Address Validation Architecture-eXternal (SAVA-X) |
| |
| | draft-xu-savax-control-11.txt |
| | Date: |
17/05/2026 |
| | Authors: |
Ke Xu, Xiaoliang Wang, Yangfei Guo, Jianping Wu |
| | Working Group: |
Individual Submissions (none) |
|
Due to the fact that the Internet forwards packets in accordance with the IP destination address, packet forwarding generally occurs without examination of the source address. As a result, malicious attacks have been initiated by utilizing spoofed source addresses. The inter-domain source address validation architecture represents an endeavor to enhance the Internet by employing state machines to generate consistent tags. When two end hosts at different address domains (ADs) of the IPv6 network communicate with each other, tags will be appended to the packets to identify the authenticity of the IPv6 source address. |
| | Data Plane of Source Address Validation Architecture-eXternal (SAVA-X) |
| |
| | draft-xu-savax-data-10.txt |
| | Date: |
17/05/2026 |
| | Authors: |
Ke Xu, Xiaoliang Wang, Yangfei Guo, Jianping Wu |
| | Working Group: |
Individual Submissions (none) |
|
Due to the fact that the Internet forwards packets in accordance with the IP destination address, packet forwarding generally occurs without examination of the source address. As a result, malicious attacks have been initiated by utilizing spoofed source addresses. The inter-domain source address validation architecture represents an endeavor to enhance the Internet by employing state machines to generate consistent tags. When two end hosts at different address domains (ADs) of the IPv6 network communicate with each other, tags will be appended to the packets to identify the authenticity of the IPv6 source address. This memo focuses on the data plane of the SAVA-X mechanism. |
| | Communication Protocol Between the AD Control Server and the AD Edge Router of Source Address Validation Architecture-eXternal (SAVA-X) |
| |
|
Due to the fact that the Internet forwards packets in accordance with the IP destination address, packet forwarding generally occurs without examination of the source address. As a result, malicious attacks have been initiated by utilizing spoofed source addresses. The inter-domain source address validation architecture represents an endeavor to enhance the Internet by employing state machines to generate consistent tags. When two end hosts at different address domains (ADs) of the IPv6 network communicate with each other, tags will be appended to the packets to identify the authenticity of the IPv6 source address. This memo focuses on the communication protocol between ACSs and AERs of the SAVA-X mechanism. |
| | Terminal-based joint selection and configuration of MEC host and DETNET-RAW network |
| |
|
There are several scenarios involving multi-hop heterogeneous wireless networks requiring reliable and available features combined with multi-access edge computing, such as Industry 4.0. This document discusses mechanisms to allow a terminal influencing the selection of a MEC host for instantiation of the terminal-targeted MEC applications and functions, and (re)configuring the RAW network lying in between the terminal and the selected MEC host. This document assumes IETF RAW and ETSI MEC integration, fostering discussion about extensions at both IETF and ETSI MEC to better support these scenarios. |
| | Extensions to enable wireless reliability and availability in multi-access edge deployments |
| |
|
There are several scenarios involving multi-hop heterogeneous wireless networks requiring reliable and available features combined with multi-access edge computing, such as Industry 4.0. This document describes solutions integrating IETF RAW and ETSI MEC, fostering discussion about extensions at both IETF and ETSI MEC to better support these scenarios. |
| | MIPv6 DETNET-RAW mobility |
| |
|
There are several use cases where reliability and availability are key requirements for wireless heterogeneous networks in which connected devices might be mobile, such as eXtended Reality (XR). This document discusses and specifies control plane solutions to cope with mobility, by proactively preparing the network for the change of point of attachment of a connected mobile node. It also defines Mobile IPv6 extensions implementing these control plane solutions. |
| | JEP Action Mandate Profile (JEP-AMP) |
| |
|
This document defines the JEP Action Mandate Profile (JEP-AMP), a profile of the Judgment Event Protocol (JEP). JEP-AMP specifies how a JEP Delegation event can express a verifiable, bounded, revocable, and auditable mandate for an agent, human, organization, workflow, or system to perform an action on behalf of a principal. JEP-AMP does not redefine JEP-Core event verbs, signature semantics, event hash semantics, validation-level semantics, identity systems, credential systems, legal liability, regulatory sufficiency, payment clearing, or global authorization validity. JEP-AMP defines the minimum interoperable shape of an Action Mandate Descriptor and profile-level rules by which relying parties, gateways, verifiers, and receipt systems can interpret a JEP Delegation event as a candidate action mandate under a stated trust, policy, profile, and relying-party context. |
| | Multi-Vantage Path Snapshot (MVPS): A Canonical Bundle Format for Coordinated Traceroute Measurements |
| |
|
This document specifies the Multi-Vantage Path Snapshot (MVPS) bundle format, a focused envelope for traceroute observations collected in coordination from two or more network vantages towards a common destination. MVPS defines a JSON serialization, a YANG 1.1 module, and a deterministic path-fingerprint algorithm enabling bit- reproducible auditing and cross-implementation interoperability. MVPS is intentionally minimal in scope: it specifies a wire format and the algorithms required to produce it deterministically. Analytical metrics derived from MVPS bundles are out of scope. MVPS complements the AURA architecture defined by RFC 9198, which specifies a measurement architecture but does not normatively specify the result format. MVPS is intended as one possible result format for AURA-style coordinated measurements. MVPS is also positioned relative to existing single-operator reporting formats (RIPE Atlas measurement JSON, CAIDA warts), which are not standardised and which do not provide a deterministic cross-implementation path identity. |
| | Continuity Envelope Protocol |
| |
|
This document defines the Continuity Envelope Protocol (CEP), a transport-agnostic protocol model for identity-bound messaging systems where delivery alone is not sufficient. CEP separates a visible envelope surface from sealed internal object truth and defines how receivers determine whether a delivered object may safely and legitimately continue. The protocol distinguishes between control-plane notification, data-plane object carriage, and decision-plane continuation handling. CEP is the umbrella model for companion drafts such as TIBET TAT, which specifies generic sealed handoff and transfer flow, and IDDrop, which profiles that handoff model for identity transfer. |
| | IDDrop: Identity Drop and Acceptance Protocol |
| |
|
This document specifies IDDrop, an identity-transfer protocol for moving identity claims, actor claims, and receiver-bound claim bundles across human-facing and machine-facing environments. IDDrop defines two complementary operating modes: offer-first, intended for proximity and human-in-the-loop workflows, and request- first, intended for autonomous systems, daemon-to-daemon exchange, and policy-driven machine identity transfer. IDDrop does not treat filenames or user-visible extensions as identity truth. Instead, it binds identity transfer to sealed carrier truth, semantic classification, actor provenance, receiver targeting, and causal validation. This document profiles the generic TIBET TAT handoff model for trustworthy identity transfer. |
| | TIBET TAT: Touch-and-Transfer Protocol |
| |
|
This document specifies TIBET TAT, a Touch-and-Transfer protocol for moving sealed continuity-bearing objects across proximity, relay, and local-network handoff lanes. TAT defines a consent-bound handoff model, a seed exchange for tunnel establishment, encrypted chunk streaming, and mutual transfer anchoring between sender and receiver. TAT does not define identity truth, semantic class, or sealed object class by itself. Instead, it defines the wire and handoff layer that carries such objects once sender and receiver have agreed to transfer. TAT is intended to sit between the Continuity Envelope Protocol (CEP) and higher-level application profiles such as IDDrop. |
| | Metadata and Query Profile for Efficient Agent Discovery |
| |
|
This document defines a metadata and query profile for efficient discovery of autonomous software agents. The profile describes how agents publish capability metadata using explicit tags, natural- language descriptions, example tasks, protocol bindings, and operational constraints. It also defines JSON metadata, discovery request, and discovery response objects that enable discovery services to combine structured filtering, semantic retrieval, and fine-grained matching while preserving an interoperable protocol surface. The profile does not mandate a specific machine-learning model, embedding model, database, or ranking algorithm. Instead, it standardizes the metadata and result evidence needed by clients and discovery services so that different implementations can interoperate while optimizing their own latency, scalability, and ranking quality. |
| | Architecture for Agentic Overlay Networks |
| |
|
This document describes an architecture for agentic overlay networks. The architecture enables autonomous software agents, agent gateways, registries, discovery services, and enterprise service hubs to interoperate across administrative domains without replacing the existing Internet protocol stack. The architecture separates control-plane coordination from runtime agent interaction. Management root nodes coordinate trust anchors, semantic taxonomies, and network-wide policy. Registry service nodes onboard agents and publish signed capability metadata. Discovery service nodes provide intent-driven candidate selection. Enterprise service hubs adapt private systems and legacy interfaces into agent- compatible capabilities. After discovery, runtime authentication and execution are performed by the invoking and target endpoints, which can be agents or gateways, using mutual verification; discovery and management nodes are not required in the runtime path. This document defines architectural roles, functional boundaries, metadata expectations, operational workflows, and security considerations for such networks. It does not define a new transport protocol, a new URI scheme, or a mandatory discovery ranking algorithm. |
| |
|
| |
| | Automated Certificate Management Environment (ACME) DNS Labeled With ACME Account ID Challenge |
| |
| | draft-ietf-acme-dns-account-label-03.txt |
| | Date: |
15/05/2026 |
| | Authors: |
Antonis Chariton, Amir Omidi, James Kasten, Fotis Loukos, Stanislaw Janikowski |
| | Working Group: |
Automated Certificate Management Environment (acme) |
|
This document outlines a new DNS-based challenge type for the ACME protocol that enables multiple independent systems to authorize a single domain name concurrently. By adding a unique label to the DNS validation record name, the dns-account-01 challenge avoids CNAME delegation conflicts inherent to the dns-01 challenge type. This is particularly valuable for multi-region or multi-cloud deployments that wish to rely upon DNS-based domain control validation and need to independently obtain certificates for the same domain. |
| | BMP Extension for Path Status TLV |
| |
|
The BGP Monitoring Protocol (BMP) provides an interface for obtaining BGP path information, which is conveyed through BMP Route Monitoring (RM) messages. This document specifies a BMP extension to convey the status of a path after being processed by the BGP process. |
| | JMAP File Storage extension |
| |
|
The JMAP base protocol (RFC8620) provides the ability to upload and download arbitrary binary data. This binary data is called a "blob", and can be used in all other JMAP extensions. This extension adds a method to expose blobs as a filesystem along with the types of metadata that are provided by other remote filesystem protocols. |
| | Resource Allocation Model for Hybrid Switching Networks |
| |
|
The fast increase in traffic volumn within and outside Datacenters is placing an unprecendented challenge on the underline network, in both the capacity it can provide, and the way it delivers traffic. When a large portion of network traffic is contributed by large flows, providing high capacity and slow to change optical circuit switching along side fine-granular packet services may potentially improve network utility and reduce both CAPEX and OpEX. This gives rise to the concept of hybrid switching - a paradigm that seeks to make the best of packet and circuit switching. However, the full potential of hybrid switching networks (HSNs) can only be realized when such a network is optimally designed and operated, in the sense that "an appropriate amount of resource is used to handle an appropriate amount of traffic in both switching planes." The resource allocation problem in HSNs is in fact complex ineractions between three components: resource allocation between the two switching planes, traffic partitioning between the two switching planes, and the overall cost or performance constraints. In this memo, we explore the challenges of planning and operating hybrid switching networks, with a particular focus on the resource allocation problem, and provide a high-level model that may guide resource allocation in future hybrid switching networks. |
| | Network File System version 4.2 COPY Operation Implementation Experience |
| |
|
This document describes the authors' experience implementing the NFSv4.2 COPY operation. It recommends and motivates updates to the specification of that operation. This is not a normative document. |
| | Authenticated Modes for HPKE |
| |
|
The standards-track [I-D.ietf-hpke-hpke] supersedes the informational [RFC9180], omitting its authenticated modes mode_auth and mode_auth_psk. This document restores mode_auth_psk mode as a strict extension and illustrates how the restored mode can be used with a post-quantum "shared secret" as the PSK in order to achieve hybrid PQ/T confidentiality while transitioning to quantum-resistant encryption, without deprecating the classical implicit authentication on which many applications still rely. This extension requires only the addition of AuthEncap()/AuthDecap() to the DHKEM, the definition of four setup functions, and a change in VerifyPSKInputs(). The extension does not alter the externally observable behavior of the existing HPKE modes standardized in [I-D.ietf-hpke-hpke]. Although AuthEncap()/AuthDecap() reintroduce the functionality of mode_auth, the mode itself is not restored, since it cannot provide quantum resistance. This document discusses the transitional nature of the AuthPSK construction and its security properties as a transitional step towards quantum resistance. In particular, this document illustrates how the restored mode_auth_psk can be used to provide ready-made KEM combiner-like functionality ([I-D.ounsworth-cfrg-kem-combiners]) without requiring downstream API users to manage their own encryption context. |
| | EVPN Unreachability Signaling |
| |
|
This document defines a new EVPN Route Type for signaling prefix unreachability information without affecting the forwarding plane. The route type reuses the Route Type 5 (IP Prefix Advertisement) field order defined for EVPN IP prefix routes, adds an Address Family octet for unambiguous IPv4/IPv6 parsing, and appends Reporter TLVs that allow aggregation of unreachability reports from multiple network vantage points. |
| | Proof of Stateful Integrity (PSI) for Vulnerable Populations |
| |
|
This document specifies the PSI-04 Protocol, a cryptographic framework for establishing the Proof of Stateful Integrity (PSI) for data involving vulnerable subjects (e.g., Clinical Trial participants, NDIS recipients, and Aged Care residents). The protocol mandates a verifiable "Chain of State" that prevents post-hoc data manipulation by ensuring the final submission is mathematically anchored to the point of inception. PSI-04 utilizes Ed25519 signatures canonicalized via RFC 8785 and verified through a 3-node Multi-Party Computation (MPC) consensus mechanism. |
| | Proof of Sequential Memory Execution (PoSME) |
| |
|
This document defines Proof of Sequential Memory Execution (PoSME), a cryptographic primitive combining mutable arena state, data- dependent pointer-chase addressing, and per-block causal hash binding in a single step function. A Prover executes K sequential steps over a mutable N-block arena. Each step reads d blocks at addresses determined by the previous read's result (pointer chasing), writes one block with spatial neighborhood entanglement (incorporating A\[w-1\] and A\[w+1\]), and advances a transcript chain. The construction provides three properties: (1) unconditional sequential time enforcement anchored in physics-bounded latency floors, (2) forgery prevention via causal hashes (reduces to collision resistance of H), and (3) TMTO resistance scaling as $1/\alpha$ with spatial entanglement, where $\alpha$ is the adversary's storage fraction. Verification requires O(Q * d^R * log N) hash evaluations with no arena allocation. No trusted setup is required. |
| | Privacy Pass Token Expiration Extension |
| |
|
This document describes an extension for Privacy Pass that allows tokens to encode expiration information. |
| |
|
| |
| | Post-Quantum Enhancements to TLS-Based EAP Methods |
| |
|
This document proposes enhancements to TLS-based EAP methods, including the Extensible Authentication Protocol with Transport Layer Security (EAP-TLS), EAP Tunneled TLS (EAP-TTLS), Protected EAP (PEAP), and EAP Tunnel Method (TEAP), to incorporate post-quantum cryptographic mechanisms. It also addresses challenges related to large certificate sizes and long certificate chains, as identified in [RFC9191], and provides recommendations for integrating PQC algorithms into TLS-based EAP deployments. |
| | Reliability in AI Networks Gap Analysis,Problem Statement,and Requirements |
| |
|
This document provides the gap analysis of existing reliability mechanism in AI networks, describes the fundamental problems, and defines the requirements for technical improvements. |
| | IGP Extensions for Optimized SRv6 SID Advertisement |
| |
|
When the IGP runs SRv6 Flex-Algo or performs QoS resource allocation, it needs to assign a large number of END.X SIDs, which can significantly impact IGP LSDB advertisements and overall performance. This document proposes a simplified method for advertising a large number of SRv6 SIDs. This method is particularly useful in scenarios that require generating many END.X SIDs, such as when supporting numerous Flex-Algo algorithms. It helps reduce the size of LSDB advertisements and improves IGP advertisement efficiency and operational performance. |
| | ML-KEM Security Considerations |
| |
|
NIST standardized ML-KEM as FIPS 203 in August 2024. This document discusses how to use ML-KEM within protocols - that is, what problem it solves, and what you need to do to use it securely. |
| | Operations,Administration and Maintenance (OAM) for Network Resource Partition (NRP) in SR |
| |
|
A Network Resource Partition (NRP) represents a subset of network resources and associated policies within the underlay network. This document describes the implementation of the Operations, Administration, and Maintenance (OAM) mechanism for NRPs in Segment Routing (SR) networks. By extending existing OAM mechanisms such as ping, traceroute, Bidirectional Forwarding Detection (BFD), and Simple Two-way Active Measurement Protocol (STAMP), the proposed solution enables comprehensive NRP support in SR networks. |
| | Secure Webhook Token (SWT) |
| |
|
The Secure Webhook Token (SWT) is a specialized JSON Web Token (JWT) format designed for securely authorizing and verifying webhook requests. It defines a set of claims to ensure that the token is explicitly tied to webhook events and that its integrity can be reliably validated by the recipient. A key feature of SWT is the introduction of a unique claim, webhook, which encapsulates webhook- specific information, such as the event type. By providing a structured and secure approach to webhook authentication, SWT aims to be a lightweight and flexible solution while maintaining compatibility with typical JWT structures. It is designed with the best practices in mind and may serve as a foundation for future standardization efforts. |
| | SRv6 SFC Deployment Options |
| |
|
This document mainly introduces the factors to consider for supporting SRv6 SFC from the aspects of deployment and reliability methods. |
| | Operating Model Protocol (OMP) Core -- Version 02: Invariant 3 -- Verifiable Delegation Binding |
| |
| | draft-veridom-omp-02.txt |
| | Date: |
13/05/2026 |
| | Authors: |
Tolulope Adebayo, Oluropo Apalowo |
| | Working Group: |
Individual Submissions (none) |
|
This document obsoletes draft-veridom-omp-00. The Operating Model Protocol (OMP) defines a deterministic routing and tamper-evident evidence architecture for consequential AI decisions. This document specifies OMP Core version 01, which adds Invariant 3: Verifiable Delegation Binding. Every ASSISTED or ESCALATED routing state must bind the Named Accountable Officer to a verifiable DelegationInstrument at the time of decision. When valid binding cannot be established, the system records AUTHORITY_UNBOUND -- a sealed, positive evidentiary state. This update is additive and backward-compatible with OMP Core version 00. |
| | Consideration of Applying Zero Trust Philosophy in Network Infrastructure |
| |
|
Network security has traditionally relied on a perimeter-centric model, assuming that traffic originating within the network can be implicitly trusted. This model is fundamentally challenged by modern, highly distributed, and software-driven network environments where internal compromise is a realistic and high-impact threat scenario. This document examines the critical limitations of edge- only network protection and the systemic risks that arise from insufficient internal validation. Once the network perimeter is bypassed, the absence of internal protection mechanisms facilitates rapid lateral movement, impersonation of network entities, and interference with critical control and management functions. The document argues that Zero Trust (ZT) principles, which mandate continuous, dynamic verification of all entities and communications regardless of network location, are necessary to address contemporary threat models. Deploying ZT-aligned network protection mechanisms beyond the network edge is essential to build resilient, controllable, and trustworthy networks. |
| | Operating Model Protocol (OMP) Core: Invariant 3 -- Verifiable Delegation Binding |
| |
|
This document obsoletes draft-veridom-omp-00. The Operating Model Protocol (OMP) defines a deterministic routing and tamper-evident evidence architecture for consequential AI decisions. This document specifies OMP Core, which adds Invariant 3: Verifiable Delegation Binding. Every ASSISTED or ESCALATED routing state must bind the Named Accountable Officer to a verifiable DelegationInstrument at the time of decision. When valid binding cannot be established, the system records AUTHORITY_UNBOUND -- a sealed, positive evidentiary state. This update is additive and backward-compatible with OMP Core version 00. |
| | Wallet State Attestation: Signed Booleans about On-Chain State |
| |
|
This document defines Wallet State Attestation: a primitive in which an issuer reads on-chain state for a wallet address, evaluates one or more operator-defined conditions, and returns a cryptographically signed boolean (or structured fact profile) that any verifier can check offline using a published JWKS endpoint. The primitive enables condition-based access decisions without identity presentation, credential exchange, or trust in the issuer at runtime. This document describes the request and response surface, the signing algorithm posture, the JWKS discovery pattern, and the security and privacy considerations of the primitive. It does not define a new wire protocol; rather, it profiles existing IETF building blocks (JWT, JWKS, JOSE) for the wallet-state-attestation use case. |
| | A YANG Data Model for Segment Routing (SR) Policy and SR in IPv6 (SRv6) support in Path Computation Element Communications Protocol (PCEP) |
| |
| | draft-ietf-pce-pcep-srv6-yang-09.txt |
| | Date: |
13/05/2026 |
| | Authors: |
Cheng Li, Siva Sivabalan, Shuping Peng, Mike Koldychev, Luc-Fabrice Ndifor |
| | Working Group: |
Path Computation Element (pce) |
|
This document augments a YANG data model for the management of Path Computation Element Communications Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs in support for Segment Routing in IPv6 (SRv6) and SR Policy. The data model includes configuration data and state data (status information and counters for the collection of statistics). |
| | The PrivateToken HTTP Authentication Scheme Extensions Parameter |
| |
|
This document specifies new parameters for the "PrivateToken" HTTP authentication scheme, called extensions. The purpose of these extensions is to negotiate and carry public metadata for Privacy Pass protocols. |
| | Privacy Pass Issuance Protocols with Public Metadata |
| |
|
This document specifies Privacy Pass issuance protocols that encode public information visible to the Client, Attester, Issuer, and Origin into each token. |
| | Trust and security considerations for Structured Email |
| |
|
This document discusses trust and security considerations for structured email and provides recommendations for message user agents on how to deal with structured data in email messages. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Structured Email Working Group mailing list ([email protected]), which is archived at https://mailarchive.ietf.org/arch/browse/sml/. Source for this draft and an issue tracker can be found at https://github.com/arnt/sml-trust. |
| |
|
| |
| | BGP MultiNexthop Attribute |
| |
|
Today, a BGP speaker can advertise one nexthop for a set of NLRIs in an Update message. This nexthop can be encoded in either the top- level BGP-Nexthop attribute (code 3), or inside the MP_REACH_NLRI attribute (code 14). Forwarding information related to the nexthop is scattered across various attributes, extended communities or the NLRI field. This document defines a new optional non-transitive BGP attribute called "MultiNexthop (MNH)" with IANA code TBD. The MNH provides two things: it allows carrying the Nexthop and related forwarding information in one BGP attribute. The MNH also enables carrying an ordered set of multiple Nexthops in the same attribute, with forwarding information scoped on a per Nexthop basis. |
| | Binary Application Record Encoding (BARE) |
| |
|
The Binary Application Record Encoding (BARE) is a data format used to represent application records for storage or transmission between programs. BARE messages are concise and have a well-defined schema, and implementations may be simple and broadly compatible. A schema language is also provided to express message schemas out-of-band. Comments Comments are solicited and should be addressed to the mailing list at ~sircmpwn/[email protected] and/or the author(s). |
| | RADIUS over QUIC |
| |
|
The Remote Authentication Dial-In User Server (RADIUS) Protocol can use the User Datagram Protocol (UDP) and the Transport Control Protocol (TCP) as its underlying transport layer. But it permits TCP to be used as a transport protocol for RADIUS only when a transport layer such as TLS or IPsec provides confidentiality and security. QUIC inherently supports encryption (using TLS 1.3), which could provide a higher level of security. And QUIC supports multiple streams over a single connection, enhancing throughput and efficiency. This document defines RADIUS over the QUIC transport protocol, named RADIUSoQUIC. |
| | TIBET Causal Time Substrate |
| |
|
This document describes the TIBET Causal Time Substrate, a forward- only causal ordering model for identity-bound distributed systems. TIBET does not treat wall-clock time as the primary ordering primitive. Instead, it uses a cryptographically bound logical-time structure encoded through append-only linkage, monotonic generation counters, and signed causal references. External wall-clock sources, including NTP, RFC 3161 timestamping services, Roughtime, GNSS, or public ledger timestamps, are treated as auxiliary alignment anchors rather than as the constitutive source of event order. The core claim is simple: TIBET is a forward-only causal substrate that enables recovery and reversibility without rewriting history. |
| | TIBET Semantic Surface Manifest |
| |
|
This document defines the Semantic Surface Manifest, a human-readable and policy-matchable routing layer for identity-bound continuity containers and TBZ-based sealed bundles. The Semantic Surface Manifest exposes limited dispatch metadata such as time fragment, context, profile, and priority without exposing sealed content. It is intended for use in systems where routing decisions may need to occur before deep inspection, while trust remains anchored in intrinsic bundle properties such as magic bytes, manifests, hashes, signatures, and causal references. In short: address visible, content sealed. |
| | Use of Composite FN-DSA Signatures in TLS 1.3 |
| |
|
Compositing the post-quantum FN-DSA signature with traditional signature algorithms provides protection against potential breaks in either component. This document specifies how such a composite signature can be used for authentication in TLS 1.3. The selection of composite algorithms is intentionally chosen to strictly mirror the composite strategies for ML-DSA. This alignment provides two distinct and predictable security tiers for hybrid signatures, ensuring a consistent approach to post-quantum transition across the ecosystem. |
| | BMP Statistics Information TLV |
| |
|
The BGP Monitoring Protocol (BMP) defines statistics reports that provide periodic snapshots of various BGP-related metrics. When statistics are reported periodically, the snapshot values may not reflect the variations that occurred between reporting intervals. This document defines a Statistics Information TLV that can be used to convey additional statistical information about BMP gauge-type statistics during the reporting period. This TLV reports the minimum and maximum values observed (with timestamps indicating when they occurred), along with additional statistical measures such as average, median, or snapshot values. This enables BMP collectors to better understand the dynamics of monitored statistics even when the reported snapshot values appear constant. |
| | A YANG Data Model for requesting path computation |
| |
|
In certain scenarios — particularly within hierarchical Software- Defined Networking (SDN) environments—the topology information provided by a Traffic Engineering (TE) network provider may be insufficient for a client to perform end-to-end multi-domain path computation. In such cases, the client may need to delegate the computation of specific intra-domain paths to the TE provider, leveraging the resulting path segments to construct optimal multi- domain end-to-end paths. This document defines a mechanism to enable path computation requests by augmenting the Remote Procedure Calls (RPCs) specified in RFC YYYY. The augmented RPCs support path computation on demand, allowing clients to request intra-domain TE path computations from the provider while maintaining control over inter-domain path selection. Additionally, this document outlines several use cases in which such path computation requests are beneficial, particularly in environments where YANG-based management protocols—such as NETCONF or RESTCONF—are used for network automation and control. |
| |
|
| |
| | BGP Extension for SR-MPLS Entropy Label Position |
| |
|
This document proposes extensions for BGP to indicate the entropy label position in the SR-MPLS label stack when delivering SR Policy via BGP. |
| | Hewlett Packard Enterprise's Secure Vector Routing (SVR) |
| |
| | draft-menon-svr-08.txt |
| | Date: |
10/05/2026 |
| | Authors: |
Abilash Menon, Patrick MeLampy, Michael Baj, Patrick Timmons, Hadriel Kaplan |
| | Working Group: |
Individual Submissions (none) |
|
This document describes Hewlett Packard Enterprise's Secure Vector Routing (SVR), an overlay inter-networking protocol that operates at the session layer. SVR conveys end-to-end network requirements that cannot be expressed in network-layer headers by carrying application- layer cookies in the first packet of a session, eliminating the need for tunnel encapsulation and for non-overlapping underlay address spaces. SVR traverses middleboxes and address translators between private networks, the IPv4 public Internet, and the IPv6 public Internet, and supports SD-WAN, multi-cloud, multicast, and dual-stack use cases while improving security at the routing plane. |
| | Network-based mobility management in CATS network environment |
| |
|
Computing-Aware Traffic Steering (CATS) network architecture is to choose the best edge computing server by considering both the network environment and available computing/storage resources of the edge computing server. This draft describes the mechanism in which service continuity is provided even when the client moves and connects to a new ingress CATS-Router by using the PMIPv6-based mobility management method in the CATS-based edge computing networking environment. |
| | WebTransport over WebSocket |
| |
|
WebTransport [OVERVIEW], a protocol framework within the Web security model, empowers Web clients to initiate secure multiplexed transport for low-level client-server interactions with remote servers. This document outlines a protocol, based on WebSocket [WEBSOCKET], offering WebTransport capabilities similar to the HTTP/2 variant [WEBTRANSPORT-H2]. It serves as an alternative when UDP-based protocols are inaccessible, and the client environment exclusively supports WebSocket [WEBSOCKET]. |
| | The HiAE Authenticated Encryption Algorithm |
| |
| | draft-pham-cfrg-hiae-06.txt |
| | Date: |
10/05/2026 |
| | Authors: |
Frank Denis, Pham Phuong, Lucas Prabel, Sun Shuzhou |
| | Working Group: |
Individual Submissions (none) |
|
This document describes HiAE, a high-throughput authenticated encryption algorithm designed for next-generation wireless systems (6G) and high-speed data transmission applications. 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/hiae-aead/draft-pham-hiae. |
| | The PRF Protocol |
| |
|
This document describes the PRF protocol ("Prf is Reversed Frp"), a lightweight, binary-length-prefixed TCP relay messaging protocol. PRF enables peer-to-peer tunneling of TCP connections through a public middle relay node, originally designed for Minecraft multiplayer sessions behind NAT or firewall environments. The protocol defines three roles - Server, Client, and Middle - and a set of four wireframe message types for room registration, connection requests, worker handoff, and direct Minecraft client handshake parsing. |
| | Wire-format Alerting for Risk Notification |
| |
|
This document describes WARN, a transport-agnostic compact binary wire protocol used for emergency alerts under constrained hardware and lossy networks. It is designed to reach farther and quicker than OASIS CAP, which tries to deliver full human-readable information at the cost of complexity. It primarily uses fixed fields, with support for TLVs when more expressiveness is required. It also has a mandatory signature to prevent fake alerts propagating through a mesh. |
| | Protocol Information Over Air |
| |
|
This protocol transmits information over the air, marking fast and big download speeds. |
| | Top Level Domain Transition Operational Practices |
| |
|
This document describes the process for Top-Level Domain(TLD) registries to switch their Back-End Registry Operator(BERO), including migration requirements, data changes, and operational procedures. This document applies to scenarios where the name service of certain TLD is migrated between different BERO, and the TLD has implemented DNSSEC. |
| |
|
| |
| | A YANG Data Model for In Situ Operations,Administration,and Maintenance (IOAM) Integrity-Protected Options |
| |
|
In Situ Operations, Administration, and Maintenance (IOAM) is an example of an on-path hybrid measurement method to collect operational and telemetry information. The collected data may then be exported to systems that will use it to, e.g., monitor, measure, or (re)configure the network. Integrity Protection of In Situ Operations, Administration, and Maintenance (IOAM) Data Fields (RFC YYYY) defines IOAM Options with integrity protection, also called Integrity-Protected Options. This document defines a YANG data model for the management of these Integrity-Protected Options. The document also defines an IANA-maintained YANG module for IOAM Integrity Protection Methods. |
| | The ARK Identifier Scheme |
| |
| | draft-kunze-ark-43.txt |
| | Date: |
08/05/2026 |
| | Authors: |
John Kunze, Emmanuelle Bermes |
| | Working Group: |
Individual Submissions (none) |
|
The ARK (Archival Resource Key) naming scheme is designed to facilitate the high-quality and persistent identification of information objects. The label "ark:" marks the start of a core ARK identifier that can be made actionable by prepending the beginning of a URL. Meant to be usable after today's networking technologies become obsolete, that core should be recognizable in the future as a globally unique ARK independent of the URL hostname, HTTP, etc. A founding principle of ARKs is that persistence is purely a matter of service and neither inherent in an object nor conferred on it by a particular naming syntax. The best any identifier can do is lead users to services that support robust reference. A full-functioning ARK leads the user to the identified object and, with the "?info" inflection appended, returns a metadata record and a commitment statement that is both human- and machine-readable. Tools exist for minting, binding, and resolving ARKs. Responsibility for this Document The ARK Alliance Technical Working Group [ARKAtech] is responsible for the content of this Internet Draft. The group homepage lists monthly meeting notes and agendas starting from March 2019. Revisions of the spec are maintained on github at [ARKdrafts]. |
| | MTA Hooks: An HTTP-Based Mail Processing Protocol |
| |
|
This document specifies MTA Hooks, an HTTP-based protocol enabling Mail Transfer Agents (MTAs) to delegate message processing decisions to external services. MTA Hooks provides a modern alternative to legacy mail filtering protocols by leveraging ubiquitous HTTP infrastructure, supporting both JSON and CBOR serialization, and offering fine-grained capability negotiation. The protocol supports both inbound message reception and outbound message delivery scenarios, allowing external scanners to inspect messages, modify content, and influence routing decisions at various stages of mail processing. |
| | TRIP: Trajectory-based Recognition of Identity Proof |
| |
|
This document specifies the Trajectory-based Recognition of Identity Proof (TRIP) protocol, a decentralized mechanism for establishing claims of physical-world presence through cryptographically signed, spatially quantized location attestations called "breadcrumbs." Breadcrumbs are chained into an append-only log, bundled into verifiable epochs, and distilled into a Trajectory Identity Token (TIT) that serves as a persistent pseudonymous identifier. The protocol employs a Criticality Engine grounded in statistical physics to distinguish biological movement from synthetic trajectories. Power Spectral Density (PSD) analysis detects the 1/f signature of Self-Organized Criticality in human mobility through the PSD scaling exponent alpha. A six-component Hamiltonian energy function scores each breadcrumb against the identity's learned behavioral profile in real time. This revision (-03) addresses three areas identified through expert review by researchers in the statistical physics community: it replaces informal terminology with standard spectral analysis nomenclature; it provides the analytical and numerical bridge between the Levy flight displacement exponent and the PSD scaling exponent; and it introduces a convergence analysis framework for quantifying the minimum trajectory length required for reliable single-trajectory classification. Additionally, this revision removes Passive Verification mode entirely, requiring all Attestation Results to be bound to Relying Party nonces via the Active Verification Protocol. TRIP is designed to be transport-agnostic and operates independently of any particular naming system, blockchain, or application layer. |
| | ZI2 Certified Email Server Attestation Protocol |
| |
|
This document specifies the ZI2 Certified Email Server Attestation Protocol, a mechanism for cryptographic attestation of email origin at the mail server level. Unlike existing email authentication protocols (SPF, DKIM, DMARC), which operate at the domain level, ZI2 Certified operates at the server-instance level, enabling definitive identification of the specific server that dispatched a given email message. The protocol introduces two custom mail headers, a DNS TXT record publication format, a graduated trust model with four levels, and an integration interface for AI-based email classification systems. The protocol operates complementarily to existing email authentication infrastructure and introduces an ARC-Delegated Trust mechanism to preserve origin attestation across legitimate transit modifications. |
| | Agent Directory |
| |
|
This document defines the Agent Directory (AD), a service where agents register their identity, capabilities, and reachable endpoints and where clients discover them by capability. The AD adapts the Constrained RESTful Environments (CoRE) Resource Directory (RFC 9176) from constrained IoT devices to software agents, reusing its registration, lookup, and soft-state lifecycle model. The AD uses HTTP and JSON. MCP and A2A define how agents interact; this document defines how they are found. |
| | Lossless ECMP Convergence Based on LD/RD Degradation Signal Propagation |
| |
|
This document describes a mechanism for achieving lossless Equal-Cost Multi-Path (ECMP) convergence by utilizing the propagation of Local Degrade (LD) and Remote Degrade (RD) signals defined in the Physical Coding Sublayer (PCS) layer of IEEE 802.3. The mechanism enables proactive ECMP path switching upon detection of link degradation, before an actual link failure occurs, thereby preventing packet loss during routing convergence. |
| | Use of the ILNP Nonce Destination Option Header |
| |
|
The Identifier Locator Network Protocol (ILNP) for IPv6 is described in Experimental RFCs 6740-6744. ILNP packets for IPv6 are distinguished from normal IPv6 packets by the presence of the Nonce Destination Option Header (aka Nonce Header), as defined in RFC6744. This document clarifies the use of the Nonce Header for ILNP. This document updates RFC6740, RFC6741, RFC6744. |
| | ILNP usage by IPv6 applications |
| |
|
The Identifier Locator Network Protocol (ILNP) for IPv6 is described in Experimental RFCs 6740-6744. ILNP uses a different architecture to IPv6 but is implemented to work with IPv6. This document describes how unmodified IPv6 applications running on an ILNP-capable node can make use of ILNP. This document updates RFC6740, RFC6741, RFC6748. |
| | ILNP addressing using Preference values |
| |
|
The Identifier Locator Network Protocol (ILNP) for IPv6 is described in Experimental RFCs 6740-6744. This document clarifies how addressing in ILNP makes use of Preference values with Locator (L64) and Node Identifier (NID) values. This includes the way that Preference values are used for forming Identifier-Locator Vector (I-LV) values, and selecting I-LVs for use. This document updates RFC6740, RFC6741, RFC6742, RFC6748. |
| | ILNP textual representations |
| |
|
The Identifier Locator Network Protocol (ILNP) for IPv6 is described in Experimental RFCs 6740-6744. This document describes how values for ILNP data-types SHOULD be represented in textual form. These data-types are: the Locator (L64), the Node Identifier (NID), and the Identifier-Locator Vector (I-LV). The notation for the textual representation is defined formally. Use-cases are provided as examples of real world usage. This document updates RFC6740, RFC6741, RFC6742. |
| | Verifiable Usage Accounting for Internet of Agents |
| |
|
This document describes a usage accounting and evidence framework for the Internet of Agents (IoA). In cross-domain agent collaboration, agents may attach to gateways, discover capabilities, delegate subtasks, invoke tools, consume model or compute resources, and produce auditable outcomes. Existing application logs or platform- specific billing interfaces are insufficient for interoperable accounting across agents, gateways, and administrative domains. This document defines requirements and a common object model for verifiable usage accounting, including Accounting Contexts, Metering Profiles, Measurement Dimensions, Usage Event Records, and Accounting Evidence References. These objects are intended to support interoperable recording, correlation, export, verification, correction, and dispute handling for agent collaboration events. This document does not define pricing, charging policy, token issuance, financial settlement, revenue-sharing rules, invoices, or business support system interfaces. It focuses on protocol-visible accounting records and evidence objects that may be used by other systems. |
| |
|
| |
| | LISP Multicast Deployment Experience |
| |
| | draft-ietf-lisp-multicast-deploy-00.txt |
| | Date: |
07/05/2026 |
| | Authors: |
Vengada Govindan, Marcin Hamroz, Jaroslaw Gawron, Junyi Zhang, Romans Fomicevs |
| | Working Group: |
Locator/ID Separation Protocol (lisp) |
|
We present our experiences in supporting deployments of LISP Multicast using unicast and multicast underlays. This document details design considerations that can be useful for anyone interested in deploying LISP multicast services over IP networks. |
| | Partial MLS |
| |
| | draft-ietf-mls-partial-02.txt |
| | Date: |
07/05/2026 |
| | Authors: |
Franziskus Kiefer, Karthikeyan Bhargavan, Richard Barnes, Joel, Marta Mularczyk |
| | Working Group: |
Messaging Layer Security (mls) |
|
The Messaging Layer Security (MLS) protocol provides efficient asynchronous group key establishment for large groups with up to thousands of clients. In MLS, any member can commit a change to the group, and consequently, all members must download, validate, and maintain the full group state, which can incur a significant communication and computational costs, especially when joining a group. This document defines an MLS extension to support "partial MLS clients" that don't undertake these costs. A partial client cannot commit changes to the group, and only has partial authentication information for the other members of the group, but is otherwise able to participate in the group. In exchange for these limitations, a partial MLS client can participate in an MLS group with significantly lower requirements in terms of download, memory, and processing. |
| | Problem Statement for Cross-Layer Vulnerabilities due to Forged ICMP Errors |
| |
|
ICMP error messages are vital for network reliability, providing feedback on issues such as unreachable hosts or fragmentation requirements. They help devices adapt dynamically, support troubleshooting, and enable essential functions like Path MTU Discovery. However, off-path attackers on the Internet may forge ICMP error messages to bypass legitimate validation mechanisms, causing the victim's TCP/IP stack to misinterpret network conditions and exposing critical vulnerabilities. This document analyzes how such forged ICMP errors can be exploited by off-path attackers to induce cross-layer interactions within the victim's TCP/IP stack, leading to four classes of vulnerabilities: information leakage, desynchronization of shared variables, semantic gaps, and identity deception. These ICMP-based attacks allow off-path attackers to manipulate network traffic, disrupt communication flows, and compromise both infrastructure and user privacy, without being on the direct communication path. The document concludes with proposed countermeasures and recommendations for protocol evolution. |
| | Fast Network Notifications Problem Statement |
| |
| | draft-ietf-rtgwg-net-notif-ps-02.txt |
| | Date: |
07/05/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: |
Individual Submissions (none) |
|
Many network applications, ranging from Artificial Intelligence (AI) /Machine Learning (ML) training or inference to cloud services, require high bandwidth, low delay, low jitter and minimal packet loss in data transfer, which requires that the networks can be adaptive in the presence of faults, degradations, or congestion. However, existing traffic management mechanisms often face limitations in responsiveness, coverage, and operational complexity, particularly in high-speed and large-scale network environments. A good and timely understanding of network operational status 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 existing problems and the need for fast network notification. |
| | Path Computation Element Communication Protocol (PCEP) Extension for SR-MPLS Entropy Label Positions |
| |
|
Entropy label (EL) can be used in the SR-MPLS data plane to improve load-balancing and multiple Entropy Label Indicator (ELI)/EL pairs may be inserted in the SR-MPLS label stack as per RFC8662. This document proposes a set of extensions for Path Computation Element Communication Protocol (PCEP) to configure the Entropy Label Positions (ELP) for SR-MPLS networks. |
| | Path Computation Element Communication Protocol (PCEP) Extensions for Topology Filter |
| |
|
A topology filter is a data construct that is used to filter network topologies. The Path Computation Element (PCE) MUST take into account the topology related constraints during the path computation. This document proposes a set of extensions for Path Computation Element Communication Protocol (PCEP) to support the topology filter. |
| |
|
| |
| | Composite ML-KEM for use in Cryptographic Message Syntax (CMS) |
| |
|
Composite ML-KEM defines combinations of ML-KEM with RSA-OAEP, ECDH, X25519, and X448. This document specifies the conventions for using Composite ML-KEM algorithms with the Cryptographic Message Syntax (CMS) using the KEMRecipientInfo structure defined in “Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS)” (RFC 9629). |
| | A Top-level Domain for Private Use |
| |
|
This document describes the "internal" top-level domain for use in private applications. |
| | Stateless Hash-Based Signatures for Secure Shell (SSH) |
| |
|
This document describes the use of Sphincs+/SLH-DSA digital signatures, standalone and as a hybrid with Ed25519/Ed448, in the Secure Shell (SSH) protocol. |
| | Messaging Layer Security Credentials using Selective Disclosure JSON and CBOR Web Tokens |
| |
|
The Messaging Layer Security (MLS) protocol contains Credentials used to authenticate an MLS client with a signature key pair. Selective Disclosure CBOR Web Tokens (SD-CWT) and Selective Disclosure JSON Web Tokens (SD-JWT) define token formats where the holder can selectively reveal claims about itself with strong integrity protection and cryptographic binding to the holder's key. This document defines MLS credentials for both these token types. |
| | Call Placement Service (CPS) URI Certificate Extension for STI Certificates |
| |
|
This document specifies a non-critical X.509 v3 certificate extension that conveys the HTTPS URI of a Call Placement Service (CPS) associated with the telephone numbers authorized in a STIR Certificate. The extension enables originators and verifiers of STIR PASSporTs to discover, with a single certificate lookup, where Out- of-Band (OOB) PASSporTs can be retrieved. The mechanism only provides a new way to discover the URI of CPS endpoint and is fully backward compatible with existing STIR certificates and OOB APIs. |
| | AAuth Bootstrap Guidance |
| |
|
This document provides informational guidance for agent providers (APs) on enrolling agents and issuing AAuth agent tokens defined in [I-D.hardt-oauth-aauth-protocol]. It covers per-platform key handling, optional platform attestation, agent identifier strategies, and refresh patterns. The mechanisms described here are not normative protocol — they are common patterns that interoperable AP implementations can adopt or adapt. |
| | A Comprehensive Roadmap for OAuth 2.0 Standards and Drafts |
| |
|
The OAuth 2.0 ecosystem has expanded significantly since the publication of RFC 6749, resulting in a complex landscape of extensions, security best practices (BCPs), and application-specific profiles. This complexity can be daunting for implementers, architects, and security auditors. This document serves as a comprehensive roadmap to navigate this landscape. It categorizes key RFCs and active Internet-Drafts into functional areas, explains the relationships between them, and provides context on their evolution. The goal is to help readers understand the current state-of-the-art, select the appropriate specifications for their use cases, and follow the latest security best practices, while also offering a glimpse into the future directions of the framework. |
| | SFC: Self-Describing Resilient Container File Format |
| |
|
This document specifies the Self-Describing Resilient Container (SFC) file format, a general-purpose binary container format designed for reliable transmission of arbitrary file data over unreliable, bandwidth-constrained, or asynchronous channels including physical media hand-carry, multi-session transfers, and heterogeneous delivery paths. SFC encapsulates any file or directory tree into independently addressable, self-identifying chunks. Each chunk carries sufficient metadata to identify itself and verify its own integrity in isolation. Full reconstruction additionally requires a Global Header; this distinction is made explicit throughout. This document defines a Core specification and five optional Profiles: Image (SFC/P1), Split Transport (SFC/P2), HTTP Hints (SFC/P3), Preprocessing (SFC/P4), and Directory (SFC/P5). |
| | Use of FN-DSA in TLS 1.3 |
| |
|
NIST is standardizing FN-DSA as a post-quantum NTRU-lattice-based digital signature algorithm, which is expected to be published in FIPS 206. This document specifies how FN-DSA can be negotiated for authentication in TLS 1.3 via the signature_algorithms and signature_algorithms_cert extensions. |
| | Distributed Congestion Mitigation |
| |
| | draft-psenak-lsr-igp-dcm-00.txt |
| | Date: |
06/05/2026 |
| | Authors: |
Peter Psenak, Jakub Horn, Bruno Decraene, Guillaume Gryszata |
| | Working Group: |
Individual Submissions (none) |
|
This document describes the Distributed Congestion Mitigation (DCM) mechanism using the Interior Gateway Protocols (IGPs) such as IS-IS [RFC1195], OSPFv2 [RFC2328], or OSPFv3 [RFC5340]. DCM is a tactical, distributed mechanism, designed to mitigate network congestion by offloading traffic to an alternate, congestion-free paths. DCM is fully integrated in IGPs. |
| | MPEG-2 Transport Stream Packaging for Media Over QUIC Transport |
| |
|
This document extends the MOQT Streaming Format (MSF) by registering the "m2ts" packaging value for carrying MPEG-2 Transport Stream and M2TS source packets over Media Over QUIC Transport. It defines catalog fields for transport-stream track description and specifies receiver and relay behavior for joining, switching, and validating packetized streams. |
| | Framework for Normalizing Multi-Vendor Network Inputs for LLM-Assisted Network Management |
| |
|
Large Language Models (LLMs) are increasingly used to assist network management tasks such as troubleshooting, intent translation, and automation. Network operations, however, rely on data from many vendors and sources: CLI output, configuration snippets, telemetry, alarms, and vendor-specific APIs. These inputs differ in format, structure, and semantics, which makes it difficult to present a consistent interface to an LLM. This document describes a framework for standardizing such multi-vendor inputs for LLM-assisted network management. Incoming messages from multi-vendor network elements are first handled by an Input Classifier, which determines the nature of each input and assigns it to one of three categories: performance, configuration, or response, using a hybrid approach (rule-based classification first, with escalation to a Small Language Model (SLM) when rules are insufficient). The classified input is then passed to the corresponding Structurer among the Performance Structurer, Configuration Structurer, and Response Structurer, each of which produces a normalized, structured representation (typically with SLM assistance and optional confidence scoring). That structured output is fed to a Prompt Schema Generator, which creates a structured, vendor-agnostic schema and supplies schema-aligned prompts to the central LLM. This document specifies the architecture and component roles for use in design and implementation. It does not define a wire protocol; it is published for informational purposes. |
| |
|
| |
| | Encrypted ESP Echo Protocol |
| |
|
This document defines the Encrypted ESP Echo Function, a mechanism to assess the reachability of IP Security (IPsec) network paths using Encapsulating Security Payload (ESP) packets. It detects end-to-end path status by exchanging only encrypted ESP packets between IPsec peers. The Encrypted Echo message can either use existing congestion control payloads from RFC9347 or a new message format defined here, with an option to specify a preferred return path when there is more than one pair of IPsec SAs between the same set of IPsec peers. A peer can announce support using a new IKEv2 Status Notification ENCRYPTED_PING_SUPPORTED. |
| | KEM-based Authentication for TLS 1.3 |
| |
|
This document gives a construction for a Key Encapsulation Mechanism (KEM)-based authentication mechanism in TLS 1.3. This proposal authenticates peers via a key exchange protocol, using their long- term (KEM) public keys. |
| | KEM-based pre-shared-key handshakes for TLS 1.3 |
| |
|
This document gives a construction in which (long-term) KEM public keys are used in the place of TLS PSK keys, avoiding concerns that may affect systems that use symmetric-key-based PSK, such as requiring key diversification and protection of symmetric-keys' confidentiality. This mechanism is inspired by AuthKEM (and could use AuthKEM certificate public keys for resumption), but can be independently implemented. |
| | Root CA Certificate Rekeying in the Scenario of Post Quantum Migration |
| |
|
In the public key infrastructures (PKIs), root certification authority (CA) certificate rekeying is crucial to guarantee business continuity. Two approaches are given in [RFC4210] for entities which are belonging to different generations to verify each other's certificate chain. However, these approaches rely on the assumption that the old entities can be updated. In this draft, we propose a One-way Link Certificate based solution such that old entities are transparent to root CA certificate rekeying. Namely, during the overlapping lifetime of two root CA certificates, without any update in old entities, old and new entities can verify each other's certificate chain smoothly. Furthermore, the proposed solution works in both traditional PKIs, and post-quantum (PQ) PKIs, where the certificate can be pure PQ or hybrid ones. |
| | Reverso for the QUIC protocol |
| |
|
This document describes a QUIC version re-designing the layout of the QUIC protocol to avoid memory fragmentation at the receiver and allows implementers seeking a more efficient implementation to have the option to implement contiguous zero-copy at the receiver. This document describes the change from QUIC v1 required in packet formats, variable-length integers and frame formats. Everything else from QUIC v1 described in [RFC9000] is untouched. |
| | vCon Lifecycle Management using SCITT |
| |
|
This document proposes using the SCITT (Supply Chain, Integrity, Transparency, and Trust) protocol to record, communicate and coordinate the lifecycle of Virtual Conversations (vCons), which are standardized containers for conversational data like call recordings, transcripts, and chat logs. While vCons enable capturing and sharing conversation details for AI analysis and business purposes, they lack mechanisms for proving compliance with privacy regulations and consent management. SCITT addresses this by providing an immutable, append-only transparency ledger that records key lifecycle events—from vCon creation and consent management to call recording, as well as data processing and deletion—enabling entities to demonstrate regulatory compliance and maintain trust across distributed systems. The framework specifically addresses consent management challenges under regulations like GDPR and CCPA, where consent can be revoked at any time, requiring coordinated deletion across all parties that have received the vCon. By combining vCons with SCITT, organizations can build scalable, transparent governance systems that protect personal data rights while enabling responsible use of conversational data for AI and business applications. |
| | vCon World Transcription Format Extension |
| |
|
This document defines the World Transcription Format (WTF) extension for Virtualized Conversations (vCon). The WTF extension provides a standardized analysis framework for representing speech-to-text transcription data from multiple providers within vCon containers. This extension defines a comprehensive analysis format that enables consistent transcription processing, quality assessment, and interoperability across different transcription services while preserving provider-specific features through extensible fields. The WTF extension is designed as a Compatible Extension that introduces a new analysis type for transcription data without altering existing vCon semantics, ensuring backward compatibility with existing vCon implementations. |
| | SOCKS Protocol Version 4 |
| |
|
This document describes SOCKS version 4, a protocol designed to facilitate TCP proxy services across a network firewall. SOCKS operates at the session layer, providing application users with transparent access to network services on the other side of the firewall. It is application-protocol independent, allowing it to support a wide range of services, including those utilizing encryption, while maintaining minimum processing overhead by simply relaying data after initial access control checks. The protocol defines two primary operations: CONNECT for establishing outbound connections to an application server, and BIND for preparing for and accepting inbound connections initiated by an application server. |
| | SOCKS Protocol Version 4A |
| |
|
This document specifies SOCKS Protocol Version 4A, an independent protocol originated from the SOCKS Protocol Version 4. This protocol allows SOCKS clients to delegate domain name resolution to the SOCKS server. This is particularly useful in environments where the client host cannot resolve the destination host's domain name due to restrictive network policies or lack of DNS access. 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/4socks/socks4. |
| | Judgment Event Protocol (JEP) |
| |
|
This document defines the Judgment Event Protocol (JEP), a neutral verifiable event format for decision-related operations in human, organizational, software, and autonomous agent systems. JEP specifies four immutable event verbs: Judgment (J), Delegation (D), Termination (T), and Verification (V). It defines a signed JSON event structure, anti-replay fields, detached JSON Web Signature (JWS) verification over JSON Canonicalization Scheme (JCS) canonicalized payloads, event hash and reference semantics, validation levels, structured validation results, failure codes, extension handling, trust-profile interfaces, and determinability boundaries. JEP is intended to provide a global protocol-level interoperability layer for verifiable decision event records. JEP-Core does not define legal liability, authorization validity, regulatory compliance, organizational trust decisions, global identity, global truth, or mandatory support for any specific credential, identity, AI platform, agent framework, or blockchain system. --- |
| | EST Lightweight Operations |
| |
|
This document defines eight new operations for the Enrollment over Secure Transport (EST) protocol specified in RFC 7030: ucacaps, ucacert, ucacerts, ucrlinfo, ucrl, usimpleenroll, usimplereenroll, and userverkeygen. These operations deliver PKI objects, including CA certificates, certificate chains, CRLs, and enrolled certificates, as Base64-encoded DER or PEM, without the CMS encapsulation used by the corresponding EST operations in RFC 7030. The ucacaps operation enables EST clients to discover which operations the EST server supports. Eliminating the CMS wrapper for these responses reduces code size and parsing complexity. This document updates RFC 7030. |
| | JEP Profiles and Interoperability |
| |
|
This document defines optional trust profiles and interoperability bindings for the Judgment Event Protocol (JEP). JEP-Core defines the neutral event protocol. This document defines how actor identifiers, keys, credentials, authorization context, attestations, archival systems, and chain systems can be bound to JEP events without changing JEP-Core semantics. The profiles in this document are optional. A JEP-Core implementation MUST NOT require support for DID, VC, X.509, OAuth, RATS, blockchain anchoring, HJS, JAC, or any specific AI platform or agent framework. --- Companion Drafts This draft depends on draft-wang-jep-judgment-event-protocol-06. Conformance classes, schemas, test vectors, and reference-validator behavior are defined in draft-wang-jep-conformance-00. |
| | JEP Conformance and Test Suite |
| |
|
This document defines conformance classes, validation-result structure, schema requirements, test-vector categories, reference-validator behavior, and implementation testing guidance for the Judgment Event Protocol (JEP). It is a companion to draft-wang-jep-judgment-event- protocol-06. The purpose of this document is to make JEP implementations testable, interoperable, and auditable across languages, platforms, identity systems, and deployment profiles. --- |
| | MCP Aggregation Protocol (MCP-AX): Hierarchical Tool Namespace Delegation for Model Context Protocol Servers |
| |
|
This document specifies MCP-AX, an aggregation protocol for Model Context Protocol (MCP) servers. MCP-AX enables hierarchical composition of tool namespaces across heterogeneous networks of MCP servers, from cloud services to resource-constrained embedded devices. The protocol defines a master-subagent architecture directly inspired by the AgentX protocol (RFC 2741), adapted for the tool/resource model of MCP rather than the OID/MIB model of SNMP. MCP-AX introduces recursive namespace delegation, capability-aware routing, transport bridging for constrained nodes, and irreversibility-gated tool dispatch suitable for autonomous and semi- autonomous AI agent systems. |
| | Batched Token Issuance Protocol |
| |
|
This document specifies two variants of the Privacy Pass issuance protocol that allow for batched issuance of tokens. These allow clients to request more than one token at a time and for issuers to issue more than one token at a time. |
| | RPL DIS Modifications and Applications |
| |
|
This document augments [RFC6550] by defining new DODAG Information Solicitation (DIS) flags and options that enable a RPL node to exert finer control over how neighboring RPL routers respond to its DIO solicitations. In addition, this document describes several use cases that motivate these DIS extensions and illustrate scenarios in which enhanced control of DIO responses improves network efficiency, responsiveness, and robustness. |
| | Updates to SFrame Cipher Suites Registry |
| |
|
This document addresses two omissions in the Secure Frames (SFrame) protocol specification. First, the definition of the IANA registry for SFrame ciphersuites omits several important fields. This document updates the IANA registry specified by RFC 9605 and requests that IANA add those fields, defining the contents of those fields for current entries. Second, the AEAD construction based on AES-CTR and HMAC is defined only for the 128-bit security level. This document registers parallel constructions at the 256-bit security level. |
| | Configuring UDP Sockets for ECN for Common Platforms |
| |
|
Explicit Congestion Notification (ECN) applies to all transport protocols in principle. However, it had limited deployment for UDP until QUIC became widely adopted. As a result, documentation of UDP socket APIs for ECN on various platforms is sparse. This document records the results of experimenting with these APIs in order to get ECN working on UDP for Chromium on Apple, Linux, and Windows platforms. This document provides a snapshot of ECN state of affairs as supported by these platforms at the time of writing. Readers should refer to the documentations of the various platforms for an up-to- date information on the matter. |
| | Privacy Primer for vCon Developers |
| |
|
This document serves as a primer for technical professionals involved in the processing (which includes collecting, using, disclosure, and erasure) of personal data, including not only basic identifiers like name, age, and address, but also sensitive data contained in communications, including biometrics obtained from audio and video recordings. It outlines key concepts in data privacy and communications privacy, addressing the ethical and legal considerations surrounding the collection, processing, sharing, access, retention, and disclosure of individuals’ data. The document covers fundamental privacy principles, defines important roles in data processing, and explains individuals’ rights regarding their personal information. It also discusses the scope of protected personal information, including sensitive data categories, and explores techniques like data aggregation and anonymization. While referencing existing IETF work on privacy in Internet communications, this draft extends beyond to address individuals' data privacy in relation to organizations handling such data. The goal is to provide a comprehensive overview of privacy considerations, aligning with fair information practices and current regulatory frameworks, to guide professionals in implementing privacy-respecting data management practices. |
| |
|
| |
| | Matroska Media Container Tag Specifications |
| |
| | draft-ietf-cellar-tags-25.txt |
| | Date: |
03/05/2026 |
| | Authors: |
Steve Lhomme, Moritz Bunkus, Dave Rice |
| | Working Group: |
Codec Encoding for LossLess Archiving and Realtime transmission (cellar) |
|
Matroska is a multimedia container format. It can store timestamped multimedia data but also chapters and tags. The Tag elements add important metadata to identify and classify the information found in a Matroska Segment. This document defines the Matroska multimedia container tags, namely the tag names and their respective semantic meaning. |
| | Authorized update to MUD URLs |
| |
|
This document provides a way for an RFC8520 Manufacturer Usage Description (MUD) definitions to declare what are acceptable replacement MUD URLs for a device. RFCEDITOR-please-remove: this document is being worked on at: https://github.com/mcr/iot-mud-acceptable-urls |
| | JSON Meta Application Protocol (JMAP) Email Delivery Push Notifications |
| |
|
This document specifies an extension to the JSON Meta Application Protocol (JMAP) that allows clients to receive an object via the JMAP push channel whenever a new email is delivered that matches a client- defined filter. The object can also include properties from the email, to allow a user notification to be displayed without having to make a further network request. |
| | MARC: A Control and Uncertainty Disclosure Profile for Generative Models and Agents |
| |
|
This document specifies MARC, a vendor-neutral control and uncertainty-disclosure profile for generative models and agentic systems. MARC defines a small set of interoperable control metadata, separates pre-decision capability assessment from post-decision answer confidence, identifies the target of confidence disclosures, and defines a bounded primary action set for answering, clarification, retrieval, tool use, additional deliberation, abstention, and escalation. MARC does not standardize model internals, training methods, agent discovery, authorization, transport, tool schemas, provenance systems, or claims about machine cognition. Instead, it defines externally observable semantics that can be implemented by model providers, orchestration layers, evaluation harnesses, API gateways, and user-facing systems. The goal is to reduce silent failure, unnecessary externalization, and misleading uncertainty communication while improving auditability and interoperability. |
| | Sovereign Verification & Trust Protocol (SVTP) v1.0 |
| |
|
This document specifies the Sovereign Verification & Trust Protocol (SVTP), a foundational framework for establishing verifiable identity, attribution, and governance for autonomous machines. SVTP provides a non-repudiable "Root of Trust" for both digital AI agents and physical autonomous systems (e.g., industrial robotics, autonomous vehicles). By defining the SVTP-DID (did:svtp) and the Protocol Seal mechanism, this standard enables secure machine-to-machine (M2M) interaction, automated compliance with NIST-800-218, and institutional-grade liability containment in the machine economy. |
| | Update to Automatic Bandwidth Adjustment Procedure of Stateful PCE for MPLS-TE and SR-TE LSPs |
| |
|
The Stateful PCE extensions allow Stateful control of Traffic Engineering (TE) LSPs using PCEP for RSVP-TE and Segment Routing (SR) (for both MPLS and IPv6 Data planes) for both PCE-Initiated and PCC- Initiated LSPs. Extensions to the Path Computation Element Communication Protocol (PCEP) for MPLS-TE Label Switched Path (LSP) Automatic Bandwidth Adjustments with Stateful PCE are defined in RFC 8733. It defines the AUTO-BANDWIDTH-ATTRIBUTES TLV and a set of sub-TLVs for each of the attributes. The sub-TLVs are included if there is a change since the last information sent in the PCEP message. However, it lacks a mechanism to remove an attribute identified by the sub-TLV explicitly. This document updates RFC 8733 by defining the behaviour to remove an attribute explicitly. In addition, this updates allow applying this PCEP extensions to SR-TE LSPs (for both MPLS and IPv6 Data planes), in addition to MPLS-TE LSPs. |
| | A well-known URI for publishing service parameters |
| |
| | draft-ietf-tls-wkech-12.txt |
| | Date: |
03/05/2026 |
| | Authors: |
Stephen Farrell, Rich Salz, Benjamin Schwartz |
| | Working Group: |
Transport Layer Security (tls) |
|
We define a well-known URI at which an HTTP origin can inform an authoritative DNS server, or other interested parties, about its Service Bindings. Service binding data can include Encrypted ClientHello (ECH) configurations, that may change frequently. This allows the HTTP origin, in collaboration with DNS infrastructure elements, to publish and rotate its own ECH keys. Other service binding data such as information about TLS supported groups is unlikely to change quickly, but the HTTP origin is much more likely to have accurate information when changes do occur. Service data published via this mechanism is typically available via an HTTPS or SVCB resource record. |
| |
|
| |
| | HTTP Live Streaming 2nd Edition |
| |
|
This document obsoletes RFC 8216. It describes a protocol for transferring unbounded streams of multimedia data. It specifies the data format of the files and the actions to be taken by the server (sender) and the clients (receivers) of the streams. It describes version 13 of this protocol. |
| | General Guidance for Implementing Branded Indicators for Message Identification (BIMI) |
| |
|
This document is meant to provide guidance to various entities so that they may implement Brand Indicators for Message Identification (BIMI). This document is a companion to various other BIMI drafts, which should first be consulted. |
| | SVG Tiny Portable/Secure |
| |
|
This document specifies SVG Tiny Portable/Secure (SVG Tiny PS) -- A Scalable Vector Graphics (SVG) profile to be used with documents that are intended for use with more secure requirements, and in some cases, in conjunction with a limited rendering engine. |
| | Fetch and Validation of Verified Mark Certificates |
| |
|
A description of how entities wishing to validate a Verified Mark Certificate (VMC) should retrieve and validate these documents. This document is a companion to BIMI core specification, which should be consulted alongside this document. |
| | BIMI Reporting |
| |
|
To support the utility of Brand Indicators for Message Identification (BIMI), domains publishing BIMI records may find it useful to know when their logos are failing to be displayed as expected. When an entity, for example a mailbox operator, determines whether or not to display the logo identified in the BIMI record, they may encounter errors trying to retrieve the image file. Similarly, the associated evidence document used to validate the logo may fail evaluation. In other cases, the evaluator may decide that despite everything validating, they may rely on local policies that determine validated logos should still not be displayed. This specification defines how BIMI evaluators should report their evaluation outcome back to the publisher within the context of existing Domain-based Message Authentication, Reporting, and Conformance (DMARC) reports. |
| | Brand Indicators for Message Identification (BIMI) |
| |
|
Brand Indicators for Message Identification (BIMI) permits Domain Owners to coordinate with Mail User Agents (MUAs) to display brand- specific Indicators next to properly authenticated messages. There are two aspects of BIMI coordination: a scalable mechanism for Domain Owners to publish their desired Indicators, and a mechanism for Mail Transfer Agents (MTAs) to verify the authenticity of the Indicator. This document specifies how Domain Owners communicate their desired Indicators through the BIMI Assertion Record in DNS and how that record is to be interpreted by MTAs and MUAs. MUAs and mail- receiving organizations are free to define their own policies for making use of BIMI data and for Indicator display as they see fit. |
| | Agent Attachment Protocol |
| |
|
This document describes the Agent Attachment Protocol (AAP) that enables AI agents to establish attachment to an edge node and derive communication and attachment-related properties. These properties include endpoint identifiers, supported communication mechanisms, and attachment context information that can be exposed to discovery systems. AAP focuses on how agents obtain and maintain attachment state and how attachment-derived properties can be represented in a consistent and interoperable manner. These properties can be used by forwarding functions at edge nodes and by routing or control-plane mechanisms to support communication between agents. |
| | The HTTP FETCH-ONCE Method |
| |
|
This document defines the HTTP FETCH-ONCE method. It allows a client to retrieve a resource and ensures that the resource is immediately deleted or invalidated after retrieval. |
| | Smart Traffic Synchronization Protocol (STSP) Version 1.0 |
| |
|
This document defines the Smart Traffic Synchronization Protocol (STSP), version 1.0 -- an open, extensible protocol for real-time coordination of urban traffic signal infrastructure across distributed networks of intersections. STSP defines a standard message format, node state machine, synchronization algorithm, and inter-node communication model that enables any compliant traffic controller to participate in a federated intelligent network -- regardless of manufacturer, city, or country of deployment. The key contribution of STSP is the definition of the Infrastructure- to-Infrastructure (I2I) coordination layer -- a communication model between traffic signal nodes that does not exist as an open standard in any currently published specification. Existing standards such as SAE J2735 SPaT/MAP and ETSI ITS-G5 address Vehicle-to-Infrastructure (V2I) communication. STSP addresses the orthogonal problem: how nodes coordinate with each other. This document is placed in the public domain under CC BY 4.0 with Open Implementation Clause. Any city, government, company, or individual may implement STSP freely, provided that original authorship is attributed in all implementations, documentation, and derivative works as follows: "Implements STSP, designed by Gustavo Angel Aldana Flores (draft-aldana-stsp)." |